openvms backup problem

[Domen Setar]

Hi,

I have a problem making backup on SAN (Clariion) disk. When I'm copying data to SAN disk, I reach about 1000 IO/s and bandwith of about 60 MB/s. If I want to backup data to SAN disk the throughput is rising to around 16000 IO/s (which is 98% read IO)and bandwith is falling to less then 1 MB/s. Can someone explain this behaviour of BACKUP command?
Thank you

Domen

[Hein van den Heuvel]

You wouldn't happen to be using BACKUP/DATA=COMPRESS right?
That might do a lot more read IOs than copy... if the data compresses a lot (test files!?)

1) What OpenVMS version ?

2) You mention "to SAN disk", but where is it FROM?
- what are the IO rates on the individual files input/output disks?

In the old days Backup would open up as many files as FILLM / ASTLM / memory would allow and would spend a good bit of time up front reading file headers and such to figure out what order to do IOs in. For non-simple disks this is less, or not at all, relevant.

Try REDUCING the quotas for the backup process

$ HELP BACK /IO reads...
/IO_LOAD[=n]
Beginning in OpenVMS Version 8.3, BACKUP is optimized to work more efficiently with new storage controllers. You can use the /IO_LOAD qualifier to increase or decrease the number of ..."

Hope this helps some,
Hein van den Heuvel
HvdH Performance COnsulting.

[Domen Setar]

I'm not using data compression.
I'm testing on OpenVMS V8.3-1H1 (on Integrity).
I was using many disks as a source. They were on EVA and CX4-120 storage.

I'l try to reduce quotas.

Domen

[Hoff]

Please post the exact DCL commands used here and the particular measurements received; what you're doing and what you're looking at for numbers.

AFAIK, BACKUP-based data compression (if that's what you are using here) is not officially supported by HP. AFAIK, it's (still?) an undocumented and latent feature.

Compression can be all over the map for its effectiveness; it's dependent on the input data. IIRC, the BACKUP /DATA_FORMAT=COMPRESS stuff is using zlib, which does fairly well for most compression.

[Hoff]

Ah, nevermind the compression stuff in the last. Missed the "not" in that reply.

But please post the commands and the measurements.

[Robert Gezelter]

Domen,

As has been noted, the precise BACKUP command would be helpful.

That will clarify many questions, including whether this is a disk-to-disk operation, or a disk-to-diskresident-saveset operation. There is a difference, and details are significant.

Also, what are the details of the source and destination disks. I have also learned to ask for a display of the RMS parameters (e.g., SHOW RMS) on the BACKUP process.

- Bob Gezelter, http://www.rlgsc.com

[Domen Setar]

I'm using very basic form of BACKUP command:

BACKUP source destination/SAVE

[Volker Halle]

Domen,

others have asked for precise information, please be more specific in providing the actual backup command used and information about the source and destination disk.

What are you trying to achieve ?

Volker.

[Domen Setar]

The precise command is:

$ backup $1$DGA405:[BACKUPI.COBISL_$l3...]*.*; bkpdsk1:[bkpnazaj]COBISL_$L3.SA;
/save

I'm measuring the performance on CX4-120. It's very difficult to proved you this data.

Source and destionation disks are on CX4-120. They are both RAID5 disks. They are independent, because they are in different RAID groups.
I tried many different source disks. But the problem is always the same.

I'm trying to get similar backup performance as I get using EVA disk as a destination backup disk for savesets (bandwith of about 50 MB/s).

I also tried a command:
$ backup $1$DGA405:[BACKUPI.COBISL_$l3...]*.*; bkpdsk1:[bkpnazaj...]
It works as expected: bandwith at about 50 MB/s.

[Volker Halle · Accepted solution]

Domen,

your BACKUP operation is reading and writing from/to the same SAN storage controller. BACKUP is known for being able to create massive IO loads and for - possibly - overloading the controller. This is what the /IO_LOAD qualifier has been created for.

Can you acccess EVA disks and CX4-120 from the same OpenVMS node (please specify the OpenVMS version and system type) ? If so, you could first try a backup operation reading from a EVA disk and writing to a CX4-120 disk.

When creating sequential backup savesets, it is also adviseable to use SET RMS/EXTEND=65535 to minimize file extend operations.

Volker.