IDS disk layout & LVM

we have and IDS 7.31.UD8 working on HP/UX. our db size is around 7gb. system has four disks. 2x36gb 15k rpm, 2x146gb 10k rpm. we use lvm and mirroring for informix chunk volumes.IDS use cooked files for chunks and all the chunk files residing on the 146gb disks. we don't use db for real time oltp processing, just for reporting during the day, and at the end of the day application loads the daily data to IDS like a batch job. we can say that it is similar to the datawarehouse and our application is working like an ETL tool. during the load checkpoint durations were very high. (around 100-150seconds) changing the ids config gave nothing. using the round robin for the biggest tables in our db helped us to lower the checkpoint durations by a percent of %10. after that i created a new volume on the 15k disks and moved the index dbspaces and the physical log dbspace to the new volume on faster disk. this helped us to reduce the checkpoint durations to ~50-60 seconds. we will attach a new disk array (msa30, 8x146gb 15k rpm disks) to the system and move informix chunks to the disk array. there are three choices in my mind. 1) create a new volume group with 8 disks.create a mirrored logical volume. put all chunks in this logical volume.(also remove the round robin fragmentation). 2) create 4 new volume groups each with 2 disks.create a mirrored logical volume in each volume group. put physical log, index dbspace, logical log and data dbspace(there will be only one data dbspace) in separate logical volumes(remove round robin fragmentation) 3) create 4 new volume groups each with 2 disks.create a mirrored logical volume in each volume group. put physical log, index dbspace, logical log in separate logical volumes. there will be 3 or 4 data dbspaces distributed to these logical volumes and we will continue to use round robin fragmentation. which one do you recommend and why? which one will be faster? or do you have other recommendations? thanks Abdullah

Abdullah AKOGLU wrote: > we have and IDS 7.31.UD8 working on HP/UX. our db size is around 7gb. > system has four disks. 2x36gb 15k rpm, 2x146gb 10k rpm. we use lvm and > mirroring for > informix chunk volumes.IDS use cooked files for chunks and all > the chunk files residing on the 146gb disks. we don't use db for real > time oltp processing, > just for reporting during the day, and at the end of the day > application loads the daily data > to IDS like a batch job. we can say that it is similar to the > datawarehouse and our application > is working like an ETL tool. > during the load checkpoint durations were very high. (around > 100-150seconds) > changing the ids config gave nothing. using the round robin for the > biggest tables in our db > helped us to lower the checkpoint durations by a percent of %10. > after that i created a new volume on the 15k disks and moved the index > dbspaces and the physical log dbspace > to the new volume on faster disk. this helped us to reduce the > checkpoint durations to ~50-60 seconds. > we will attach a new disk array (msa30, 8x146gb 15k rpm disks) to the > system and move informix chunks to > the disk array. > there are three choices in my mind. > 1) create a new volume group with 8 disks.create a mirrored logical > volume. > put all chunks in this logical volume.(also remove the round robin > fragmentation). > 2) create 4 new volume groups each with 2 disks.create a mirrored > logical volume in each volume group. > put physical log, index dbspace, logical log and data dbspace(there > will be only one data dbspace) > in separate logical volumes(remove round robin fragmentation) > 3) create 4 new volume groups each with 2 disks.create a mirrored > logical volume in each volume group. > put physical log, index dbspace, logical log in separate logical > volumes. there will be 3 or 4 data dbspaces > distributed to these logical volumes and we will continue to use > round robin fragmentation. > > which one do you recommend and why? which one will be faster? or do > you have other recommendations? > Recommendations: 1. Use RAW devices on your new array 2. Install the HPUX modules to enable Kernel Asynchronous IO (KAIO), tune the kernel KAIO settings (HP has a white paper on doing this for IDS get it and also scan the CDI history for suggestions from the HPers out there) and put 'export KAIOON=1' into the IDS startup script to enable KAIO in IDS. 3. Set up 4 volume groups as 4 mirrored pairs (ie RAID1), create a single volume group out of the 4 pairs as a 4-way stripe (ie RAID0) thereby creating a single large RAID10 array. 4. You don't do OLTP so there's no reason to isolate the logical logs and physical logs from the data by creating a separate disk volume for them. 5. Break the RAID10 array into 2GB chunks and use them to create ROOT dbspace, logical log dbspace, physical log dbspace, data dbspace, and index dbspace. 6. Should you have fragment your large tables? Depends - can your queries take advantage of fragment elimination? Will it allow the overnight loads to be broken up into more data streams to load faster? 7. Retune the instance - there are several reputable consultancies out here, including Oninit ;-), that will happily help with that. Art S. Kagel Oninit > thanks > > Abdullah > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > >