Re: waiting for SEM

Looks like Waiting for SEM is misleading. I have a few servers and on some oncheck runs much much faster than the others. For eg on my single cpu server it takes 4 hours on my multiple cpu it takes 14. I ran glance on the 'faster' ones and found that they are also waiting for SEM. I gave up on that line and like Tercan and Felix poinited out changed NUMCPUVPS to 1 and SINGLE_CPU_VP to 1. Increased SHMVIRTSIZE (there were some dynamically allocated messages) and increase NUMAIOVPS. Now it takes around 4 hours. I dont know which did it but its better now. Deepa Michael Segel wrote: > 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