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 >

Here is the onconfigure LOCKS 200000 # Maximum number of locks BUFFERS 1126400 # Maximum number of shared buffers NUMAIOVPS 2 # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 500 # Maximum number of logical log files CLEANERS 384 # Number of buffer cleaner processes SHMBASE 0xa000000 # Shared memory base address SHMVIRTSIZE 1048576 # initial virtual shared memory segment size SHMADD 524288 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 CKPTINTVL 180 # Check point interval (in sec) LRUS 384 # Number of LRU queues LRU_MAX_DIRTY 2 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit LTXHWM 50 # Long transaction high water markpercentage LTXEHWM 60 # Long transaction high water mark (exclusive) TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 32 # Stack size (Kbytes) "Bill Dare" <dareb@jevic.com> '''g''l''s'D :b96d32$83q$1@terabinaries.xmission.com... > > > > > -----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 > >