topic Re: BACKUP/IO_LOAD - What Value in Operating System - OpenVMS

BACKUP/IO_LOAD - What Value

Robert Atkinson — Mon, 29 Jun 2009 13:06:22 GMT

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.

Re: BACKUP/IO_LOAD - What Value

Hoff — Mon, 29 Jun 2009 14:18:09 GMT

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.

Re: BACKUP/IO_LOAD - What Value

GuentherF — Mon, 29 Jun 2009 19:50:26 GMT

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

Re: BACKUP/IO_LOAD - What Value

Hoff — Mon, 29 Jun 2009 20:38:32 GMT

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.

Re: BACKUP/IO_LOAD - What Value

Steve Reece_3 — Tue, 30 Jun 2009 09:54:41 GMT

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

Re: BACKUP/IO_LOAD - What Value

Robert Atkinson — Tue, 30 Jun 2009 10:05:36 GMT

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?

Re: BACKUP/IO_LOAD - What Value

Robert Atkinson — Tue, 30 Jun 2009 13:13:36 GMT

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.

Re: BACKUP/IO_LOAD - What Value

Hoff — Tue, 30 Jun 2009 16:23:59 GMT

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

Re: BACKUP/IO_LOAD - What Value

Cass Witkowski — Tue, 30 Jun 2009 17:40:02 GMT

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.

Re: BACKUP/IO_LOAD - What Value

GuentherF — Tue, 30 Jun 2009 17:55:39 GMT

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

Re: BACKUP/IO_LOAD - What Value

Robert Atkinson — Wed, 01 Jul 2009 09:49:03 GMT

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.

Re: BACKUP/IO_LOAD - What Value

Jim_McKinney — Wed, 01 Jul 2009 10:53:18 GMT

> 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{/...}

Re: BACKUP/IO_LOAD - What Value

Cass Witkowski — Wed, 01 Jul 2009 14:50:53 GMT

Your backup is only taking 114 seconds?