4

Renicing a process to a negative nice level increases the process's scheduling priority. High priority processes are run before low-priority processes. They are also allowed to run longer before being pre-empted (they get longer time-slices).

On a web server, running httpd processes with a negative nice value should reduce context switching and therefore improve overall performance.

Has anyone tried doing this? What kind of a difference does it make? Is response time improved? Does the response time standard deviation increase or decrease? Is throughput improved?

Edit:

I'm not looking to reduce the priority of other processes; and I'm not looking to fix an overloaded system. I'm wondering if negative nice levels effect reduced context switches, and if so what the impact of this is on response time and throughput.

Improve this question
3
  • "High priority processes are run before low-priority processes" - not so - they are scheduled more frequently - not necessarily before. "On a web server....reduce context switching" - if it's a webserver then by definition its not competing with anything else. If its a generic server running less critical services and you've exhausted other routes for optimisation then you may get some benefit from reducing the priority of other services - apart from the system services.
    – symcbean
    Jun 9, 2011 at 12:54
  • The individual httpd processes compete with themselves. I'm wondering how much impact giving processes an increased time-slice has. This is about optimizing for actual throughput at the expense of interactivity by reducing pre-emption and other context switches.
    – Daniel S. Sterling
    Jun 9, 2011 at 16:07
  • But you can't sensibly manipulate the priority on seperate processes for the same webserver instance. And running multiple instances of webserver on the same box would be a bit dumb.
    – symcbean
    Jun 10, 2011 at 12:18

2 Answers 2

Reset to default
6

I'd highly suggest not doing this. If your server is so heavily loaded that apache isn't getting the CPU time it needs, then renicing a process will have a very minimal effect, if any. Additionally, apache will have many different processes running at any one time. You could renice the parent process, and its children will inherit the parent's niceness, but then all of the httpd processes will be fighting each other for time.

In old kernels (say late 90s/early 00s), I found there to be some value in renicing processes (though I usually only decreased priority, not increased). With the scheduler in modern kernels, I've never found it to be necessary or even worthwhile thinking about.

In conclusion, to solve performance problems, there are a plethora of other areas I would pay attention to before I'd start blaming process priority.

Improve this answer
3
  • 2
    The point isn't that the server is heavily loaded. Let's say it isn't. The httpd processes will compete for CPU time no matter how many there are or what the load is. The point is to optimize for actual throughput at the expense of interactivity by reducing pre-emption and other context switches; by giving each httpd as much time as I can per context switch, overall performance should improve -- that's the theory. I'm not looking to blame process priority, I'm looking to use it as a tool to reduce context switches.
    – Daniel S. Sterling
    Jun 9, 2011 at 16:10
  • If you server is not heavily loaded, none of this is going to make any difference whatsoever, and may possibly decrease performance. If you want to test this, feel free to do so. I'd be very surprised, though if it makes any difference at all.
    – EEAA
    Jun 9, 2011 at 16:14
  • 2
    I'm not trying to disagree with you; but do you have any details or theory behind why prioritizing processes would reduce performance? I agree it might not make much difference, and it might increase "jitter" (response time standard deviation); but theoretically it should also increase overall throughput as the system will spend less time context switching. Do you know or think otherwise?
    – Daniel S. Sterling
    Jun 9, 2011 at 16:21
1

Warning: IANAKD (I am not a Kernel Developer :)

Assuming we are talking about Linux, you can read about how nice is implemented at:

http://www.kernel.org/doc/Documentation/scheduler/sched-nice-design.txt

To attempt to answer your question, it won't affect throughput because processes are deprioritized while blocking on I/O, and a Web server serving static content is most likely going to be I/O bound.

See also the "ionice" command-- although it's not useful unless different processes are contending for I/O.

Ultimately I don't think that reducing context switches will make a difference. Most likely a Web server serving static content is spending all its time doing I/O (network or disk) and the CPU is relatively idle. Processors are so much more powerful than I/O subsystems these days that they are rarely the bottleneck in many server scenarios. (Obviously pure number crunching or 3D rendering and such are exceptions to this.) If you're considering implementing this on a real server to improve performance, I would suggest first monitoring the system using tools like top, iostat, vmstat, dstat, etc. to see where it's spending most of its time. Once you have data on the bottleneck, you'll be in a good position to look for solutions to it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .