Durable advice speeds up HP 3000s
February 17, 2014
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.
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. Gilles 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
In the report that is produced, you will notice OPEN files (ones with an associated asterisk ending the file name); these are 1W in size.
There are two such files associated with each configured DTC, file name starting with the letter H, followed by six characters that represent the last six characters of the DTC MAC address, followed by the letter A or B. The EOF for these files should be 0 and 5 for the respective "A" and "B" files.
Otherwise, your CPU is being subjected to high-volume, unnecessary IO, requiring CPU attention. The solution is to simply enable SQL heartbeat for each transceiver attached to each DTC. This is done via a small white jumper switch that you should see at the side of each transceiver. Voila, you've just achieved a significant no-cost CPU upgrade.
Compete details are in Gilles' original article. On speeding up backup time, he pointed out that adding an option to the STORE command will help you track IO retries.
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.