Re: Keeping clean pages in shared memory

In article <3j51am$shs@infmx.informix.com> raj@informix.com (Raj Gopalakrishna) writes: > > Page Cleaners and Checkpoints definitely influence cache flushing. >By setting a low value for LRU_MIN_DIRTY, you cause excessive page >cleaning activity. This may not be a good idea as it effectively reduces >the effectiveness and size of the cache. I mention size of the cache >because everytime the MIN_DIRTY threshold is reached some page cleaners >are kicked in to start flushing pages and this artificially reduces the >size of the cache. > > Secondly, page cleaner flushes are not sorted but asynch. writes. > > On the other hand, checkpoints are sorted, synchronous writes. > > Choosing the checkpoints interval and optimal values for MIN and MAX >DIRTY can be tricky. A number of Informix manuals explain these >parameters in greater detail. Refer to them. >-raj > Well I see you're from Informix so you should be able to find out, but I had stayed away from this for years thinking exactly what you state, and after years of being told 'lower LRU_MIN_DIRTY and LRU_MAX_DIRTY' I finally stopped and talked it over with someone from Informix who stated that the effect is not to reduce the size of the cache, or render it wasted memory, but merely to ensure that more of it is clean at any given time. The buffers and data remain, the hits will be hits, but the writes wont pile up too much. I found (at releases lower than 6.0) that doing a tbstat - -r 1 and monitoring the number of seconds a checkpoint took was the needed tool to tune this. Checkpoints taking longer than 2-3 seconds are seen as intolerable by my customer base (~100 sites, between 20 and 600 users, doing OLTP), and the constant background work is needed to keep the foreground work from being a perceptible time delay.