LRUS, CLEANERS, BUFFERS and # of disks (dbspaces) 
Author Message
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)

I doubled BUFFERS on system because I noticed that
        BTR=bufwaits*100/(pagreads+bufwrits)
is very bad. But there is no changes in BTR. I think that problem is in LRU
queues.

Is it possible to say what is the best number of LRUS and CLEANERS? Does it
depend on number of disks and/or dbspaces? Is number of BUFFERS important for
calculating # of LRUS and CLEANERS?
Is it wrong to put LRUS=8 and CLEANERS=1? If yes - what are your
recommendations?

Number of users on system 20 - 30. System is application and DB server.
OS      SCO OpenServer 5.x
HW      2 CPU Pentium, 128 M RAM, 2 disks
Informix 7.3x DS



Wed, 18 Jun 1902 08:00:00 GMT
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)

Nebojsa Sevo schrieb:

Quote:

> I doubled BUFFERS on system because I noticed that
>         BTR=bufwaits*100/(pagreads+bufwrits)
> is very bad. But there is no changes in BTR. I think that problem is in LRU
> queues.

> Is it possible to say what is the best number of LRUS and CLEANERS? Does it
> depend on number of disks and/or dbspaces? Is number of BUFFERS important for
> calculating # of LRUS and CLEANERS?
> Is it wrong to put LRUS=8 and CLEANERS=1? If yes - what are your
> recommendations?

> Number of users on system 20 - 30. System is application and DB server.
> OS      SCO OpenServer 5.x
> HW      2 CPU Pentium, 128 M RAM, 2 disks
> Informix 7.3x DS

There are some rules which should be mentioned:

Value for CLEANERS should be greater or equal to the value of LRUS !!!
I would increase LRUS = 32 and CLEANERS = 32.

Sometime ago there was a hint for a ratio of 750 BUFFERS / LRUS in this
NG.

So up to about 50 MB or 25000 BUFFERS can be configured to fullfil this
advice.

You should use all free available memory to Informix to increase
perfomrance.
But you should avoid using to much memory. This will page-out memory
pages to disk.

Regards
Frank



Wed, 18 Jun 1902 08:00:00 GMT
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)
What is BTR ?
Quote:

> I doubled BUFFERS on system because I noticed that
>         BTR=bufwaits*100/(pagreads+bufwrits)
> is very bad. But there is no changes in BTR.



Tue, 13 May 2003 14:41:39 GMT
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)

Quote:
> I doubled BUFFERS on system because I noticed that
> BTR=bufwaits*100/(pagreads+bufwrits)
> is very bad. But there is no changes in BTR. I think that problem is
in LRU
> queues.

> Is it possible to say what is the best number of LRUS and CLEANERS?
Does it
> depend on number of disks and/or dbspaces? Is number of BUFFERS
important for
> calculating # of LRUS and CLEANERS?
> Is it wrong to put LRUS=8 and CLEANERS=1? If yes - what are your
> recommendations?

I'd start with LRUS=4 (which is the minimum) and CLEANERS=6.
You did not mention your LRU_MAX/MIN_DIRTY settings, but with
a high buffer wait ratio I assume these are quite high. Reduce
them and the BTR will drop. It also helps against long checkpoints.
On the other side it affects the buffer write quality. You must find
the balance.

Quote:

> Number of users on system 20 - 30. System is application and DB
server.
> OS SCO OpenServer 5.x
> HW 2 CPU Pentium, 128 M RAM, 2 disks
> Informix 7.3x DS

HTH
Christian
--

The opinions stated above are my own
and not necessarily those of my employer.



Wed, 18 Jun 1902 08:00:00 GMT
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)
A problem with the BUFWAITS Ratio is most likely caused by contention for
the LRU queues rather than for buffers.  So, as you have discovered, adding
to BUFFERS has little effect (better to watch onstat -P output to check
if there are enough buffers).  As for how to configure, as Frank pointed out
CLEANER >= LRUS is the rule to speed checkpoint processing and inline buffer
flushing as well under load.  As for the number of LRUS you need, it is more
related to the number of users and the Buffer Turnover Rate than the number
of buffers itself.  With more users or with a higher rate of buffers being
replaced by other pages you will see increased LRU contention and so will
need more.  It is really hard to predict, however, you can always set to the
maximum (128) which will cost little in memory and improve almost any
installation.  Whatever you do avoid LRUS=64 and LRUS=96 these values (and I
also suspect LRUS=32 but have no proof) trigger a bug in the LRU rehash
algorithm, that Informix has never admitted to let alone fixed, which will
send your bufwaits through the roof.  If you still have bufwaits problems
with LRUS=128 you will have to start playing with the LRUPOLICY (an
undocumented onconfig parameter) to adjust how tasks select LRUS and when
they rehash -vs- spin-waiting.

