- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- VMS Poor SDLT performance
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2004 04:38 AM
тАО09-15-2004 04:38 AM
Re: VMS Poor SDLT performance
And before speculating/tweaking the tape side do a backup to the null device to give you an idea where the bottleneck might be. In most BACKUP performance cases I have been involved it was the disk input.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2004 10:56 AM
тАО09-15-2004 10:56 AM
Re: VMS Poor SDLT performance
I'm not understanding what you mean by thrashing of the HBA. From my understanding of Backup there is one buffer that in one phase of backup there is a lot of disk I/Os queued up to get data off the disk and into the buffer. Once the buffer is full then that activity stops and the data is sent from the buffer to the tape drives. Which would give you a sort of see-saw effect of the disk is busy and tape is idle then the tape is busy and disk is idle.
I don't know if backup is capable of double buffering where one buffer is being filled from disk and one is being written to tape. It may be so but the AS1200 may not have enough oomph to do it fast enough to keep up with todays tape drives. I didn't know the AS1200 supported the FC HBAs.
If the CPU is your limiting factor you may have to just play with the buffer size WSMAX WSEXTENT to see what setting gives you the best throughput.
Cass
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2004 06:15 PM
тАО09-15-2004 06:15 PM
Re: VMS Poor SDLT performance
In this situation, BACKUP does a lot of I/O through one fibre channel adapter to the storage array to fill its in-memory buffers (while the tape drive is idle). Next, it throws all data at once over the other fibre channel adapter to the tape drive (while the disks are now idle). After it has finished, BACKUP starts again to excruciate the disks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-15-2004 06:57 PM
тАО09-15-2004 06:57 PM
Re: VMS Poor SDLT performance
I think I have to agree with Cass on this.
It is INTENDED BEHAVIOR for Backup to first do ONLY a lot of disk I/O, and thereafter ONLY a bulk of tape I/O.
... and the disk I/O is even divided in two separate phases: first, from Index info, the layout of the buffer is determined, with every file segment's pointing to its logically-contigous location IN the buffer.
Then, ALL those file segments are specified in ONE I/O request (maybe split up again by hardware limits, but that is XQP, not BACKUP) to force the disk into heavy-load-mode, so as to optimise head-movements, ie, fill the predetermined buffer in the order of disk-layout, random with respect to buffer layout, and so reduce the biggest time loss: waiting for head-movements (at the cost of memory and some CPU).
So, if the memory available to backup is not too small, you will see alternating DISK- and tape-I/O's.
Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2004 01:52 AM
тАО09-16-2004 01:52 AM
Re: VMS Poor SDLT performance
Thanks again to all as everything stated is right on the money.
I continue to investigate only because I feel this process can be better/faster.
Others in similar environments are seeing 60-80GB/hr not my dismal 16-20GB/hr.
Increasing system resources, i.e. buffers, quotas etc, actually slowed down the process. It did open up the throttle on reads but simply increased the io queue, (actually reading too fast).
I am planning on testing some read speeds by using null as the output device. Just to see what top read speed is.
I also plan on doing some timings to the same tapes from an ES40 to see if my little AS1200 is just going as fast as it can.
Thanks to all for the assistance !!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2004 02:53 AM
тАО09-16-2004 02:53 AM
Re: VMS Poor SDLT performance
I can't see that he said he found the behaviour good (and I don't think I explicitly said I found it bad, either).
And why do you think this behaviour is good when it puts the tape drive into a start/stop mode which makes everything go slower? An SDLT 1 tape drive can do about 11 MegaBytes/second, an SDLT 2 drive can do 16 MegaBytes/second to media. In the storage trainings I got told that for compression you need about 3-times the data rate to keep the tape moving.
I don't see what model of tape drive Tim has. Remember that the little AS1200 is already running at 100% CPU.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2004 03:38 AM
тАО09-16-2004 03:38 AM
Re: VMS Poor SDLT performance
High DIOLM can cause some disk I/O
subsystems to collapse (resets, hangs, slow
downs). DIOLM=100 is more than enough to
allow RAID sets and optimizing disk
controllers to have something to "work with".
WSQUOTA: The larger WSQUOTA the longer it
takes BACKUP to map files into its buffers
sized by WSQUOTA. During this time the tape
drive remains idle. WSQUOTA=(10000..40000)
is an optimum range.
Here's why: Once BACKUP has completed
mapping files into its buffers and has
issued ALL I/Os in a tight loop disk I/Os
start filling the buffers. Once the first
buffer in order is ready to go (files are
stored in the save set in alphabetic
order which is not necessarily the
order files are stored on disk)
it is queued to the tape drive. The larger
WSQUOTA the more "UN"-likely it is that the
first buffer fills first thus delaying I/O
to the tape drive. Tape drives typically
have an onboard cache of multiple MBs. Once
the data is in this cache the host
application (BACKUP) gets a complete I/O
signalled. And BACKUP will not start another
disk scan until all tape I/Os have
completed. So with a nicely small WSQUOTA
the tape drive has still work to-do while
BACKUP thinks the tape drive is
done and starts another disk scan. With a
large WSQUOTA the tape's write-back cache is
nearly unnoticeable.
And really...DO A TEST RUN TO THE NULL
DEVICE!!! It tells whether-or-not the disk
input is a limiting factor.
And do yourself another favor...DO A TEST
RUN /PHYSICAL DISK-TO-TAPE!!! It tells
whether-or-not your overall infrastructure
(drives, busses, network) have a bottleneck.
With an SDLT1 and compaction you should
reach 20+MB/sec at least.
/Guenther
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2004 03:52 AM
тАО09-16-2004 03:52 AM
Re: VMS Poor SDLT performance
Well, that's what I already wrote on Aug 8, 2004 11:01:39. It is good to see that a real expert[*] confirms this.
I remember that I wrote something similar to comp.os.vms some years ago and I almost got stoned to death...
It about time that VMS engineering works
- on the documentation for BACKUP tuning.
- on BACKUP itself again to teach it double-buffering.
[*] I do know Guenther - this is not meant cynical!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2004 04:02 AM
тАО09-16-2004 04:02 AM
Re: VMS Poor SDLT performance
you posted DIOLM = 2048 not 4096;
Guenther posted DIMLM = 100.
I Guess Tim need know what's the best value for backup.
Antonio Vigliotti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2004 04:33 AM
тАО09-16-2004 04:33 AM
Re: VMS Poor SDLT performance
The chapter "Using Backup" in the "System
Manager's Manual" has been updated for V8.2.
I am not sure how much clearer it is now
on this complex issue.
The recommended value for DIOLM is 100 and the recommended start-tuning value for WSQUOTA is 10,000 pagelets.
WSQUOTA is the most sensitive tuning
parameter for BACKUP. DIOLM and FILLM come
next but are far less sensitive. The other
ones just need to be larger to avoid BACKUP
to run into some quota/limit starvation and
take a shortcut or wait to overcome the
temporary shortage.
To make sure the current BACKUP scheme is
not interrupted by running out of some other
quota:
FILLM = 100 (start value, incr. by 10,
should be < CHANNLECNT - 20)
PGFLQUOTA >= WSQUOTA + 25000
ASTLM >= DIOLM + 100
BIOLM >= FILLM + 100
BYTLM >= 256 * FILLM + 6 * DIOLM + 10000
ENQLM >= FILLM + 100
But before you start changing your quotas
and limits...TIME A BACKUP TO THE NULL
DEVICE and TIME A /PHYSICAL to tape!!!
Without these two simple tests you have no
idea about your current limits.
/Guenther