Backup account quotas - using ABS

[Tom Hartsook]

I have read several of the threads here regarding account quotas and BACKUP. We use ABS for backups, and the processes run as username ABS. So I thought that I would compare the quotas of ABS vs. the recommend quotas from "Setting Software Parameters for Efficient Backups". It seems that my ABS username has very large quotas.

So I wondered where my quotas "came from" since the ABS install creates the ABS username. The column labeled ABS-create are the values from the v4.4 kit.

Recmd Mine ABS-create
WSQUOTA 32768 65536 2048
FILLM 128 256 256
DIOLM 100 256 256
WSEXTENT 50000 131072 65536
PGFLQUOTA 100000 3000000 200000
ASTLM 1000 1024 1024
BIOLM 1000 256 256
BYTLM 100000 500000 500000
ENQLM 1000 2048 2048

Any comments? It seems that I should at least reduce WSQUOTA.

[John Gillings]

Tom,

The most important thing to know about BACKUP quotas is there are really only three things that you can or should vary. CPU, Memory and I/O Bandwidth.

CPU is governed by availability and priority. Few people change priority from the default.

For BACKUP memory is governed ONLY by WSQUOTA. WSEXTENT is effectively ignored. In the past, the advice has been "as much as you can", but recent experiments show that "less is more" in terms of performance. This is somewhat counterintuitive, but the person who came to this conclusion probably knows more about backup than the sum total of the rest of the planet ;-) The recommendation is now to start at about 10000, vary it up to 32K and pick the one that gives best performance.

The other quota that matters is FILLM, governing I/O bandwidth. Use it to throttle BACKUP if it's using too much system resources.

Set all other quotas according to the formulae in the backup manual (these give values that are effectively infinity).

[Tom Hartsook]

I have reduced WSQUOTA to 32k for this weekend.

It is interesting that the ABS kit creates the ABS username with a WSQUOTA of 2048. Does that seem really small?

[John Gillings]

Tom,

>ABS kit creates the ABS username with a WSQUOTA of 2048. Does that seem really small?

2048 pagelets is 1MB. That sounds like a buffer size to me ;-) That said, I'm told that 10K pages is sufficient for most systems.

Does ABS *specify* that as the WSQUOTA, or does it inherit the local system default? (sorry, I don't have an ABS kit to check for myself).

[Tom Hartsook]

I don't really know exactly how the "final" quota is determined. I have included below the DCL from the kit.

$ account_quotas = -
"/MAXJOB=0" + -
"/MAXACCTJOBS=0" + -
"/MAXDETACH=0" + -
"/PRCLM=8" + -
"/PRIO=4" + -
"/QUEPRIO=4" + -
"/CPUTIME=0" + -
"/FILLM=256" + -
"/SHRFILLM=0" + -
"/BIOLM=256" + -
"/DIOLM=256" + -
"/ASTLM=1024" + -
"/TQELM=255" + -
"/ENQLM=2048" + -
"/BYTLM=500000" + -
"/PBYTLM=0" +-
"/JTQUOTA=16384" + -
"/WSDEF=512" + -
"/WSQUO=2048" + -
"/WSEXTENT=65536" + -
"/PGFLQUO=200000"
$ !
$ VMI$CALLBACK UPDATE_ACCOUNT - 'abs_account_name' "''account_quotas'"

[Ian Miller.]

look at the PQL_M system parameters to ensure they are not raising the quotas higher than you want.

MCR SYSMAN PARAM SHOW /PQL

these parameters specify minimum values.

[GuentherF]

The real killer with BACKUP is DIOLM. In a 'perfect' scenario BACKUP swamps the I/O system with up-to DIOLM QIOs. As is known some controllers 'reset' with DIOLM > 1,000 and some quorum disks time out.

WSQUOTA betweem 10,000 to 30,000 pagelets is mostly sufficient to reach an optimum. Keep in mind that BACKUP uses eventually all of WSQUOTA to map its work buffers. At a certain larger value there's more CPU overhead because of many more buffers and the multi-buffer effect has already been reached with a smaller value.

All other limits should be way up to avoid a failure during the BACKUP run: PGFLQUOTA, ENQLM, ASTLM, BYTLM should all be way up. It doesn't hurt because these are just limits.

FILLM controls how many files are opened in parallel. If you don't care that a backup run may 'block' (exclusive open) too many files you can set FILLM in the hundreds. The number of open files is limited by WSQUOTA anyway because once there is no more buffer space available to map another file BACKUP waits until other ongoing files are completed before it opens another file.

So basically DIOLM < 100 and WSQUOTA 10,000 <> 30,000 should be all you care about.

/Guenther

[Tom Hartsook]

This is HP's response to the question of WSQUOTA=2048. This seems to be much smaller than any of the recommended values. 2048 pagelets seems small...
Tom

Using large limits/quotas for BACKUP mostly gives you less performance. This is why we selected a WSQUOTA of 2048.

BACKUP allocates virtual memory of WSQUOTA and divides it into WSQUOTA/(BLOCKSIZE/512) buffers. Before BACKUP starts any read I/Os from disk it opens up to FILLM files and maps there disk blocks (in file extents) into the buffers.

The larger the buffer space the longer this takes. At this point the tape is not getting any I/Os. Once all buffers have I/Os mapped BACKUP start multiple read I/Os from
disk. As soon as the first buffer is ready to be written to tape BACKUP issues an I/O to tape. Tapes have an onboard memory cache to avoid start-and-stop situations.

To keep this cache fills and the tape moving any longer non-I/O times should be avoided. With large BACKUP buffers (sized by WSQUOTA) there will be long delays between bursts of tape I/Os. Better is to have less (SMALL) BACKUP buffer space in which case BACKUP sends smaller bursts of I/O to the tape but also the time in between these bursts is much shorter (mapping/reading less files into BACKUP buffers). If the tape has enough data in the cache to avoid this I/O starvation it will not go into start-stop mode.

Regards,
ABS engineering

[comarow]

I thought Backup_06 and later ECO
solved the DIOLM problem.

[GuentherF]

With V8.3 there is a new BACKUP qualifier /IO_LOAD which specifies the maximum number of outstanding disk read I/Os. The default is 8.

This was backported to V7.3-2, V8.2 and V8.2-1.

All thanks to Guy Peleg.

/Guenther