Chapter 2. Monitoring and benchmark tools 43
Draft Document for Review May 4, 2007 11:35 am 4285ch02.fm
The columns in the output are as follows:
Process (procs) r: The number of processes waiting for runtime.
b: The number of processes in uninterruptable sleep.
Memory swpd: The amount of virtual memory used (KB).
free: The amount of idle memory (KB).
buff: The amount of memory used as buffers (KB).
cache: The amount of memory used as cache (KB).
Swap si: Amount of memory swapped from the disk (KBps).
so: Amount of memory swapped to the disk (KBps).
IO bi: Blocks sent to a block device (blocks/s).
bo: Blocks received from a block device (blocks/s).
System in: The number of interrupts per second, including the clock.
cs: The number of context switches per second.
CPU (% of total CPU time)
us: Time spent running non-kernel code (user time, including nice time).
sy: Time spent running kernel code (system time).
id: Time spent idle. Prior to Linux 2.5.41, this included I/O-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, this appeared as
zero.
The vmstat command supports a vast number of command line parameters that are fully
documented in the man pages for vmstat. Some of the more useful flags include:
-m displays the memory utilization of the kernel (slabs).
-a provides information about active and inactive memory pages.
-n displays only one header line, useful if running vmstat in sampling mode and
piping the output to a file. (For example, root#vmstat –n 2 10 generates vmstat
10 times with a sampling rate of two seconds.)
When used with the –p {partition} flag, vmstat also provides I/O statistics.
2.3.3 uptime
The uptime command can be used to see how long the server has been running and how
many users are logged on, as well as for a quick overview of the average load of the server
(Refer to 1.6.1, “Processor metrics” on page34). The system load average is displayed for
the past 1-minute, 5-minute, and 15-minute intervals.
The optimal value of the load is 1, which means that each process has immediate access to
the CPU and there are no CPU cycles lost. The typical load can vary from system to system:
For a uniprocessor workstation, 1 or 2 might be acceptable, whereas you will probably see
values of 8 to 10 on multiprocessor servers.
You can use uptime to pinpoint a problem with your server or the network. For example, if a
network application is running poorly, run uptime and you will see whether the system load is
high. If not, the problem is more likely to be related to your network than to your server.
Tip: You can use w instead of uptime. w also provides information about who is currently
logged on to the machine and what the user is doing.