RE: LRU writes

> -----Original Message----- > From: Stefan Weideneder [SMTP:stefan@weideneder.de] > Sent: Monday, May 05, 2003 1:16 PM > To: informix-list@iiug.org > Subject: RE: LRU writes > > > > Assuming you really do want to cause more LRU writes because of > > excessive checkpoint duration, simply reducing the number of LRUs won't > > work. That would increase the number of buffers per LRU. It will then > > take > > longer to reach the value for LRU_MAX_DIRTY. You would get less LRU > > writes than before. > > The number of LRU-queue-pairs do not > change the amount of LRU-Writes. > LRU_MAX and MIN_DIRTY are expressed > in percent and should be interpreted > as the total amount of buffers > modified, before LRU-writes start. > "onstat -R" displays at the last > lines the total of buffers before > LRU-writes cleaning starts. > Maybe this is different in release 9.X, but in 7.31 from the Admin guide: page 11-40 By specifying when page cleaning begins, the LRU_MAX_DIRTY configuration parameter limits the number of page buffers that can be appended to an MLRU queue. The initial setting of LRU_MAX_DIRTY is 60, so page cleaning begins when 60 percent of the buffers managed by a queue are modified. page 11-47 Events That Prompt Flushing of the Regular Buffers Flushing of the regular buffers is initiated by any one of the following three conditions: n The number of buffers in an MLRU queue reaches the number specified by LRU_MAX_DIRTY. I found out that this is true recently the difficult way. I increased the number of BUFFERS on my production instance by 50% without adjusting the number of LRU queues. The result is, as expected, longer checkpoints. Regards, Bill Dare > The only trick to increase the LRU-writes > is to reduce LRU_MAX_DIRTY and maybe > LRU_MIN_DIRTY. > > Since, a lot of pages will not be flushed > during a fuzzy checkpoint, I cannot imagine > that these pages will be flushed by a LRU-write. > So it might happen that a lot of pages will only > be written during the next physical checkpoint. > Don't know if the page-cleaner-threads are > smart enough to find out, that the next > checkpoint will be a physical checkpoint. > > There is an additional problem with the > displayed information from "onstat -R". > I guess, this option displays only > "No-Sorted Writes" and "Sorted-Writes". > It's years ago when I tried to find out > what was really displayed and either the > behavior has changed in the past or my > test with a single LRU-queue pair and > a mass insert was a bad example. > > Finally I think to ensure that the next > phyiscal checkpoint will not take > too long, we should reduce LRU_MAX_DIRTY > so that (LRU_MAX_DIRTY / 100 * BUFFERS) > can be written in between an acceptable > time and if this is not good enough > because some pages are not flushed > we should call a script which invokes > "onmode -B" when the amount of dirty > pages gets higher than LRU_MAX_DIRTY. > > See also: > http://www.weideneder.de/download/admin/autoflush.scr > > ( onmode -c should be changed by onmode -b ) > > > BR > > Stefan >