disk usage

[J Busch]

I have added 2 12H disk arrays to our DB server. The gives us a total of 5 12H disk arrays. 1000 gig usable space. ( i know there old but i got them at no cost). The probelm is now all my backups take 2 to 4 times longer for the same amount of disk space. ie backup speed went from 12 to 16 GIG per hour to 2 to 4 GIG per hour. I was using glance to watch the processes and i see the processes doing a lot of waiting for cache. How can i increase the disk cache or am i looking at the wrong thing.

Thanks...

[Rick Garland]

The 12H will do some stuff automatically, like change the RAID setting based on amount of disk usage.

By adding these disks could you have change the RAID setting?

[J Busch]

i added two complete arrays with 12 disk in the array. This gives us 5 arrays with 12 18 GIG disk in each. Each array is on its own scsi card. I use to see in glance disk IO goto 100% when i did a file system backup. Now i see disk IO around 40% wiht a lot of waits. I thought maybe i needed to increase the disk cache space in memory. This is just a guess though.

[Geoff Wild]

I tried to add this to your "cron logging " question - but posting was down:

CCMON would probably do the trick for you - designed to check consistency between nodes in a cluster -
but can also be used to check multiple servers (non MC/SG).

http://h71028.www7.hp.com/enterprise/downloads/ccmon-service-brief.pdf

http://h20219.www2.hp.com/services/cache/10973-0-0-106-169.aspx


Another option, try out cfengine:

http://www.cfengine.org/


And one more, write your own script that copy's crontabs to a central location,
compares them with the original, if different,
parses the .sh_history to see who changed it...etc...

Rgds...Geoff


As far as this question, are the disks striped at the hardware level?

Rgds..Geoff

[J Busch]

yes each array is broken down into 4 luns. and each lun is one VG with one LV.

i am leting the 12h handle the details. each lun is 45 gig.

example array 2
LUN VG LV Mount
lun 0 -- VGu21--lvu21 /u21
lun 1 -- VGu22--lvu22 /u22
lun 2 -- VGu23--lvu23 /u23
lun 3 -- VGu24--lvu24 /u24

[Hein van den Heuvel]

Off Topic a litlle...

Jim Busch wrote:
"each array is broken down into 4 luns. and each lun is one VG with one LV."

"example array 2
LUN VG LV Mount
lun 0 -- VGu21--lvu21 /u21"

If you go that route, why bother with LVM?
Seems to me the LVM layer does not add any value in your case. Just mkfs on the real device file (the one you presented to pvcreate)


Just curious,
Hein.

[Bill Hassell]

The 12H is not known for speed, especially if the 12H RAM is not maxed out. Also, the 12H switches to a RAID5 config once it is about 50% used, so if most of the disk space is occupied, the performance will also be a lot slower.

You can improve backup speeds by using alternate links (another SCSI card in your computer to access the same 12H). By using alternate links (in LVM), reads will be spread across both channels. This *may* improve the throughput, but not always. It depends on how random the data locations are.

Now you said backups were much faster. Prior to the 12H, were you on some fibre channel SAN and replaced the SAN with the 12H? In that case, the performance drop isn't as bad as I would expect. Or were the 12H boxes just added to an existing server and the backup is adding these disks to the total job? If so, the 12H is not capable of keeping a moderm DLT, Ultrium or AIT tape drive busy--they are just too slow. This in turn causes the tape drive to stop writing and require a resync cycle, perhaps several seconds. You could easily see a 10:1 drop in speed in those cases. This is a case where free is not always better.

[J Busch]

The solution was actually in OmniBack. Once we set OB2VXDIRECT=1 the backup speed went back to normal. Not sure why just adding two additional 12H caused the problem but it is now fixed.

To answer the LVM question it is the way it was done in the past by my predecessor. Not the best answer but I like things consistent so I carried it forward.

Thanks...