Art S. Kagel

Quote:

> I doubled BUFFERS on system because I noticed that
>         BTR=bufwaits*100/(pagreads+bufwrits)
> is very bad. But there is no changes in BTR. I think that problem is in LRU
> queues.

> Is it possible to say what is the best number of LRUS and CLEANERS? Does it
> depend on number of disks and/or dbspaces? Is number of BUFFERS important for
> calculating # of LRUS and CLEANERS?
> Is it wrong to put LRUS=8 and CLEANERS=1? If yes - what are your
> recommendations?

> Number of users on system 20 - 30. System is application and DB server.
> OS      SCO OpenServer 5.x
> HW      2 CPU Pentium, 128 M RAM, 2 disks
> Informix 7.3x DS



Wed, 18 Jun 1902 08:00:00 GMT
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)

I was under the impression that LRU shold not be set to 128. Should be
set to 127 to the max, as theres is sort of bug.
I too have Buffere waits in my system, and I get the Buffer waits as
soon as I reinitialize my system.
I have LRUS=127 and LRU_MAX_DIRTY=2 and LRU_MIN_DIRTY=1, CLEANERS=16.
I am running INFORMIX 7.31 FC6 on DIGITAL UNIX 5.0
Any suggestions ???
Thanks,

Quote:
-----Original Message-----

Sent: Wednesday, November 29, 2000 11:19 AM

Subject: Re: LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)

A problem with the BUFWAITS Ratio is most likely caused by contention
for
the LRU queues rather than for buffers.  So, as you have discovered,
adding
to BUFFERS has little effect (better to watch onstat -P output to check
if there are enough buffers).  As for how to configure, as Frank pointed
out
CLEANER >= LRUS is the rule to speed checkpoint processing and inline
buffer
flushing as well under load.  As for the number of LRUS you need, it is
more
related to the number of users and the Buffer Turnover Rate than the
number
of buffers itself.  With more users or with a higher rate of buffers
being
replaced by other pages you will see increased LRU contention and so
will
need more.  It is really hard to predict, however, you can always set to
the
maximum (128) which will cost little in memory and improve almost any
installation.  Whatever you do avoid LRUS=64 and LRUS=96 these values
(and I
also suspect LRUS=32 but have no proof) trigger a bug in the LRU rehash
algorithm, that Informix has never admitted to let alone fixed, which
will
send your bufwaits through the roof.  If you still have bufwaits
problems
with LRUS=128 you will have to start playing with the LRUPOLICY (an
undocumented onconfig parameter) to adjust how tasks select LRUS and
when
they rehash -vs- spin-waiting.

Art S. Kagel


> I doubled BUFFERS on system because I noticed that
>         BTR=bufwaits*100/(pagreads+bufwrits)
> is very bad. But there is no changes in BTR. I think that problem is
in LRU
> queues.

> Is it possible to say what is the best number of LRUS and CLEANERS?
Does it
> depend on number of disks and/or dbspaces? Is number of BUFFERS
important for
> calculating # of LRUS and CLEANERS?
> Is it wrong to put LRUS=8 and CLEANERS=1? If yes - what are your
> recommendations?

> Number of users on system 20 - 30. System is application and DB
server.
> OS      SCO OpenServer 5.x
> HW      2 CPU Pentium, 128 M RAM, 2 disks
> Informix 7.3x DS



Wed, 18 Jun 1902 08:00:00 GMT
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)


Quote:

>I was under the impression that LRU shold not be set to 128. Should be
>set to 127 to the max, as theres is sort of bug.

It's just a spurious warning message you can ignore. But why not see if your
port doesn't support more LRUs, like say 512?

