disk layout/striping questions part 2
(Sorry for posting this a 2nd time - I was hoping for a few opinions.) As part of my 7.22 -> 7.31 upgrade, I am redoing the disk layout. A few questions for the gurus: Environment: HP-UX 10.20 HP quad processor K260 1 gig RAM 20 gig database 3 or 4 mirrored singleton disk drives I will be using HP-UX LVM to create raw 2 gig logical volumes on the drives (which are all larger than 2 gigs). I will then create my chunks in these volumes. Most of the chunks will be 2 gigs, but if smaller (ala detached indexes or single table dbspaces), the offsets will work. Question: Is it better to create lvm volumes striped across the disks and then just create chunks one after another at those volumes? (The OS is striping) OR Is it better to create lvm volumes on single disks (no lvm striping), then create the informix chunks one after another across the disks/volumes? (Informix is striping). Please don't tell me that striping across the disks is the answer - I already know that. _How_ should I stripe across the disks? And why? Should LVM handle the details, and the OS figures things out, or should I create chunks in order across the disks/volumes myself? LVM will have to be involved anyways so that I can break up the large disks into manageable 2 gig logical volumes. Since these are raw chunks, should I involve the OS as little as possible? I am leaning towards Informix mirroring rather than the HP-UX/Mirror. I will probably utilize some expression-based fragmentation. Any opinions? Thanks Allen Jantzen, DBA Ned Davis Research
Allen W. Jantzen wrote: > > (Sorry for posting this a 2nd time - I was hoping for a few opinions.) > > As part of my 7.22 -> 7.31 upgrade, I am redoing the disk layout. > A few questions for the gurus: > > Environment: > HP-UX 10.20 > HP quad processor K260 > 1 gig RAM > 20 gig database > 3 or 4 mirrored singleton disk drives > > I will be using HP-UX LVM to create raw 2 gig logical volumes on the > drives (which are all larger than 2 gigs). I will then create my > chunks in these volumes. Most of the chunks will be 2 gigs, but if > smaller (ala detached indexes or single table dbspaces), the offsets > will work. > > Question: > Is it better to create lvm volumes striped across the disks and then > just create chunks one after another at those volumes? (The OS is > striping) > OR > Is it better to create lvm volumes on single disks (no lvm striping), > then create the informix chunks one after another across the > disks/volumes? (Informix is striping). > > Please don't tell me that striping across the disks is the answer - I > already know that. _How_ should I stripe across the disks? And why? > Should LVM handle the details, and the OS figures things out, or > should I create chunks in order across the disks/volumes myself? > LVM will have to be involved anyways so that I can break up the large > disks into manageable 2 gig logical volumes. > > Since these are raw chunks, should I involve the OS as little as > possible? > > I am leaning towards Informix mirroring rather than the HP-UX/Mirror. > I will probably utilize some expression-based fragmentation. Use hardware/firmware mirror, if available, OS mirror next, Informix mirror last as a set oc choices, stripe across the 4 mirrored pairs using the LVM with a stripe block size of 8 or 16K (most LVMs recommend 64K which works fine for filesystems but is too large for efficient Informix chunks). If your volume manager supports it, stagger the starting drive pair of each successive chunk so that they do not all begin on the same drive. (NB - some LVMs are even capable of alternating the starting drive of each successive stripe within each set which can improve sequential processing speeds because reads can be overlapped better.) During initial data load this will spread the writes more evenly. Once the tables are mainly populated it should no longer matter but it will speed initial loading. Be sure that you are striping mirrored pairs and not mirroring stripe sets as the latter is MUCH slower and riskier to recover if a drive fails. If your LVM does not handle staggering the stripes directly you can simulate it by making sure that each stripe is one block short or one block over of 2GB since 2GB is evenly divisible by 4 times the block size for 8, 16, 32, or 64K blocks (if you make the size over 2GB you will waste a bit but chunks will be max size). Art S. Kagel
We have a very similar setup, and I am currently testing the performance between OS Striping and Informix Fragmentation. HPUX 10.20 Informix 7.30 HP K420 4 processors 1 GB RAM 125 GB DB It seems to me that you have two choices. First, you could stripe at the Logical Volume level, creating stripes of 2GB, which you would then allocate to the database as chunks. So the chunks would be striped. Secondly, you could have several disks, and create a dbspace on each one. You could then fragment by round robin, using the dbspaces that are each located on a separate disk. Informix distributes that data evenly across the dbspaces The advantage of using Informix fragmentation, is that you can have multiple threads working at the same time, so if you had a table fragmented across 4 dbspaces(which are on different disks), you could have 1 thread searching each dbspace simultaneously, basically doing a parallel scan. This would also be beneficial as you have 4 cpu's, so each thread would not have a dedicated CPU. This seems like it would be faster, but I haven't reached that level of testing yet. Anyone else have arguments either way? Marc Allen W. Jantzen wrote in message <3749fb05.434515@news.fl.comcastwork.com>... >(Sorry for posting this a 2nd time - I was hoping for a few opinions.) > >As part of my 7.22 -> 7.31 upgrade, I am redoing the disk layout. >A few questions for the gurus: > >Environment: >HP-UX 10.20 >HP quad processor K260 >1 gig RAM >20 gig database >3 or 4 mirrored singleton disk drives > >I will be using HP-UX LVM to create raw 2 gig logical volumes on the >drives (which are all larger than 2 gigs). I will then create my >chunks in these volumes. Most of the chunks will be 2 gigs, but if >smaller (ala detached indexes or single table dbspaces), the offsets >will work. > >Question: >Is it better to create lvm volumes striped across the disks and then >just create chunks one after another at those volumes? (The OS is >striping) > OR >Is it better to create lvm volumes on single disks (no lvm striping), >then create the informix chunks one after another across the >disks/volumes? (Informix is striping). > >Please don't tell me that striping across the disks is the answer - I >already know that. _How_ should I stripe across the disks? And why? >Should LVM handle the details, and the OS figures things out, or >should I create chunks in order across the disks/volumes myself? >LVM will have to be involved anyways so that I can break up the large >disks into manageable 2 gig logical volumes. > >Since these are raw chunks, should I involve the OS as little as >possible? > >I am leaning towards Informix mirroring rather than the HP-UX/Mirror. >I will probably utilize some expression-based fragmentation. > >Any opinions? > >Thanks >Allen Jantzen, DBA >Ned Davis Research
Marc Hopkins wrote: > > We have a very similar setup, and I am currently testing the performance > between OS Striping and Informix Fragmentation. > HPUX 10.20 > Informix 7.30 > HP K420 4 processors > 1 GB RAM > 125 GB DB > > It seems to me that you have two choices. > First, you could stripe at the Logical Volume level, creating stripes of > 2GB, which you would then allocate to the database as chunks. So the chunks > would be striped. > > Secondly, you could have several disks, and create a dbspace on each one. > You could then fragment by round robin, using the dbspaces that are each > located on a separate disk. Informix distributes that data evenly across > the dbspaces The advantage of using Informix fragmentation, is that you can > have multiple threads working at the same time, so if you had a table > fragmented across 4 dbspaces(which are on different disks), you could have 1 > thread searching each dbspace simultaneously, basically doing a parallel > scan. This would also be beneficial as you have 4 cpu's, so each thread > would not have a dedicated CPU. This seems like it would be faster, but I > haven't reached that level of testing yet. Anyone else have arguments > either way? I say do both! Stripe and mirror at the OS level (or firmware better) and then fragment the table to allow multiple threads to work and to permit fragment elimination to speed queries and not have to worry that you may be hitting one fragment harder than the rest and beating on that one drive because the striping and mirroring are spreading the work around to, in Allen's case, 8 drives. Art S. Kagel