Re: What is bufwaits (onstat -p)

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

Daniel Wood wrote: > > 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. I have to differ Daniel. There ARE situations, all too common in a busy OLTP system, where LRU contention will cause bufwaits. According to the Administrator's Guide, Chapter 11 or 12 depending on version, when a thread needs to read a page from disk into a buffer it selects an LRU, if the buffer at the end of the queue of that LRU is latched it will bufwait and try again. On a busy OLTP system (and even many DSS systems) there will be many pages accessed that are not yet in the buffer cache and so will have to acquire a buffer from the LRU end of the queue to read a page into. If there are many users and too few LRU queues this will cause contention for the last buffer in some of the LRU queues resulting in extensive bufwaits. Note that the onstat -p values that I recommend using to calculate the Bufwaits Ratio (BR) which may be aided by increasing LRUS includes pagreads and bufwrits. The former indicated the number of times an LRU tail page was latched to read a page from disk, which also latches the LRU itself I believe, and the latter indicates the number of times a buffer was modified which requires a latch on the LRU in order to move the buffer to the MLRU sub-queue if it is not already there. In addition, your description does not explain why when this BR exceeds 7% the system starts to seem slow to updaters and if it exceeds 10% many OLTP users will complain of poor performance. Nor does it explain why subsequently increasing LRUS significantly both reduces the BR to under 7% (often as low as 2%) eliminates the perceived performance problems. I have been using this rule of thumb on my own systems for over 4 years and I have been recommending it here for about three years and the results are completely consistent and satisfying. I believe you are correct in your description of the mechanics governing incrementing the reported bufwaits value, I just think you have missed the effects of the conditions that cause it to increment. Art S. Kagel > 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