RE: What is bufwaits (onstat -p)

I have one question. From your message: -- Pages that get both update and read activity or pages that get updated by multiple users are the source of bufwaits. The odds of two users with incompatible access modes hitting the same page at the same time is little affected by the number of LRU's. -- I have a box all to myself. I did a select statement. Nothing else is running against the databse. bufwaits went up. Please explain how this can occur if the only source of incrementing bufwaits is pages which get both update and read activity. Thanks, Will >===== Original Message From Daniel Wood <dwood@informix.com> ===== >Bufwaits have little or nothing to do with LRU contention nor with >reading in a page from disk. As Vinod said it does occur when one >has to wait on a buffer because another is accessing it. > >The counter is not incremented because one waits to get access to >an LRU. It is incremented when a buffer is in use by another user. >However, two users can obtain shared access to a buffer if they >are just going to read it. > >A user going to modify a page must obtain an exclusive lock(XLOCK) >on the buffer while readers just need to obtain a shared lock(SLOCK). >A user attempting a XLOCK on a page must wait for all users with >X/S LOCK's to release the buffer. Likewise a user wanting to put >an SLOCK on a buffer must wait if either the page is XLOCK or there >are waiters on the page(Presumably waiting to put an XLOCK). > >Pages that get both update and read activity or pages that get >updated by multiple users are the source of bufwaits. The odds >of two users with incompatible access modes hitting the same page >at the same time is little affected by the number of LRU's. > >Of course, if the time one held onto a buffer was excessively prolonged by waiting >on the LRU's, thus delaying the release of >the buffer, then there could be a little impact on bfwaits. >However, the time one is actually doing something with a buffer >should far outweigh the time to release it. > >You should do: > > onstat -g spi | sort -n +1.> >The tail end of this output will show what spin locks(lrus, buf's, >etc.) are getting the most contention. If the lrus do appear >high in the list then increasing the LRU may help. > >- dwood > >"Art S. Kagel" wrote: > >> The bufwaits indicates when a thread has to wait to read a page into a >> buffer from disk usually this is caused by the LRU Queue to which the thread >> has hashed to acquire a buffer being locked by another thread trying to do >> the same thing or needing to move a buffer from the 'clean' part of the >> queue to the 'dirty' part so it can modify the page it contains. Sometimes >> the condition is caused by buffer flushing activities for the same reason. >> Another cause is the need to latch a buffer that already contains data to >> move it to the MRU end of the queue. >> >> Increasing BUFFERS CAN help somewhat but the most effect is obtained by >> increasing LRUS which reduces the probability that there will be contention >> for the LRU that the thread hashes to (or the ones that it rehashes to >> after spinning for too long). If there is still LRU contention even after >> maxing LRUS out (128 in 7.[123]x) there are some undocumented ONCONFIG >> parameters that control how a thread selects an LRU queue which can reduce >> contention when there are a large number of threads. But since they are >> undocumented save these as a last resort. >> >> If bufwaits exceeds 7% of (pagreads + bufwrits) you are probably suffering >> from LRU contention, if >10% you are in LRU contention HELL! >> >> Art S. Kagel >> >> Vinod Bhansali wrote: >> > >> > Hello friends, >> > >> > What is bufwaits? >> > Is it incremented when somebody has to access a buffer but has to wait as >> > somebody else is accessing the buffer? >> > >> > I have read somewhere that bufwaits can be reduced by increasing the BUFFERS>> > parameter in onconfig. I agree increasing BUFFERS parameter will >> > reduce/avoid ov_buffer but I don't understand how BUFFERS parameter affects >> > bufwaits. >> > >> > I think bufwaits will be affected by number of >> > concurrent threads or cleaners or CPU VPs >> > >> > What do you say? >> > >> > Thanks in advance >> > Vinod Bhansali >> > ________________________________________________________________________ >> > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com ------------------------------------------------------------ This e-mail has been sent to you courtesy of OperaMail, as a free service from Opera Software, makers of the award-winning Web Browser, Opera. Visit us at http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail account is waiting at: http://www.operamail.com/ ------------------------------------------------------------