Influence scheduling priority with nice and renice

775

Author: Evi Nemeth, Garth Snyder, and Trent R. Hein

The “niceness” of a process is a numeric hint to the kernel about how the process should be treated in relation to other processes contending for the CPU. The strange name is derived from the fact that it determines how nice you are going to be to other users of the system. A high nice value means a low priority for your process: you are going to be nice. A low or negative value means high priority: you are not very nice. The range of allowable niceness values is -20 to +19.

This article is excerpted from the newly published Linux Administration Handbook, Second Edition.

Unless the user takes special action, a newly created process inherits the nice value of its parent process. The owner of the process can increase its nice value but cannot lower it, even to return the process to the default niceness. This restriction prevents processes with low priority from bearing high-priority children. The superuser may set nice values arbitrarily.

It’s rare to have occasion to set priorities by hand these days. On the puny systems of the 1970s and ’80s, performance was significantly affected by which process was on the CPU. Today, with more than adequate CPU power on most desktops, the scheduler usually does a good job of servicing all processes. The addition of scheduling classes gives developers additional control in cases where low response latency is essential.

I/O performance has not kept up with increasingly fast CPUs, and the major bottleneck on most systems has become the disk drives. Unfortunately, a process’s nice value has no effect on the kernel’s management of its memory or I/O; high-nice processes can still monopolize a disproportionate share of these resources.

A process’s nice value can be set at the time of creation with the nice command and adjusted later with the renice command. nice takes a command line as an argument, and renice takes a PID or a username. Confusingly, renice requires an absolute priority, but nice wants a priority increment that it then adds to or subtracts from the shell’s current priority.

Some examples:

$ nice -n 5 ~/bin/longtask

   

// Lowers priority (raise nice) by 5

$ sudo renice -5 8829

   

// Sets nice value to -5

$ sudo renice 5 -u boggs

   

// Sets nice value of boggs’s procs to 5

To complicate things, a version of nice is built into the C shell and some other common shells (but not bash). If you don’t type the full path to the nice command, you’ll get the shell’s version rather than the operating system’s. This duplication can be confusing, because shell-nice and command-nice use different syntax: the shell wants its priority increment expressed as +incr or –incr, but the standalone command wants an -n flag followed by the priority increment. (Actually, it’s even worse than this: the standalone nice will interpret nice -5 to mean a positive increment of 5, whereas the shell built-in nice will interpret this same form to mean a negative increment of 5.)

The most commonly niced process in the modern world is xntpd, the clock synchronization daemon. Since CPU promptness is critical to its mission, it usually runs at a nice value about 12 below the default (that is, at a higher priority than normal).

If a process goes berserk and drives the system’s load average to 65, you may need to use nice to start a high-priority shell before you can run commands to investigate the problem. If you don’t, you may have difficulty running even simple commands.

© Copyright Pearson Education. All rights reserved.