|
HP OpenVMS Systemsask the wizard |
|
The Question is: Dear Wizard, I would like to increase my backup elapsed time on my Alphaserver 1000A/500 with 1GB of memory. I have a disk with 250,000 files and 5GB of used space. The disk is a partition on a three disk RAID5 set attached to a RAID230 controller. The cluster_size is 26, fragmented files are defragmented regularly. My backup device is a Quantum DLT4700 DLT library, the sustained data transfer rate is 1.5MB/second. Backup acct quotas: fillm=2000, biolm=1000, diolm=4096, astlm=4096, tqelm=512, Enqlm 2000, bytlm 500000,wsdef=wsquota=wsextent= 500000, pgflquo=1000000. Corresponding sysgen paramaters are greater than or equal to the above quota numbers. The backup command I am using has the following switches: $ backup /image /ignore=interlock /record /block_size=65534 Using performance Solution, it takes 1 1/2 hours to backup the data and 2 hours to update the backup date on the files. What is your recommendation? Any tricks to speed things up. The Answer is :
250K files in 2 hours works out to 35 files per second. With a read and
a write each -- and you are definitely not getting any benefit from the
file system's cache here! -- you are doing well at that rate. The other
consideration to remember is that the file operations are synchronous and
serially executed, so you get no benefit at all from the superior bandwidth
of a RAID set.
The OpenVMS Wizard would recommend ceasing the use of /RECORD, and specify
an explicit /SINCE time on your backup rathern than /SINCE=BACKUP. That
would likely save you more than half your backup time right there.
On the actual backup...
With 5GB of file space, your 1.5 hour backup time means you are getting
slightly better than .9MB/sec average data rate. Assuming you are running
the tape uncompressed (i.e., 1.5MB max transfer rate) you are receiving
the performance that the OpenVMS Wizard would expect assuming a lack of
I/O overlap between disk and tape. This is one of BACKUP's current known
problems, and has been removed in recent versions and ECOs.
In terms of your quotas, the OpenVMS Wizard would recommend reducing the
working set. The buffer pool is sized according to the working set; with
such a huge buffer pool you are getting starvation on the other quotas.
For example, since your average file size is 40 blocks, with a FILLM of
2000 you are only using about 80,000 pages of buffer pool before you
cannot open any more files. Even so, there's a good chance you will run
out of DIOLM. This exhaustion is particularly insidious as it stalls the
issue of the remaining disk reads, and in turn stalls the issue of tape
writes. (With the V7.2 version of BACKUP, and associated ECOs for
earlier releases, see the OpenVMS System Management documentation for
the recommended settings.)
1: Check your CHANNELCNT SYSGEN parameter. This is the other throttle
on how many files you can open. Either raise it or reduce FILLM to
be equal to CHANNELCNT. Your BYTLM is OK at 500,000.
2: Reduce WSQUOTA to 20,000. Make certain that WSMAX is at least this
big, as well.
3: Raise DIOLM and ASTLM to 10,000. Make sure you have sufficient
non-paged pool configured to accomodate this many concurrent I/Os.
Unfortunately, with an average file size of 40 blocks, you are getting
killed by file structure overhead. Again, opening files is synchronous,
so you don't get any benefit of the RAID bandwidth. You are probably
spending just as much time opening files as you are reading them.
As mentioned, there is some relief in V7.2. The concurrency has been
greatly improved in BACKUP, so that it achieves the maximum possible
overlap of disk and tape I/O. That means the backup performance should
be close to either the disk or tape speed, whichever is slower.
|