Re: Strange advises

It sounds like what your basic questions are is "Do these suggestions make sense?" and "What can I do to improve performance?" > 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 ? On some releases of HPUX, KAIO can be more expensive than on others. This really has to do with how IO completion is detected. > > > 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" The main thing that occurs when MULTIPROCESSOR is set is that we will spin when trying to lock a mutex if the mutex is currently set. We still go though the latching to protect the mutex regardless as to withither MULTIPROCESSOR is set or not. Basically what happens is that if the cpuvp can not obtain exclusive access to a mutex, then that means that some other thread is currently either queueing itself or removing itself from the mutex queue. So we spin. Every 'x' number of spins, we do a mini-sleep by making a call to a select() for a few milli-seconds. Then we start spinning again. For those places where we want to lock the memory for only a short amount of time, we will use a latch without a mutex. The basic difference is that a latch does not have a sleep queue. So it's possible that we could actually spin a bit more on those rather than on a mutex. Now for the real question. Why are you concerned about spinning? Some of it is normal. However, if you are seeing a large amount of spinning on one of the mutexes or latches, then there might be somthing of a concern. Changing the system from MULTIPROCESSOR will not make that much of an overall difference. Yes - there are a few cycles that might be saved, but that is generally offset by the OS context switch that will occur when the select() is done. What exactly are you seeing long spin waits on? It might be that the spins are indicating a more fundamental problem. > > > 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 > > Regards, > Eugene Nechayev > > Sent via Deja.com http://www.deja.com/ > Before you buy.