We have a serious ADSM performance problem with incremental backup
operations on one of our HP systems.
I think we are running ADSM Server Version 2, Release 1, Level 0.3 on
MVS (that's what the message in /usr/adsm/dsmsched.log says).
And I think we're running ADSM client v1r3 on the HP-UX 10.1 system.
Every night we run an incremental backup operation and the
dsmsched.log looks something like this:
02/27/1997 03:56:35 Total number of objects inspected: 289,072
02/27/1997 03:56:35 Total number of objects backed up: 7,766
02/27/1997 03:56:35 Total number of objects updated: 0
02/27/1997 03:56:35 Total number of objects rebound: 0
02/27/1997 03:56:35 Total number of objects deleted: 2,970
02/27/1997 03:56:35 Total number of objects failed: 0
02/27/1997 03:56:35 Total number of bytes transferred: 85.4 MB
02/27/1997 03:56:35 Data transfer time: 523.77 sec
02/27/1997 03:56:35 Data transfer rate: 166.98 KB/sec
02/27/1997 03:56:35 Average file size: 11.2 KB
02/27/1997 03:56:35 Elapsed processing time: 8:58:21
The problem is the last line. Why did it take so long to complete this
operation? Look at the middle of the log:
02/26/1997 20:53:19 Expiring--> 6,273
/sps/spedi/data/log/L-970217:070007.cl_mapout.ERR Sent
02/26/1997 20:53:24 ANS4102I ***** Processed 164,000 files *****
02/27/1997 03:49:15 Expiring--> 3,840
/sps/spedi/data/log/L-970217:070932.cl_MCLANE.ERR Sent
From 20:53 until 3:49, we got nothing done. But MeasureWare shows that
dsmc cpu utilization was nearly 100% during that time. (There is other
work running on the machine, after all!)
This happens every night on this system.
Any ideas about what could be causing this aberrant behavior?
Thanks,
Christopher Voris
Clorox Services Company
Christopher.Voris AT Clorox DOT com
|