Re: Informix and NOAGE

In article <33CC2D68.307@bellsouth.net>, MIS Dept <whsmis1@bellsouth.net> wrote: >Saeed Talebbeik wrote: >> Both NOAGE and processor affinity can boost the performance. >> However look into the machine notes of your platform to see if these two >> features are really supported. Apparently on HPUX NOAGE is supported. >> I suggest to experiment with NOAGE and see what happens. I have heard of >> lockup problems such as this but I have not seen it myself. >>NOAGE is officially supported, but we've been bitten by that nasty bug. >Informix literally took over the system; the oninit processes were >running with a priority of -16. That's because in 7.1x on HP-UX NOAGE is implemented using the POSIX scheduler class (man rtsched for details; POSIX is the only way to get negative priorities). Anything ready to run in this class gets priority over everything else. Informix, being a good database server trying to minimise context switching, tries to do as much as it can when it gets the CPU, preferring to busy-wait for a while rather than relinquish the processor. 7.22 uses HP's real-time-priority class (prios between 1 and 127; the smaller the number, the higher the priority) for NOAGE, though I don't know what priorities it assigns to the various classes of VPs. This is much more sensible. We've written a startup script for 7.14 that does much the same as what we've been told 7.22 does with NOAGE set. This script starts the server, waits for recovery to complete, sees if additional lio and pio VPs are needed to handle mirroring and kicks those off before the real-time server process does, does onstat -g glo, figures out what pid corresponds to what VP (awk is wonderful), moves some up into real-time priority, and bounces others back into time-share class. It's easy once you understand what you have to do. Be aware that any additional VPs that Informix creates on its own will inherit the priority of the parent VP--a CPU vp. It's better to create all the VPs you need when you start the server, then move them around to where you want them to be (do you really need a high-priority lio VP?). However, this brings its own set of gotchas, particularly when running on a uniprocessor box. Whenever a high-priority VP is waiting for a lower-priority VP to clean something up, it will run away in a busy-wait loop. If you run Informix at higher-than-normal priorities, keep a still-higher-priority terminal window handy, and unset autologout so it doesn't disappear of its own accord. Setting your own real-time priorities is not exactly unsupported; Informix would prefer that you use NOAGE, but they understand that it's badly broken in 7.1x and deemed to be fixed in 7.22. Informix tech support apparently considers priority tuning apart from NOAGE to be similar to kernel tuning. If it works, life is good. If it doesn't, you have more work to do. But if it turns up a real bug, they'll take the report. Useful tools for diagnosis: one or two high-priority windows, onstat -g ath, onstat -g tpf <thread_id>, onstat -g wai, access to either the console or power switch for stuff that locks out the high-priority windows. If Informix runs away, write a script to bring it back to its senses, (i.e., time-share priority), then restore the real-time stuff. Of course, any manipulation of process priority requires you to be root, and all caveats such as YMMV apply. Have fun. Jim -- W. Jim Jordan, Nortel, Stop 314 Qualicum, PO Box 3511 Stn C, Ottawa, ON K1Y 4H7 Canada I do not speak for Nortel. Unsolicited commercial or bulk e-mail may attract an invoice.