![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: I have a Alpha 8200 5/440 running Openvms 7.1 with a DLT7000 connected directly to it's internal scsi controller. Based on the DLT7000 specifications I should get 5MB/sec transfer rate native mode so about 18GB per hour. Using the VMS backup command I backup a 2GB disk with a single 2GB file on it and I get a transfer rate around 4GB per hour. I have tried adjusting the block sizes in the backup command with no real change in throughput. Why can't I get anywhere near the expected throughput? The Answer is : You should definitely be able to do better. We were able to pull data off an RZ29B to a TZ89 at 6.5 MB/sec in tests very similar to what you describe. Two possibilities come to mind for the poor performance: (1) SCSI bus contention. Running the disk on the same SCSI bus as the tape drive is likely to cause performance problems. First off, the data must travel on the bus twice (reading from disk and writing to tape), doubling the raw bus bandwidth requirements. Second, disks and tapes sometimes do not coexist well on the same SCSI bus, resulting in substantially less net bus bandwidth than the spec would lead you to believe. The solution to this problem is to buy an additional SCSI bus controller and move either the disk or tape to the other bus. (2) Process quotas. Mistuned process quotas will cause BACKUP to stall internally when it runs out of resources; this can cause very poor performance. BACKUP's buffer pool is sized to match the process's WSQUOTA. However, for copying a large mostly contiguous file the size of the buffer pool is not very important. It is more important to have an adequate DIOLM and ASTLM; running out will cause stalls and poor performance. For documentation on quota recommendations, see section 10.7, "Setting Process Quotas for Efficient Backups", in the OpenVMS System Manager's Manual.
|