Operating System - OpenVMS
1748209 Members
2813 Online
108759 Solutions
New Discussion юеВ

Re: Diagnosing a performance bottleneck in BACKUP/LIST

 
abrsvc
Respected Contributor

Re: Diagnosing a performance bottleneck in BACKUP/LIST

Wouldn't volume settings like /data_check and /highwater make a significant difference?

What do the disk characteristics look like?

Dan
David Jones_21
Trusted Contributor

Re: Diagnosing a performance bottleneck in BACKUP/LIST

My only guess would be it had something to do with caching. Write behind is easier than read ahead.
I'm looking for marbles all day long.
Art Wiens
Respected Contributor

Re: Diagnosing a performance bottleneck in BACKUP/LIST

"I'm told the system only has to run until the end of the year but if it looks like being longer than that I'll see what if I can talk them into a better tape drive."

And we're on year 8 of the bold 3-5 year plan to replace all our VMS systems. They haven't accomplished much.

Always the same tough questions have to be asked of the business ... how much money is lost per hour/day/week when this 10+ year old production hardware goes south?

Cheers,
Art

p.s. don't forget to test an actual restore. A backup listing should give you some confidence that there's something valid written on that piece of plastic but ... ;-)
Paul Jerrom
Valued Contributor

Re: Diagnosing a performance bottleneck in BACKUP/LIST

Isn't it amazing how many people answer different questions to the one being asked?

So if I understand right, it is taking 4-5 hours to read data from disk and write it to tape. It is taking double that time to read from the tape and write to the disk.

A similar backup style on one of my sites shows the backup time to be about double the listing time, so your times seem out.

Presumably then, it's an issue of either reading from the tape or writing to the disk. If the former, then maybe someone local can listen to the drive and see if it is constantly moving, or whether it is going back and forth. Might be old knackered tapes (although I'd expect an increase in error count). If the latter, maybe the Mylex has caching disabled or is waiting for writes to complete to the disk before continuing? Any chance one of the R5 disks has failed? This would cause big overheads in calculating values from parity data. Not sure if a failed R5 disk on a Mylex flags anything to VMS. Maybe set RMS extent to 200k, if that is what it will use?
[BTW, this customer wouldn't happen to be in Auckland, would it?]
Have fun,

PJ
Have fun,

Peejay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If it can't be done with a VT220, who needs it?
Jeremy Begg
Trusted Contributor

Re: Diagnosing a performance bottleneck in BACKUP/LIST

Hi Paul,

No surprised at all :-)

This system is located in Christchurch, it got moved from one building to another after the earthquake there rendered the first building unsafe. As it happens, the people in the "new" building are the ones who actually use the system.

I think your comment about a failed disk in the RAID5 set might be the solution. I've re-checked OPERATOR.LOG for SWXCR messages and yes, there is a failed drive. (I remember bringing this to their attention before the earthquake and thought it had been fixed, but now I've found out it wasn't. Some people don't deserve to have computers.)

Next step: get HP to replace the failed disk(s).

Thanks,
Jeremy
Bob Blunt
Respected Contributor

Re: Diagnosing a performance bottleneck in BACKUP/LIST

AND, possibly, get a copy of the SWXCR utilities loaded on the system so you can get a better idea about the drives using swxcrmgr online. Writing to a RAID unit with a failed drive will certainly be much slower. Definitely capture a BACKUP before any work gets done on that RAIDset but I know you knew that already.

Then I'd compress the data on that drive since their free space is pretty well sliced and diced (or, maybe, find another more dedicated space like making a LD partition or RAM disk just for the listing for top speed.

I may have a copy of the SWXCR utils...

bob
GuentherF
Trusted Contributor

Re: Diagnosing a performance bottleneck in BACKUP/LIST

Write to RAID-5 in redundant state:

- read old data (maybe from cache)
- read old parity (maybe from cache)
- write new parity
- write new data

RAID-5 array reduced:

if parity disk for this write is missing
- write data
else if data disk for this write is missing
- read old parity (maybe from cache)
- write new parity
else
- read old data (maybe from cache)
- read old parity (maybe from cache)
- write new parity
- write new data

So writing to a reduced array is never slower than writing to a redundant array.

/Guenther