UNIX System Administration Handbook - Evi Nemeth [449]
Long-term averages of the CPU statistics allow you to determine whether there is fundamentally enough CPU power to go around. If the CPU usually spends part of its time in the idle state, there are cycles to spare. Upgrading to a faster CPU won’t do much to improve the overall throughput of the system, though it may speed up individual operations.
As you can see from these examples, the CPU generally flip-flops back and forth between full-on use and complete idleness. Therefore, it’s important to observe these numbers as an average over time. The smaller the monitoring interval, the less consistent the results.
On a workstation with only one user, the CPU generally spends 99% of its time idle. Then, when you go to scroll one of the windows on your bitmap display, the CPU is floored for a few seconds. In this situation, information about long-term average CPU usage is not meaningful.
The second CPU statistic that’s useful for characterizing the burden on your system is the “load average,” the average number of runnable processes. In general, the load average includes processes waiting for disk and network I/O, so it is not a pure measure of CPU use. However, it does give you a good idea of how many pieces the CPU pie is being divided into. The load average is obtained with the uptime command:
% uptime
2:07pm up 4:02, 5 users, load average: 0.95, 0.38, 0.31
Three values are given, corresponding on most systems to the 5, 10, and 15-minute averages. In general, the higher the load average, the more important the system’s aggregate performance becomes. If there is only one runnable process, that process will usually be bound by a single resource (commonly disk bandwidth or CPU). The peak demand for that one resource becomes the determining factor in performance.
When more processes share the system, loads may or may not be more evenly distributed. If the processes on the system all consume a mixture of CPU, disk, and memory, the performance of the system is less likely to be dominated by constraints on a single resource. In this situation, it becomes most important to look at average measures of consumption such as total CPU utilization.
Modern systems do not deal well with load averages over about 6.0. A load average of this magnitude is a hint that you should start to look for ways to artificially spread the load, such as asking users to run long processes at night or using nice to set process priorities.
See page 47 for more information about priorities.
The system load average is an excellent metric to track as part of a system baseline. If you know your system’s load average on a normal day and it is in that same range on a bad day, this is a hint that you should look elsewhere for performance problems (such as the network). A load average above the expected norm suggests that you should look at the processes running on the UNIX system itself.
Another way to view CPU usage is to run the ps command with arguments that let you see how much of the CPU each process is using (-elf for HP-UX and Solaris, -aux for Red Hat and FreeBSD). More likely than not, on a busy system, at least 70% of the CPU will be consumed by one or two processes. (Remember that ps consumes some CPU itself.) Deferring the execution of the CPU hogs or reducing their priority will make the CPU more available to other processes.
An excellent alternative to ps is a program called top. top presents about the same information as ps, but in a “live” format that lets you watch the status of the system change over time.2
See page 57 for more information about top.
How UNIX manages memory
UNIX manages memory in units called pages that are usually 4K or larger. They are sometimes called “page clusters” if they are bigger than the page size that’s directly supported by the CPU or memory controller. Disk blocks are usually smaller than memory pages (1K or 512 bytes), so the kernel has to associate several disk blocks with each page that’s written out.
UNIX tries to manage