Re: KAIO and Informix and HP-UX 11.0

> I suppose that a message should appear in MSGPATH (i.e., online.log) when > Informix starts which indicate that kaio is enabled also onstat -g ioq, > iov or ath doesn't show anything about kaio or kio Yes, you should see a message in the IDS log when the engine is brought up. > Asyncdisk is compiled in kernel, all dbspaces are on raw partitions > (including rootdbs) KAIION is set to 1 , informix user runs ksh, > /dev/async has been made according to release notes. What else do I have > to check? Make sure you export KAIOON=1...I'm not sure if the spelling you used above is also what you used on the system. > 2) after we switched to raw partitions, checkpoint times jumped by an > order of magnitude (now sometimes 50-120 seconds) > > Is it normal? No, but KAIO is goofy that way. For some people it works flawlessly (I've only seen performance gains with it), for others it causes headaches and performance drops. You definitely should not be getting that kind of performance on raw partitions when KAIO is NOT enabled, unless you're processing boatloads of data nonstop. I'd double-check your disk configurations and layouts. What were you using before--cooked files? > I tried to suppress this by setting > > LRU_MAX_DIRTY 5 > LRU_MIN_DIRTY 2 > CKPTINTVL 60 Your checkpoint interval looks too low. Set LRU_MAX_DIRTY to 2 and LRU_MIN_DIRTY to 1...how many page cleaners do you have set up? > 3) is the following statement true? > Tune Tips for HP KAIO > RESIDENCY > In version 7.30 for best KAIO performance set RESIDENT flag > in the onconfig to -1. In versions prior to version 7.30 set the > resident flag to 1. This will reduce a significant amount of > kernel locking that must be done on non-resident segments. Yes, it's true. When KAIO is enabled, there's something about HP- UX that causes shared memory segments to be locked in place (i.e. no "non-resident" segments). Setting RESIDENT to -1 is a good idea on HP-UX with KAIO on. > Informix support is at little help, because they are so _slow_ and > basically do something just in cases when something doesn't work at all. You can escalate the priority of cases if it's affecting a production system or has a significant business impact. If you have a good account rep/salesperson, they can apply pressure to tech support as well. --Chuck