Re: Strange advises

Eugene Nechayev wrote: > > CROSSPOSTED: ukr.comp.dbms.informix > > Hi Informixers, > > I have two very strange recommendations that isn't true from my point of > view > from one my consultant. I hope Informix community is able to make the > advises > more clear for me. > > HPUX 10.20 > IDS 7.30UC8 > > The first is "You have KAIO running. We are aware that this feature is > causing > performance problem with Informix implementation. Recommend to not > enable it" > I haven't ever crossed with any problems that is related with > performance under > HPUX. Maybe somebody has different experience ? There were some specific reports of problems with KAIO on HPUX which were version and patch dependent. But IB that if everything is set up correctly there is not problem. Others who use HP will surely comment further. > The second advice is very interesting for me. > "Even though your host is multi-processor, it is better to configure > as NON-MULTIPROCESSOR. If not too many mutex, which is currently being > experienced. MULTIPROCESSOR 0" If you actually do have multiple CPUs then you MUST set MULTIPROCESSOR to 1 as it enables code to prevent deadlocks and memory concurrency problems that is slightly slower than otherwise but absolutely neccessary to the proper functioning of the engine. And these are the kind of problems that will not show up for weeks and then one day your server crashes or a query hangs forever because some memory location changed values when MULTIPROCESSOR == 0 says that such was impossible. Yes, this will indeed use more multex locks which are the cheapest latching method to prevent concurrent access by processes and threads running on multiple CPUS. This cannot be helped. Your consultant's advice is like someone saying to you: "If you disconnect half of the spark plugs in your car's engine there will be more electrical power to spare from the alternator to power the lights and keep the battery charged". This is true but completely ignores the fact that the engine runs better and does its job more efficiently if the plugs remain connected and that the lights DO work and the battery DOES maintain a charge anyway! > Other multi-CPU parameters hasn't been changed. > NUMCPUVPS 2 > SINGLE_CPU_VP 0 > AFF_SPROC 0 > AFF_NPROCS 2> > After changing the parameter I haven't seen any big difference in > "onstat -g spi". > Does the advice have any effect in my system ? If it's true how can I > recognize the effect from statistics ? > > Any input will be very appreciated Art S. Kagel

In article <3870CEC3.12D0BFC6@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes > >There were some specific reports of problems with KAIO on HPUX which were >version and patch dependent. But IB that if everything is set up correctly >there is not problem. Others who use HP will surely comment further. > Check the FAQ at www.smooth1.demon.co.uk Section 6.7.3 What OS bugs may affect Online? There were several implementations of KAIO on HP-UX. Check the online.log for Version 1 "HPUX Version XXX -> Using select based KAIO" Version 2 "HPUX Version XXX -> Using flag style KAIO" Version 3 "HPUX Version XXX ->Using flag/select style KAIO" Version is the best and has no known problems. Requires "Online Versions 7.30.UC3 and above and 9.14.UC1 and above" Credit to 1998 jmiller@informix.com (John F. Miller III) > >> The second advice is very interesting for me. >> "Even though your host is multi-processor, it is better to configure >> as NON-MULTIPROCESSOR. If not too many mutex, which is currently being >> experienced. MULTIPROCESSOR 0" > >If you actually do have multiple CPUs then you MUST set MULTIPROCESSOR to 1 >as it enables code to prevent deadlocks and memory concurrency problems that >is slightly slower than otherwise but absolutely neccessary to the proper >functioning of the engine. And these are the kind of problems that will not >show up for weeks and then one day your server crashes or a query hangs >forever because some memory location changed values when MULTIPROCESSOR == 0 >says that such was impossible. Yes, this will indeed use more multex locks >which are the cheapest latching method to prevent concurrent access by >processes and threads running on multiple CPUS. This cannot be helped. > >Your consultant's advice is like someone saying to you: "If you disconnect >half of the spark plugs in your car's engine there will be more electrical >power to spare from the alternator to power the lights and keep the battery >charged". This is true but completely ignores the fact that the engine runs >better and does its job more efficiently if the plugs remain connected and >that the lights DO work and the battery DOES maintain a charge anyway! > >> Other multi-CPU parameters hasn't been changed. >> NUMCPUVPS 2 >> SINGLE_CPU_VP 0 >> AFF_SPROC 0 >> AFF_NPROCS 2>> >> After changing the parameter I haven't seen any big difference in >> "onstat -g spi". >> Does the advice have any effect in my system ? If it's true how can I >> recognize the effect from statistics ? >> >> Any input will be very appreciated > >Art S. Kagel -- David Williams