 |  |
| |
The BSD-System V split isn't so obvious in modern Unixes, but the different priority systems still live in various flavors. This article should help you understand the system in whatever version you have.
If you are going to run a CPU-bound (Section 26.1) process that will monopolize the CPU from other processes, you may reduce the urgency of that more intensive process in the eyes of the process scheduler by using nice before you run the program. For example:
$ nice executable_filename
On most systems, no user can directly change a process's priority (only the scheduler does that), and only the administrator can use nice to make a process more urgent. In practice, nice is rarely used on multiuser systems -- the tragedy of the commons -- but you may be able to get more processes running simultaneously by judicious use of this program.
If you're not familiar with Unix, you will find its definition of priority confusing -- it's the opposite of what you would expect. A process with a high nice number runs at low priority, getting relatively little of the processor's attention; similarly, jobs with a low nice number run at high priority. This is why the nice number is usually called niceness: a job with a lot of niceness is very kind to the other users of your system (i.e., it runs at low priority), while a job with little niceness hogs the CPU. The term "niceness" is awkward, like the priority system itself. Unfortunately, it's the only term that is both accurate (nice numbers are used to compute priorities but are not the priorities themselves) and avoids horrible circumlocutions ("increasing the priority means lowering the priority...").
Many supposedly experienced users claim that nice has virtually no effect. Don't listen to them. As a general rule, reducing the priority of an I/O-bound job (a job that's waiting for I/O a lot of the time) won't change things very much. The system rewards jobs that spend most of their time waiting for I/O by increasing their priority. But reducing the priority of a CPU-bound process can have a significant effect. Compilations, batch typesetting programs (troff, TEX, etc.), applications that do a lot of math, and similar programs are good candidates for nice. On a moderately loaded system, I have found that nice typically makes a CPU-intensive job roughly 30 percent slower and consequently frees that much time for higher priority jobs. You can often significantly improve keyboard response by running CPU-intensive jobs at low priority.
Note that System V Release 4 has a much more complex priority system, including real-time priorities. Priorities are managed with the priocntl command. The older nice command is available for compatibility. Other Unix implementations (including HP and Concurrent) support real-time scheduling. These implementations have their own tools for managing the scheduler.
The nice command sets a job's niceness, which is used to compute its priority. It may be one of the most nonuniform commands in the universe. There are four versions, each slightly different from the others. BSD Unix has one nice that is built into the C shell, and another standalone version can be used by other shells. System V also has one nice that is built into the C shell and a separate standalone version.
Under BSD Unix, you must also know about the renice(8) command (Section 26.7); this lets you change the niceness of a job after it is running. Under System V, you can't modify a job's niceness once it has started, so there is no equivalent.
NOTE: Think carefully before you nice an interactive job like a text editor. See Section 26.6.
We'll tackle the different variations of nice in order.
Under BSD Unix, nice numbers run from -20 to 20. The -20 designation corresponds to the highest priority; 20 corresponds to the lowest. By default, Unix assigns the nice number 0 to user-executed jobs. The lowest nice numbers (-20 to -17) are unofficially reserved for system processes. Assigning a user's job to these nice numbers can cause problems. Users can always request a higher nice number (i.e., a lower priority) for their jobs. Only the superuser (Section 1.18) can raise a job's priority.
To submit a job at a greater niceness, precede it with the modifier nice. For example, the following command runs an awk command at low priority:
% nice awk -f proc.awk datafile > awk.out
By default, the csh version of nice will submit this job with a nice level of 4. To submit a job with an arbitrary nice number, use nice one of these ways, where n is an integer between 0 and 20:
% nice + n command % nice - n command
The +n designation requests a positive nice number (low priority); -n requests a negative nice number. Only a superuser may request a negative nice number.
The standalone version of nice differs from C shell nice in that it is a separate program, not a command built in to the C shell. You can therefore use the standalone version in any situation: within makefiles (Section 11.10), when you are running the Bourne shell, etc. The principles are the same. nice numbers run from -20 to 20, with the default being 0. Only the syntax has been changed to confuse you. For the standalone version, -n requests a positive nice number (lower priority) and --n requests a negative nice number (higher priority -- superuser only). Consider these commands:
$ nice -6 awk -f proc.awk datafile > awk.out # nice --6 awk -f proc.awk datafile > awk.out
The first command runs awk with a high nice number (i.e., 6). The second command, which can be issued only by a superuser, runs awk with a low nice number (i.e., -6). If no level is specified, the default argument is -10.
System V takes a slightly different view of nice numbers. nice levels run from 0 to 39; the default is 20. The numbers are different but their meanings are the same: 39 corresponds to the lowest possible priority, and 0 is the highest. A few System V implementations support real-time submission via nice. Jobs submitted by root with extremely low nice numbers (-20 or below) allegedly get all of the CPU's time. Systems on which this works properly are very rare and usually advertise support for real-time processing. In any case, running jobs this way will destroy multiuser performance. This feature is completely different from real-time priorities in System V Release 4.
With these exceptions, the C shell version of nice is the same as its BSD cousin. To submit a job at a low priority, use the command:
% nice command
This increases the command's niceness by the default amount (4, the same as BSD Unix); command will run at nice level 24. To run a job at an arbitrary priority, use one of the following commands, where n is an integer between 0 and 19:
% nice + n command % nice - n command
The +n entry requests a higher nice level (a decreased priority), while -n requests a lower nice level (a higher priority). Again, this is similar to BSD Unix, with one important difference: n is now relative to the default nice level. That is, the following command runs awk at nice level 26:
% nice +6 awk -f proc.awk datafile > awk.out
Once again, the standalone version of nice is useful if you are writing makefiles or shell scripts or if you use the Bourne shell as your interactive shell. It is similar to the C shell version, with these differences:
With no arguments, standalone nice increases the nice number by 10 instead of by 4; this is a significantly greater reduction in the program's priority.
With the argument -n, nice increases the nice number by n (reducing priority).
With the argument - -n, nice decreases the nice number by n (increasing priority; superuser only).
Consider these commands:
$ nice -6 awk -f proc.awk datafile > awk.out # nice --6 awk -f proc.awk datafile > awk.out
The first command runs awk at a higher nice level (i.e., 26, which corresponds to a lower priority). The second command, which can be given only by the superuser, runs awk at a lower nice level (i.e., 14).
-- ML
|  | |
| 26.4. Checking System Load: uptime |  | 26.6. A nice Gotcha |
Copyright © 2003 O'Reilly & Associates. All rights reserved.