very high "mt yield 0" on IDS 9.40

looking at the wait statistics of my IDS 9.40 I find an ever increasing value for the "MT yield 0" condition. Up to my knowledge this means that threads are doing busy waits for other event's 8365.1739360000 mt yield 0 7838.532454000 running 3117.827147000 mt ready 565.9444200000 aio 336.1063910000 buffer 62.40807100000 mutex 17.26987300000 checkpoint 13.41330400000 lock 0.113705 mt yield How can I try to track down the reason for this behaviour ?

rvb wrote: > looking at the wait statistics of my IDS 9.40 I find an ever > increasing value for the "MT yield 0" condition. > > Up to my knowledge this means that threads are doing busy waits for > other event's Looks like it. (snip) > How can I try to track down the reason for this behaviour ? That's difficult. Can you give us some more information? - scheduler statistics, number of vps from onstat -g glo - Do the threads hit use shm connections (notorious for yield 0)? - Any clues about what these threads are doing special? - What OS and what exact online version? Would it be possible to attach a debugger to oninit (which is a risk in a productive environment)? Michael

After thinking about this a little longer I changed my mind. Your thread spends a lot of time in the yield 0 state. This can be caused by the following: A thread running a query entirely on the buffer pool (or something similar) has to yield(0) occasionally to give other threads a chance to run. The high time spent in yield 0 state means that there are other competing threads which run after the yield(0). I assume your data is from a busy system? Only if the number of yield 0 events becomes excessively high, you have to worry about busy waits. But your data does not show this number. Michael Michael Mueller wrote: > rvb wrote: > >> looking at the wait statistics of my IDS 9.40 I find an ever >> increasing value for the "MT yield 0" condition. >> >> Up to my knowledge this means that threads are doing busy waits for >> other event's > > > Looks like it. > > (snip) > >> How can I try to track down the reason for this behaviour ? > > > That's difficult. Can you give us some more information? > > - scheduler statistics, number of vps from onstat -g glo > > - Do the threads hit use shm connections (notorious for yield 0)? > > - Any clues about what these threads are doing special? > > - What OS and what exact online version? Would it be possible to attach > a debugger to oninit (which is a risk in a productive environment)? > > Michael

"rvb" <rvbon@gmx.de> wrote in message news:6e9a0040.0503030106.178fac00@posting.google.com... > looking at the wait statistics of my IDS 9.40 I find an ever > increasing value for the "MT yield 0" condition. > > Up to my knowledge this means that threads are doing busy waits for > other event's > not quite. mt yield 0 is what is called a 'nice yield'. That means that the thread might be on a rather long code path and we want it it simply be nice offer the CPU to someone else. What could cause this... Well suppose that you have a filter on a 1,000,000 row table which will be skipping the vast majority of the rows. Suppose that we're going to have to do a sequential scan of the table -- maybe because there is no index on the table. Let's also suppose that you've got readahead turned on. Well - it would be possible that if the thread didn't occasionally yield 0 that it would become a hog, expecially if read-ahead happend to be able to get the next block of pages loaded before the prior block was scanned. There wouldn't be anything to cause the thread to give up the processor. So no one can get to the CPU until the thread is finished. Bad 'ole piggy.... So we occasionally will put in mt yield 0 simply to allow a thread switch to occur, and more equally balance the processor usage. If there are no threads in the ready queue waiting to run, then the thread which called the mt yield 0 gets control of the processor again. M.P. > 8365.1739360000 mt yield 0 > 7838.532454000 running > 3117.827147000 mt ready > 565.9444200000 aio > 336.1063910000 buffer > 62.40807100000 mutex > 17.26987300000 checkpoint > 13.41330400000 lock > 0.113705 mt yield > > How can I try to track down the reason for this behaviour ?