backup qualifiers

[Hein van den Heuvel]

For single large file copy, the preferred tool ought to be copy, and it has proven to be faster than backup in a few tests.

What VMS version? Copy increased its IO size in recent version and with that ought to be the faster tools.

The whole exercise is rather dependend on all sorts of parameters I am afraid. Backup will issue a batch of IOs one the input side to fill its IO buffers and then wait for them all all to complete, next start to write synchroneously. No overlap :-(. (Yes, there is room for improvement...)
The batch size depends on process quotas like ASTLM, DIRIOLM, WS,...

Copy simply does read, write, read, write....

It will depend on things like fragementation and disk controller smarts which one will win. The controller may recognizes the pattern and starts read-ahead for the copy case, but the multiple IOs for backup may muddy the waters. Also, the deep queue that backup can create can throw controllers into a temporary state of shock it seems :-).

Hope this helps some,
Hein.

[Marc Van den Broeck]

Hein,

thx for info.
vms version: V7.2-1

Rgds
Marc

[Hein van den Heuvel]

We had an internal report/experience where BACKUP from an XP was slow compared to copy.

There the deep queue / high parallelism saturated the XP front end / cache algoritmes.

The workaround was to drop DIOLM and PQL_MDIOLM to 8 from the current recommendation of 100. The IOPS jumped from 300 to 2,000.

THey also found that the XP, and I imageing other cached controllers also, really like IO sizes in powers of 2, and transfers alling at powers of 2. On VMS that would suggest clustersizes of 4, 8, 16, 32, 64 to at least get the first IOs started alligned.

fwiw,
Hein.

[comarow]

Large cluster sizes on the backup device will help. Huge cluster size.
/block=32768 would be a good starting size.

The original files should be defragmented.

Now, depending on the device to be backed up to, working sets, diolim are changed.
For example keep diolm to <32 on a san disk or the cache will thrash, and 4096 on a scsi disk.


We need the devices and controllers and files.

[Wim Van den Wyngaert]

/block won't help because it is a save set qualifier.

Avoid raid-5 on the destination disk and monitor process quota.

I vaguely remember that very high quota may decrease performance.

Wim

[Wim Van den Wyngaert]

On a server in use, I got a 5 to 10% gain in wall time when I did set file/cac=no for the source file and the destination directory. The file was only 300 MB and extended file cache was in use.

FTP between 2 cluster nodes arrived at about half the speed.

Wim

[Ian Miller.]

Its curious that disabling caching for the file affects the result if BACKUP bypasses XFC.

Current recommended values for process quotas for running backup are lower than previously recommended.

[Wim Van den Wyngaert]

Ian,

Found this on the subject of 7.2-1

BACKUP uses the XFC cache. This can impact the performance of other applications that use the XFC cache. This change keeps BACKUP from monopolizing the XFC cache.

So, it depends on which patches are installed ??? And is it completely disabled ?

I tested it on 7.3 with XFC 2.0 installed but not 3.0 or higher. I did each test 2 times and got 5 and 10% better performance.

Wim

[Wim Van den Wyngaert]

Note that I did the test on a mchine with VCC_FLAGS on 1, thus not XFC but VCC was active.

Wim

[Marc Van den Broeck]

Wim,

I have VCC_FLAGS also on 1. This are my vcc parameters:
VCC_FLAGS 1
VCC_MAXSIZE 100000
VCC_MAX_CACHE -1
VCC_MAX_IO_SIZE 127
VCC_MAX_LOCKS -1
VCC_READAHEAD 1
VCC_WRITEBEHIND 1
VCC_WRITE_DELAY 30

Marc