RE: 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, -----Original Message----- From: Art S. Kagel [mailto:kagel@bloomberg.net] Sent: Wednesday, November 29, 2000 11:19 AM To: informix-list@iiug.org 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 Nebojsa Sevo wrote: > > 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

In article <905spf$ia$1@news.xmission.com>, "Sinha, Niraj" <niraj.sinha@BondBook.com> wrote: > > 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 > -----Original Message----- > From: Art S. Kagel [mailto:kagel@bloomberg.net] > Sent: Wednesday, November 29, 2000 11:19 AM > To: informix-list@iiug.org > 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 > > Nebojsa Sevo wrote: > > > > 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.