Slow Raid 5 Disk maybe, where to start?

We are setting up a new soalris 10 container system... priority ageing a worry but I presume ok on my version? 9.40.UC8, Solaris 10 containers, raid 5 very striped Sun sata array 16GB cache (which never gets used I'm told), 6CPU IV+ V490, 40 dbspaces - one mountpoint cooked linked chunks. Mostly Read only DW type spatial app. Can't quite get pfread.sh working, or for that matter myschema no matter what I do. I used the c program in the checkpoint post and it took at worst 3 minutes 50 seconds to write 20mb in 2k block sizes. I get long checkpoints, best is about 14 seconds. Without tuning it was 15-20 sec I think, writing out 25-30mb of buffers. Reading 20mb using dd gives me a time of 0.0 seconds ! Reading data seems fine. I guess my question is, when Informix writes to disk (at checkpoint or in normal operation) what is the block size it uses as this is configurable somehow in the O.S. Is there a difference in the way the engine managed IO at checkpoint and other times? Strangely selecting into raw tables or temp space is not too bad. FYI, it is late in what is a very busy day, so sorry for anything obvious missed in this post. Paul - good one securing Art ! And BTW IDS 11 on Win Ultimate :(

On Nov 26, 2:15 am, PeterP <peterp...@gmail.com> wrote: Hi Peter, > We are setting up a new soalris 10 container system... priority ageing > a worry but I presume ok on my version? Priority aging is a concern on Solaris, although it's not quite as aggressive as HPUX. Just set 'NOAGE 1' in your ONCONFIG file and IDS will ask Solaris to not age oninit processes. > > 9.40.UC8, Solaris 10 containers, raid 5 very striped Sun sata array AAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! PLEASE read my paper on the subject (Why should I not use RAID 5?), along with several others from database and storage experts from Oracle and elsewhere, on the BAARF web site (www.baarf.com) > 16GB cache (which never gets used I'm told), 6CPU IV+ V490, 40 > dbspaces - one mountpoint cooked linked chunks. Mostly Read only DW > type spatial app. Cooked chunks with IDS 9.40 which does not support DIRECT_IO is costing you from 10-25% of your available IO performance over and above the performance and safety costs of using RAID5! Do you routinely disable one or two cylinders of your car's engine? Why not use RAW devices for chunks and use all 8 cylinders?!?!?! > > Can't quite get pfread.sh working, or for that matter myschema no > matter what I do. > I used the c program in the checkpoint post and it took at worst 3 > minutes 50 seconds to write 20mb in 2k block sizes. > > I get long checkpoints, best is about 14 seconds. Without tuning it > was 15-20 sec I think, writing out 25-30mb of buffers. Does the test app open the files in O_SYNC mode? If not you are only testing you system cache speed which is not the speed at which IDS writes to disk as IDS ALWAYS opens COOKED chunks in O_SYNC mode (except in the latest 10.00 and 11.10 releases that can use O_DIRECT mode). If it did not your data would not be safe after a checkpoint. > Reading 20mb using dd gives me a time of 0.0 seconds ! Reading data > seems fine. That's reading data that's already in cache! IDS reads from 'disk' tend to NOT be in the system cache when COOKED chunks are used because of it's own buffer cache. Any data that's recent enough to be in the system cache will likely still be in the IDS buffer cache so IDS won't even issue an IO request for it. > I guess my question is, when Informix writes to disk (at checkpoint or > in normal operation) what is the block size it uses as this is > configurable somehow in the O.S. Is there a difference in the way the > engine managed IO at checkpoint and other times? Strangely selecting > into raw tables or temp space is not too bad. IDS writes either 1 page or 8 page IOs (2K or 16K on Solaris). At checkpoint time it does perform larger single and multiple contiguous IOs to enable OS and drive level elevator sorting of writes so that physical writes can be optimized at the hardware level. IDS performs best on arrays configured with a block size UNDER 64K. Sizing your array at 16K or 32K blocks will likely perform best. Array MFGs typically default the blocksize to 128K and recommend blocking as large as 256K or 512K for filesystems and for those applications that does seem to work out well. However, for database applications smaller block sizing is better. > FYI, it is late in what is a very busy day, so sorry for anything > obvious missed in this post. Paul - good one securing Art ! And BTW > IDS 11 on Win Ultimate :( Thanks for the vote of confidence. You said 9.40UC8 on Solaris above, so I'll assume this is some asside to Paul. ;-) Art S. Kagel