Workshop

it a point to say, “Would you show me, please?” Otherwise, a communication jam (between you and her)
could send you on the wrong track. As soon as you saw her open a Telnet session to a UNIX host and log
on, you knew, objectively, that this application lived on a UNIX host.
Check with other users of the UNIX host. Are they having problems? Some of them are disgruntled: “Yes,
things are pretty slow.” Others are not. You examine who is having problems and find that they’re mostly
people running reports. Because you know that the processing for reports takes place on the UNIX host
itself, you naturally suspect the UNIX host as the culprit. If you suspected a network problem at this point,
you might time an FTP transfer of a large file to this UNIX host to rule out a network problem. You don’t,
however, suspect a network problem, because all the folks who are reporting problems are largely doing
back-end processing on the UNIX host. You decide to monitor the resources of the UNIX host. You
perform a vmstat and come up with this:
procs memory page faults cpu
-------------------------------------------r
b avm fre re pi po fr sr cy in sy cs us sy id wa
0 0 16894 120 1 0 78 208 312 0 279 1208 94 5 19 54 22
0 0 17091 173 1 8 95 288 872 0 271 2730 180 13 34 33 20
4 1 17112 123 0 48 0 168 635 0 293 3751 386 20 51 0 29
6 1 17050 267 0 48 0 152 652 0 267 4124 359 24 44 0 32
Wow! It looks horrible. What in blazes does this cryptic output mean? (Hint: See Hour 8, “Hard Basics:
Guide to Being a Hardware Geek,” for a verbose description of these column headings.)
For the purposes of this discussion, the salient points here are contained in the fre, po, and pi columns.
Basically, this output is showing that you have very little memory in the free list and that page-outs (po)
and page-ins (pi) are way up.
Remember that paging activity takes a really, really long time in comparison to using physical memory. All
this paging activity sure does slow things down. To be absolutely sure that this is the problem, you monitor
the paging activity during the times the users say the box is slow. There’s definitely a correlation. You
recommend a memory upgrade, and as soon as the memory is installed, the problem goes away. Excellent!
Certain third-party vendors make graphical long-term server resource reporting tools; if you have long-term
problems, it might be worth investing in one of these. The graphical representation of resource use can really
be helpful in spotting resource trends that can be dealt with before you have problems. (The Microsoft
System Monitor is certainly a good start, but even more sophisticated tools are available.)
Previous Table of Contents Next