topic performance i/o in Operating System - HP-UX

performance i/o

Fredy Correa — Tue, 06 Sep 2005 10:57:35 GMT

I have a doubt... the machine is a HP rp3410 with a storage unit SAM, the discs are formed in way RAW. The question is in which it forms handles better to the load the controllers, when having several volumenes and 10 internal discs, distribute the access by disc or volume? send the distribution... wanted to them to know his opinion of the best form so that i/o is but fast.

DATOS1 /dev/vgcx001/rlvdwmpr012 1996
DATOS1 /dev/vgcx001/rlvdwmpr013 1996
DATOS1 /dev/vgcx001/rlvdwmpr014 1996
DATOS1 /dev/vgcx001/rlvdwmpr015 1996
DATOS1 /dev/vgcx001/rlvdwmpr016 1996
DATOS1 /dev/vgcx001/rlvdwmpr017 1996
DATOS1 /dev/vgcx001/rlvdwmpr018 1996
DATOS1 /dev/vgcx001/rlvdwmpr019 1996
DATOS1 /dev/vgcx001/rlvdwmpr020 1996
DATOS1 /dev/vgcx001/rlvdwmpr021 1996
DATOS1 /dev/vgcx001/rlvdwmpr022 1996
DATOS1 /dev/vgcx001/rlvdwmpr023 1996
DATOS1 /dev/vgcx001/rlvdwmpr024 1996
DATOS1 /dev/vgcx001/rlvdwmpr025 1996
DATOS1 /dev/vgcx001/rlvdwmpr026 1996
DATOS1 /dev/vgcx001/rlvdwmpr027 1996
DATOS1 /dev/vgcx001/rlvdwmpr028 1996
DATOS1 /dev/vgcx001/rlvdwmpr029 1996
DATOS1 /dev/vgcx001/rlvdwmpr030 1996
DATOS1 /dev/vgcx001/rlvdwmpr031 1996
DATOS1 /dev/vgcx001/rlvdwmpr032 1996
DATOS1 /dev/vgcx001/rlvdwmpr033 1996
DATOS1 /dev/vgcx001/rlvdwmpr034 1996
DATOS1 /dev/vgcx002/rlvdwmpr001 1996
DATOS1 /dev/vgcx002/rlvdwmpr002 1996
DATOS1 /dev/vgcx002/rlvdwmpr003 1996
DATOS2 /dev/vgcx002/rlvdwmpr004 1996
DATOS2 /dev/vgcx002/rlvdwmpr005 1996
DATOS2 /dev/vgcx002/rlvdwmpr006 1996
DATOS2 /dev/vgcx002/rlvdwmpr007 1996
DATOS2 /dev/vgcx002/rlvdwmpr008 1996
DATOS2 /dev/vgcx002/rlvdwmpr009 1996
DATOS2 /dev/vgcx002/rlvdwmpr010 1996
DATOS2 /dev/vgcx002/rlvdwmpr011 1996
DATOS2 /dev/vgcx002/rlvdwmpr012 1996
DATOS2 /dev/vgcx002/rlvdwmpr013 1996
DATOS2 /dev/vgcx002/rlvdwmpr014 1996
DATOS2 /dev/vgcx002/rlvdwmpr015 1996
DATOS2 /dev/vgcx002/rlvdwmpr016 1996
DATOS2 /dev/vgcx002/rlvdwmpr017 1996
DATOS2 /dev/vgcx002/rlvdwmpr018 1996
DATOS2 /dev/vgcx002/rlvdwmpr019 1996
DATOS2 /dev/vgcx002/rlvdwmpr020 1996
DATOS2 /dev/vgcx002/rlvdwmpr022 1996
DATOS2 /dev/vgcx002/rlvdwmpr023 1996

Re: performance i/o

Mel Burslan — Tue, 06 Sep 2005 13:11:02 GMT

I know this is not the answer that you are looking for but, when you talk about databases with 10 or more disk volumes and you are worried about disk performance, in the same sentence with server model rp3410 is making it totally irrelevant. In my opinion, if you are talking about a big database and disk i/o performance issues, you need to get rid of the desktop workstation replacement class rp3410 and go up to something like rp4440. After than, you can worry about the disk I/O performance.

Re: performance i/o

Steven E. Protter — Tue, 06 Sep 2005 13:21:31 GMT

I don't thing the machine in question is right for large database service.

That being the case, raid 1 is recommended for data,index and hot logs that get written to a lot.

You need data protection. Raid 1 will provide decent performance so long as the database is not too large.

SEP

Re: performance i/o

Fredy Correa — Tue, 06 Sep 2005 14:15:58 GMT

I UNDERSTAND THAT THIS MODEL IS NOT RECOMMENDABLE FOR GREAT DATA BASES, THE QUESTION IS, At LEVEL DE UNIX FOR The ACCESSES OF DISCS IT IS BETTER TO HAVE VOLUMENES Or DISCS RAW?

Re: performance i/o

A. Clay Stephenson — Tue, 06 Sep 2005 15:03:42 GMT

The overhead of LVM is so small as to be negligible. All that is happening is one extra level of i/o indirection in the device switch table so that logical block 5000, for exapmle, is translated into block 645 of /dev/rdsk/cXtYdZ. In theory, if you could balence the i/o perfectly, raw disk would be better but the real world differences are extremely difficult to measure and balancing is much easier and more convenient with logical volumes.

I haven't used actual raw disk i/o for database in years but instead have used logical raw volumes.

Even more surprising (unless you have multiple hosts accessing the data; e.g Oracle RAC), you might just find that fully cooked i/o gives better performance. Also, don't overlook that you can use the OnlineJFS vxfs mount options convosync=direct,mincache=direct to completely bypass the buffer cache and yet allow you to use regular files.

You really need to do some measurement with your hardware and database because there is no "one size fits all" answer.

Re: performance i/o

TwoProc — Tue, 06 Sep 2005 17:01:58 GMT

In response to your last posting:
If I was choosing raw disk vs lvm - both w/o file systems - I'd definitely choose lvm. This is because while still having the advantage of speed in raw/io you'd also have the flexibility of lvm. You can mirror disks, stripe for speed, use lvm commands to move/duplicate data, etc. I'm pretty sure that lvm itself poses very little overhead on the system, especially if not responsible for a mirror. Also, consider that you'd have to put all of your data into only 10 tablespaces (each disk). With lvm you'd have the ability to create new tablespaces as needed/wanted by just getting a new lvol created out of an existing vg.

Anyway, I vote for using lvm.