[Info-vax] NetBackup Performance Woes

[George Cornelius]

In article <mjiudb$gki$1 at dont-email.me>, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
> On 2015-05-20 21:15:40 +0000, Geek Nerdly said:
> 
>> It's very consistent:
>> 
>> Queue Length spikes to as high as 50 and does not dip below 3 on node B 
>> (where backup runs) while backup is running, where at the same time on 
>> node A Queue Length hovers between 0 & 1.
> 
> That's a disk volume that's saturated, or potentially an HBA or storage 
> controller that's saturated.
> 
> Any disk I/O queue length past 0.5 means that half of all I/O requests 
> are waiting.

I can remember routinely seeing queue lengths peak at 400 or more
ordinary VMS backup operations.  It seems that in order to attempt
to guarantee streaming tapes were not in washboarding mode, the
maintainer (was it Keith Walls?) did an overhaul resulting in hundreds
of I/O's being queued ahead of time before starting the tape in
motion.

I eventually came to the conclusion that the whole thing may not
even have been AST based and that the idea was to blast a lot of
data at the tape drive, then: stop, reload, and resume fire.

Or, perhaps it was an attempt to recognize that some systems
were just too slow to keep the tape truly streaming, but at least
you could blast enough at the drive at one time to keep it from having
to go into a repositioning phase far less often.

Probably better now, but if you queue a lot of I/O's ahead as part
of your design then you will have queue depths.

And of course you will drive anyone else trying to get work done on
the volume out of their minds.

[sorry to respond to such an old post - I'm way behind on reading the group]

George

> Your backup tool has sufficient quotas and an I/O design that allows 
> this load to be generated, unfortunately.
> 
> For an example of a throttling mechanism within the OpenVMS BACKUP 
> tool, see HELP BACKUP /IO_LOAD on OpenVMS V8.3 and later.
> 
> Given the disk is apparently active at the time of the backup, the 
> resulting archived may not be entirely consistent nor entirely 
> reliable, either.