All that measurement stuff is good for the management reports but from a sysadmin perspective (DBA's opinion notwithstanding), performance is in the eye of the beholder (the user in this case). Your machine is showing no signs of getting bogged down since just one of the processors is really busy.
NOTE: There is nothing you (the sysadmin) can do to improve processor usage. If the program(s) all want to eat CPU cycles, then so be it. That's why you have a multi-processor system. To reduce the percentage of CPU usage:
1. Rewrite the program(s) to be more efficient, or
2. Replace the computer with faster processors
Now number 2 assumes that programs don't just waste CPU cycles, 'cause a faster computer will only burn useless cycles even faster. Example:
while do :
do
:
done
Anyone can type this in at a shell prompt and immediately burn 100% of one CPU. Efficient? Not really since it doesn't accomplish anything. But start 10 of these and you should see a significant reduction in the perfromance of the machine.
You (your company) spent a lot on the CPU and RAM so ideally, it will mostly be used. Requiring computers be only 1/2 used is an artificial boundary that dates back to punched cards and papertape where computers would 'lock up' if loaded too heavily. That's virtually unknown in HP-UX (assumes proper patching).
Now, that being said, there are a few things you can do once you discover I/O limitations (the infamous bottleneck). If it's LAN (and the LAN trraffic is legitimate), then look at AutoPort Aggregation (gigabit isn't quite the solution, APA works real well). If it's disk limits, then there's lots of choices, starting with the application. For Oracle, make sure the indexes are reasonable balanced (lots of row insertions may unbalance an index). And indexes sometimes get corrupted and are quietly ignored until rebuilt (means lots of serial reads). Make sure sorts are in RAM and not a temp sort area (SGA may need lots more RAM). Move hot spots such as rollback/archive logs and sort areas to physically different disks, and so on.
Once those areas have been examined, you can look at disk striping and perhaps changing the block size in the filesystems (default 8kb, might try 16kb if data records are large). The basic read-ahead size for HP-UX is 64kb but LVM will aggregate 8kb I/O's into 64kb if the I/O's are sequential. And prefetch for the buffer cache is typically 4x64kb or 256Kb. But as always, your mileage may vary.
Bill Hassell, sysadmin