Quote:
>I too have Buffere waits in my system, and I get the Buffer waits as
>soon as I reinitialize my system.
>I have LRUS=127 and LRU_MAX_DIRTY=2 and LRU_MIN_DIRTY=1, CLEANERS=16.
>I am running INFORMIX 7.31 FC6 on DIGITAL UNIX 5.0

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


Wed, 18 Jun 1902 08:00:00 GMT
 LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)


Quote:

> I was under the impression that LRU shold not be set to 128. Should be
> set to 127 to the max, as theres is sort of bug.
> I too have Buffere waits in my system, and I get the Buffer waits as
> soon as I reinitialize my system.
> I have LRUS=127 and LRU_MAX_DIRTY=2 and LRU_MIN_DIRTY=1, CLEANERS=16.
> I am running INFORMIX 7.31 FC6 on DIGITAL UNIX 5.0
> Any suggestions ???
> Thanks,

I have never seen a system without bufwaits.  The question
is, in comparison to how often you are exclusively locking a buffer,
how often are you having to wait in comparison to how often you are
changing the buffers?

bufwaits*100/(pagreads+bufwrits)

giving us the output from the following would be a start.
onstat -p
onstat -c
onstat -D
onstat -d
onstat -g iov
onstat -g glo

Hope to help,
Will

supplying this information will at least

Quote:
> -----Original Message-----

> Sent: Wednesday, November 29, 2000 11:19 AM

> Subject: Re: LRUS, CLEANERS, BUFFERS and # of disks (dbspaces)

> A problem with the BUFWAITS Ratio is most likely caused by contention
> for
> the LRU queues rather than for buffers.  So, as you have discovered,
> adding
> to BUFFERS has little effect (better to watch onstat -P output to
check
> if there are enough buffers).  As for how to configure, as Frank
pointed
> out
> CLEANER >= LRUS is the rule to speed checkpoint processing and inline
> buffer
> flushing as well under load.  As for the number of LRUS you need, it
is
> more
> related to the number of users and the Buffer Turnover Rate than the
> number
> of buffers itself.  With more users or with a higher rate of buffers
> being
> replaced by other pages you will see increased LRU contention and so
> will
> need more.  It is really hard to predict, however, you can always set
to
> the
> maximum (128) which will cost little in memory and improve almost any
> installation.  Whatever you do avoid LRUS=64 and LRUS=96 these values
> (and I
> also suspect LRUS=32 but have no proof) trigger a bug in the LRU
rehash
> algorithm, that Informix has never admitted to let alone fixed, which
> will
> send your bufwaits through the roof.  If you still have bufwaits
> problems
> with LRUS=128 you will have to start playing with the LRUPOLICY (an
> undocumented onconfig parameter) to adjust how tasks select LRUS and
> when
> they rehash -vs- spin-waiting.

> Art S. Kagel


> > I doubled BUFFERS on system because I noticed that
> >         BTR=bufwaits*100/(pagreads+bufwrits)
> > is7 very bad. But there is no changes in BTR. I think that problem
is
> in LRU
> > queues.

> > Is it possible to say what is the best number of LRUS and CLEANERS?
> Does it
> > depend on number of disks and/or dbspaces? Is number of BUFFERS
> important for
> > calculating # of LRUS and CLEANERS?
> > Is it wrong to put LRUS=8 and CLEANERS=1? If yes - what are your
> > recommendations?

> > Number of users on system 20 - 30. System is application and DB
> server.
> > OS      SCO OpenServer 5.x
> > HW      2 CPU Pentium, 128 M RAM, 2 disks
> > Informix 7.3x DS

Sent via Deja.com http://www.deja.com/
Before you buy.


Wed, 18 Jun 1902 08:00:00 GMT
 
 [ 8 post ] 

 Relevant Pages 

1. Number of LRUs, Cleaners & Buffers

2. Page cleaners / LRUS with single disk

3. LRUs and Cleaners

4. BUFFERS and LRUS settings

5. LRU,cleaner and buffer

6. Cleaners & Striped disks

7. LRU, Cleaners and num disks

8. dbspaces on same disk and io threads

9. Informix dbspace mirroring VS. Operating System disk mirroring

10. Measuring Informix Disk Usage, extents and dbspaces

11. Dbspaces spanning multiple disks.

12. One dbspace on 2 disk


 
Powered by phpBB® Forum Software