RE: is it ok to use KAIO on HP-UX

Andrew, Can You imagine, how such a fundamental bug, as that ontape was unable to restore the database from archive (with KAIO 'on'), could pass through the QA regression testing? Only because most testing (very expensive and time-consuming) was made in a different configuration. Usually, QA departments have some stable OS configuration for every part they are testing. They apply OS additional patches ONLY if it is really necessary. And, believe me, it's totally impossible to test the software like IDS with all possible patch configurations (I know pretty well the nightmare of the HP-UX patch list. Even patch bundles do not simplify that list significantly) Best regards, Alexey -----Original Message----- From: Andrew Hamm [mailto:ahamm@mail.com] Sent: Wednesday, February 11, 2004 8:34 PM To: informix-list@iiug.org Subject: Re: is it ok to use KAIO on HP-UX Alexey Sonkin wrote: > > On HP, KAIO is 'off' by default. > That means, that EVERYTHING was NOT tested properly by QA with KAIO. > That is, You need to make comprehensive testing of the > entire system, including backup, restore, replication, onpload > (whatever You use in Your system) yourself. Unlikely. Just because they supply the config like that doesn't mean it's the only testing. If the platform is dicky and needs 200 patches installed to make it work (HP has this sporadically) then I presume they test with all the appropriate patches. It might be nice to ask Informix to list all the patches, but have you SEEN the nightmare that is the HP-UX patch list? Oy Vey! sending to informix-list sending to informix-list

Alexey Sonkin wrote: > Andrew, > > Can You imagine, how such a fundamental bug, as that > ontape was unable to restore the database from archive (with KAIO 'on'), > could pass through the QA regression testing? > Only because most testing (very expensive and time-consuming) > was made in a different configuration. > > Usually, QA departments have some stable OS configuration > for every part they are testing. They apply OS additional patches ONLY > if it is really necessary. > > And, believe me, it's totally impossible to test the software like IDS with > all possible patch configurations (I know pretty well the nightmare > of the HP-UX patch list. Even patch bundles do not simplify that > list significantly) > > Best regards, > Alexey > > > -----Original Message----- > From: Andrew Hamm [mailto:ahamm@mail.com] > Sent: Wednesday, February 11, 2004 8:34 PM > To: informix-list@iiug.org > Subject: Re: is it ok to use KAIO on HP-UX > > > Alexey Sonkin wrote: > >>On HP, KAIO is 'off' by default. >>That means, that EVERYTHING was NOT tested properly by QA with KAIO. >>That is, You need to make comprehensive testing of the >>entire system, including backup, restore, replication, onpload >>(whatever You use in Your system) yourself. > > > Unlikely. Just because they supply the config like that doesn't mean it's > the only testing. If the platform is dicky and needs 200 patches installed > to make it work (HP has this sporadically) then I presume they test with all > the appropriate patches. > > It might be nice to ask Informix to list all the patches, but have you SEEN > the nightmare that is the HP-UX patch list? Oy Vey! > > > sending to informix-list > > > sending to informix-list Well, HP have recently come up with this "patch assessment" thing which will do "all the hard work for you" and you end up with a customised patch bundle just for you (how sweet) - basically a shell script to pull out your machines patch list and then it gets uploaded and assessed. It is actually pretty good, and seems to work. "run a patch assessment" from the "maintenance and support for hp products" section. Relating back to Tims original question, I think the main thing to be aware of is how many CPU VPs and physical CPUs have you got; because all the kio work will be done by the CPU VPs, so if you have only 1 CPU VP (which I am sure you don't) then you will get less throughput as compared to 200 AIO VPs ;). But probably 8 or more would be okey dokey - post an onstat -g ioa from your production, along with an onstat -g glo. I would probably only have 100 AIO VPs to try and reduce some of the filehandle maintenance across the VPs.