Fw: What is bufwaits (onstat -p)

["Vasyl Shulzhenko" <vasilis@softline.kiev.ua>]

----- Original Message -----
From: Art S. Kagel <kagel@bloomberg.net>
Newsgroups: comp.databases.informix
To: Daniel Wood <dwood@informix.com>
Sent: 30 ??? 2000 ?. 19:04
Subject: Re: What is bufwaits (onstat -p)


> 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