Backup account quotas for SAN tapes and EVA disks

[Clark Powell]

What's the popular wisdom reguarding backup account quotas and SAN tape drives and EVA disks. We were told to detune our backup accounts to achieve more stable backup of EVA disks but up till now using our old, maxed out quotas, we never encountered any problems and still saw about 40 to 80 Gb/Hr performance. Last week, however, we started to see our LTO HP Ultrium 2 drives go in and out of mount verify and even disks started to do the same. Even thought HP replaced the scsi module on the tape library (6060A) and two drive, the problem did not go away. So we changed our backup account quotas (on a GS1280, no problem were reported on the ES45's) and the problem went away.
FILLM 475 to 12
DIOLM 32757 TO 50
ASTLM 32757 TO 600

Has anybody seen anything like this?

[Sheldon Smith · Accepted solution]

I am sure other people will jump in here, but be aware you are not "detuning" your backup account quotas; your problem is "dueling caches". The VMS Backup utility was designed for dumb (dumb dumb) hard drives and even dumber tape drives. Not for hardware with "intelligent" cache.
Same issue with XP arrays. You need to have Backup tuned for intelligent hardware. John Fisher wrote a presentation on "Optimizing OpenVMS hosts for XP disk arrays" (see attachment). I think he also has a paper on EVA disk arrays.

[John Gillings]

Clark,

Current thinking on BACKUP quotas is "less is better", particularly for WSQUOTA. Logic says it should be high, but experiment has proven that the optimum value is around 10000:

WSQUOTA:
â ¢ Initial value of 32,768 pagelets
â ¢ Vary in increments of 5,000
â ¢ Values over 100,000 typically result in worst performance
FILLM:
â ¢ Equal to 100 (mostly sufficient)
â ¢ Less than CHANNELCNT - 20
â ¢ Vary in increments of 10
â ¢ Use larger values if input disk contains many very small files or is highly fragmented
â ¢ Effectiveness limited by WSQUOTA

DIOLM:
â ¢ Equal to 100 (mostly sufficient)
â ¢ Vary in increments of 10
â ¢ Larger values can cause disk I/O subsystem hangs or resets without any performance advantage

ASTLM has little or no influence.

For EVAs there has been a fair amount of work on the throttling behaviour when you push them to their limits. Some older versions had rather drastic measures to slow down OpenVMS - all would be fine until you hit the wall, then things would take a while to recover. Make sure you're up to date with all relevant patches.

Also make sure you keep some statistics for your backup runs (install T4?) so you can check if any changes you make have been positive or negative.

See the most recent "System Managerâ s Manual
Volume 1: Essentials, Chapter 11 Using Backup, Section 11.7 Setting Software Parameters for Efficient Backups"

[Guy Peleg]

I usually recommend:

FILLM=100
DIOLM=150
BIOLM=150
WSDEF=10000
WSEXTENT=20000
WSQUOTA=30000

You did not mention the O/S version but
I assume V7.3-2. Make sure you apply
the latest BACKUP ECO (VMS732_BACKUP-V0500)
it contains several performance improvements
including a redesign of the algorithm for
reading data from the source disk (optimized
for EVA/XP based controllers).

Guy Peleg

[Guy Peleg]

...I meant

wsdef=10000
wsquota=20000
wsextent=30000

Thanks John for bringing this to my
attention.

Guy

[Uwe Zessin]

Why do you bother and try to set WSEXTENT to an explicit value? It's my experience that the system parameter PGL_MWSEXTENT(sp?) is set to WSMAX by AUTOGEN anyway since OpenVMS VAX V6.0.

Or did this change? - I have not checked for a while.

[comarow]

You may well encounter a system, inherited
or the value has been sitting there through
the cobwebs of time that someone has
hard coded a value of pql_mwsextent, to what
they thought at the time was a generous
value. It probably was in 4.4. Thus,
that version of modparams has survived the
rivers of times, upgrades, system managers,
and thus, it becomes useful not to assume
pql_mwsent is actually equal to wsmax.

What should, and what is, are often not the same. Otherwise we'd be seeing VMS on everyone's desk...

[Thomas Ritter]

Uwe,(same name as my uncle) sort uses SYS$ADJWSL to make decisions about were to sort. By having *wsextent set to WSMAX will tell sort it has the memory available. This can be a big problem if you relational database where lots of sorting occurs. In general wsextent set to wsmax can have nasty side affects.

[Uwe Zessin]

Please make some efford to try to understand what I wrote:

$ write sys$output f$getsyi("version")
V7.3-2
$
$ search sys$system:modparams.dat,setparams.dat pql_mwsextent,wsmax

******************************
SYS$SYSROOT:[SYSEXE]MODPARAMS.DAT;4

MAX_WSMAX = 157792 ! Advanced Server for OpenVMS 9-MAY-2005 07:55:17
MIN_WSMAX = 10604 ! Advanced Server for OpenVMS 9-MAY-2005 07:55:17

******************************
SYS$SYSROOT:[SYSEXE]SETPARAMS.DAT;10

set WSMAX 98304
set PQL_MWSEXTENT 98304
$

This is neither an old system nor did I hard-code!!

-----
And see this:
http://h71000.www7.hp.com/wizard/wiz_4523.html
""Since OpenVMS V6.0, AUTOGEN will, by default, set PQL_MWSEXTENT to WSMAX. On OpenVMS/Alpha, by default, AUTOGEN sets WSMAX to one quarter of physical memory, in your case 64MB, or ~128000 pagelets. Now, since PQL_MWSEXTENT is the MINIMUM WSEXTENT for any process on your system, all processes will be granted that quota, regardless of the value in the UAF.""

[Clark Powell]

thank you

[John Gillings]

Re: Uwe, Thomas,

You only get nasty side effects from WSEXTENT=WSMAX if PGFLQUOTAs are too small (ie: smaller than WSEXTENT).

> http://h71000.www7.hp.com/wizard/wiz_4523.html

I wrote that answer in June 2000, and disk space is even cheaper now. Please don't limit the performance of your systems for want of a few cents worth of disk space. Make sure your systems have adequate page file space and PGFLQUOTAs!

Maybe set PQL_MPGFLQUOTA to 4*WSMAX?