[wplug] cpu load?

[Bryan J Smith]

First off, there are differences between being processor
bound and I/O bound, although you can run into both.
Some I/O processes will actually result in a low CPU utilization,
but the entire system is pegged and unable to do much.

[ E.g., a common compliant with software RAID-5 is unrespon-
siveness of a database/file server, even though CPU utilization
is only 10%. And when running bonnie benchmarks not under load,
write performance seems to be very, very adequate.
But once real metrics are applied and statistics gathered under
load, it quickly becomes apparent that disk I/O is inhibiting net I/O,
and the CPU is being used for little more than programmed I/O
(of which the x86 approach absolutely sucks at, and why we
have dedicated network and I/O processors out there). ]

Secondly and unfortunately, there is _no_ good way to measure
various I/O statistics in Linux, or analyze them against metrics.
The most you can measure is the CPU servicing interrupt request,
which does nothing to tell you about DMA operations, throughput,
bus availability, etc...
The iostat utlility shows you none of these values and cannot.

Third, if your disk is pegged, that's a possible sign of thrashing.
Fortunately, there is an utility to measure that, vmstat.
Use vmstat to see how much paging is going on,
which will directly affect you disk I/O and bus usage.
It should not, however, hit your CPU utilization to bad,
unless there is a lot of processes running and context switching
is eating up a lot of time waiting on I/O resources.

Lastly, as another poster suggested, if you have a massive sequence
of stat operations on your filesystem, that will somewhat peg your
system with I/O while actually being processor bound.
If updatedb is running and updating the apropos db, consider
suspending or killing the process and seeing if CPU load drops.
Mass stat operations are the culprit of unwanted loads, and I
often trap such operations and send myself an alert.

[ E.g., being a consultant, when I first get on any site, there is
always a complaint about a file server being "unresponsive" sometimes.
9 times out of 10, it's some AFS/NFS/SMB client (typically the last)
doing a search on the network share. ]

--  
Bryan J Smith - mailto:b.j.smith at ieee.org  
http://thebs413.blogspot.com  
Sent via BlackBerry from T-Mobile