Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

BACKUP/IO_LOAD - What Value

 
Robert Atkinson
Respected Contributor

BACKUP/IO_LOAD - What Value

I'm contemplating giving this new(ish) qualifier a go, but I'm not sure what value to start at (default is 8).

I'm running a fast EVA8000 on a quiet ES45. Any recommendations?

Rob.
12 REPLIES 12
Hoff
Honored Contributor

Re: BACKUP/IO_LOAD - What Value

Read this thread through:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1143614

More is not necessarily better as far as a storage controller is concerned, and the general recommendation of the fellow that implemented this knob (Guy Peleg) has classically been eight; the default. But you can try a few other values and see.

Do recognize that various newer storage controllers might not appreciate the blizzard of I/O that classic I/O on OpenVMS can generate; some newer widgets react, um, poorly to I/O overloads. I'm comparatively cautious around pushing most any FC SAN storage controller from most any vendor harder.

I prefer to treat /IO_LOAD as a governor, and not as an accelerator.
GuentherF
Trusted Contributor

Re: BACKUP/IO_LOAD - What Value

Run your backup script and watch disk I/O queue lengths with MONITOR DISK/QUEUE. An average queue length of 2-3 per spindle (*) is about right.

If less use a larger IO_LOAD value and if too large use a smaller value.

(*) If the disk presented is a RAID set then use 2-3 times number of disks in this RAID set.

No need to shove more down the throat of a disk drive than it can swallow at a time.

/Guenter
Hoff
Honored Contributor

Re: BACKUP/IO_LOAD - What Value

The EVA controller queue and particularly the queue-full that can arise over there is not what is visible with MONITOR and its view. This per my recollection and confirmed by Rob Brooks over in the cited thread. OpenVMS is fairly oblivious to what's going on downstairs in the EVA, which is both a benefit and a problem.
Steve Reece_3
Trusted Contributor

Re: BACKUP/IO_LOAD - What Value

I'm cautious these days on specifying any figures for pushing IO harder without knowing the complete environment. this is after putting bigger systems in at a client and then having the lock manager pull things down because I'd gone from a single node to a cluster.

If the default's 8, I'd probably be looking at that and then determining what else goes on and what other things are affected by me changing the value of the qualifier (i.e. don't just look at the backup, look at the effect it has on everything around it).

Steve
Robert Atkinson
Respected Contributor

Re: BACKUP/IO_LOAD - What Value

The reason I'm looking at this is because I've bought LTO4 drives, but they're running about the same speed as LTO3.

My EVA is practically idle most of the time, so if there's a way of pushing it harder and getting the transfer speeds up, then I'd like to pursue it.

Rob.

BTW - How are things down there?
Robert Atkinson
Respected Contributor

Re: BACKUP/IO_LOAD - What Value

Well, I tried all sorts of combinations. I changed IO_LOAD to 12, then 20, but without any difference.

I then tried increasing various UAF parameters, but again, it had no effect.

Think I'll just live with what I always knew - VMS is very poor at feeding fast tape drives!

Thanks for your responses. Maybe one day BACKUP will be less of a black art.

Rob.
Hoff
Honored Contributor

Re: BACKUP/IO_LOAD - What Value

I'd look to run the archive on the storage controller here, LBN disk to tape.

What's the LTO4 hooked to?

If hauling the blocks off disk and up into the host and back out to the controller is in order (and this and file fragmentation and such is particularly important when looking to keep a fast tape busy), then BACKUP is sensitive to the proportions among the process quotas. See:

http://labs.hoffmanlabs.com/node/49
Cass Witkowski
Trusted Contributor

Re: BACKUP/IO_LOAD - What Value

Is your CPU maxed out? If you are using BACKUP with the defaults then it is calculating CRC and group XORs.

You can set /GROUP=0. /CRC is a big hog of CPU. With todays tape and Fibre Channel technology I don't know what benefit using /CRC still provides. From my faulty memory, the undetected error rate is about 10E-34 and CRC just increases that to 10E-51. When you crunch the numbers, you would have to be backing up a very, very long time to get an undetected error with out using CRC.
GuentherF
Trusted Contributor

Re: BACKUP/IO_LOAD - What Value

The bug in EVA firmware that Hoff mentioned ealier has been fixed in recent formware verions.

With BACKUP performance one basic test _ ALWAYS - is doing the same backup to the null device: $ BACK disk: NLA0:dummy.

This gives a good idea about how fast files can be copied from the input disk.

One parameter which I found sensitive in my testing was WSQUOTA. Smaller values - YEAH - give better performance (less than 50,000 pagelets).

Ah, and just for fun try a BACKUP/PHYSICAL of that disk device to tape. That takes the file system overhead out of the loop.

/Guenther
Robert Atkinson
Respected Contributor

Re: BACKUP/IO_LOAD - What Value

Backup to NLA0 results in a 'invalid backup device' error.

Using '/NOCRC/GROUP=0' increases the backup speed from 00:01:54 to 00:01:52 - yep, 2 seconds. Was hoping for something more.

Rob.
Jim_McKinney
Honored Contributor

Re: BACKUP/IO_LOAD - What Value

> Backup to NLA0 results in a 'invalid backup device' error.

Could it be that you specified only the NL device and not a save_set on that device? Backup will want a save_set as the target. The general form of the command that you need to use is similar to the following {...you supply the qualifiers, filespecs, etc...}.

$ backup[/...} ddcu:{...} nl:t.t/sav{/...}
Cass Witkowski
Trusted Contributor

Re: BACKUP/IO_LOAD - What Value

Your backup is only taking 114 seconds?