RE: LRU writes

> -----Original Message----- > From: Franklin Tang [SMTP:franklin@macauslot.com] > Sent: Monday, May 05, 2003 8:13 AM > To: informix-list@iiug.org > Subject: LRU writes > > Dear, > I have a problem on the LRU writes , the figure for LRU compares to > Chunk writes has a huge difference. E.g. > > Fg Writes LRU Writes Chunk Writes > 0 4600 1094394 > > > I want to increase the LRU writes to reduce the chunch wirtes. Should I > reduce the number of LRU??? > Why? Are your checkpoints taking too long? OLTP of Data Warehouse? 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 parameters LRU, LRU_MAX_DIRTY, LRU_MIN_DIRTY, CLEANERS, CKPTINTVL and BUFFERS should all be tuned together to reduce checkpoints. Tune BUFFERS to get the required read/write cache percentage and then tune the others for optimal checkpoint duration for that number of buffers. Post your onconfig file for recommendations. Regards, Bill Dare > Thx > Franklin >

> 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. 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