Reliable advice on speeding up 3000s
April 3, 2006
About a month ago our editor Gilles Schipper posted a fine article on improving CPU performance on 3000s "in a heartbeat." One of our readers asked a question which prompted Gilles to clarify part of the process to speed up a 3000, for free.
(And no, unfortunately the article doesn't report that HP has pulled out the MPE/iX code that slows down the latest generation of 3000 systems. We're still waiting for that news from HP, perhaps in vain. But you never know...)
Gilles, who offers HP 3000 and HP 9000 support through his firm GSA, Inc., has also replied to a recent question about how to make a DLT backup device return to its speedy performance, after slowing to about a third of its performance.
The Heartbeat article focused on needless CPU overhead that could be caused by a networking heartbeat on 3000s. He points out:
Fortunately, there is a very simple way to recognize whether the problem exists, and also a simple cure. If your DTCs are connected without transceivers, you will not be subject to this problem.
Otherwise, to determine if you have the problem, simply type the command
:listf [email protected],2
and look at the reply that follows
Compete details are in the February 27 article, which we've revised to include this update.
On speeding up backup time, Gilles replied to this question:
We have a DLT tape drive. Lately it wants to take 6-7 hours to do backup instead of its usual two or less. But not every night, and not on the same night every week. I have been putting in new tapes now, but it still occurs randomly. I have cleaned it. I can restore from the tapes no problem. It doesn’t appear to be fighting some nightly process for CPU cycles. Any ideas on what gives?
Something that may be causing extended backup time is excessive IO retries, as the result of deteriorating tapes or tape drive.
One way to know is to add the ;STATISTICS option to your STORE command. This will show you the number of IO retries as well as the actual IO rate and actual volume of data output.
Another possibilty is that your machine is experiencing other physical problems resulting in excessive logging activity and abnormal CPU interrupt activity — which is depleting your system resources resulting in extended backup times.
Check out the following files in the following Posix directories:
/var/stm/logs/os/*
/var/stm/logs/sys/*
If they are very large, you indeed may have a hardware problem — one that is not "breaking" your machine, but simply "bending" it.