Re: waiting for SEM

Gokhan Tercan wrote: > According to Elizabeth Suto's book: > if you set the MULTIPROCESSOR to 1, this alters the OnLine system > to use spin locks for threads. Thread spin locks keep threads from being > put on a sleep or wait queue while waiting a very short time for a > resource. > > IF you set SINGLE_CPU_VP to 1,this constrains the OnLine system to use > only one CPU vp and turns off some internal locking mechanisms. This may > have positive affect on performance for 1 or 2 processor machines > > in your case you should have 1 CPU vp > and additionaly you may try to increase the semafor number Sigh. </Theoretical Mode ON> First, forget about the number of CPUs you have. You are on an SMP box. That means conceputally you have one pool of memory, and one process stack which all CPUs poll from. {Ok, so if the os has processor affinity, then you may have subordinate stacks which are tied to that processor.} So, what you are doing is limiting the engine's potential. Not all SMP boxes are created equal, not are all OS's created equal. So, the best bet would be to figure out why is the process waiting on a semaphore? Are you I/O bound? What kernel parameters are you capable of tuning? (With HPs, they limit the kernel tuning parameters because they have formulas based on other settings.) The problem with all of this *convential wisdom* is that it treats the symptoms, not the source of the problem. Suto was addressing the problems that there is additional overhead when dealing with resources under SMP. In her experiences the overhead was greater than the performance gains by having multiple VPUs. It all depends on how informix implements their SMP and how the OS works. My advice is to play with it. Or if you don't have time, fall back on the *conventional* wisdom. Now this gets back to a funny question: "When is a fork better than a thread?" [Besides during lunch] Sorry for going off on a tangent, but sometimes the simple answers may not always be the best. -Mikey