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... (AT) gmail (DOT) com> wrote:

Hi Peter,

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.

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)
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?!?!?!

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.

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.

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.

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