Re: Keeping clean pages in shared memory

In article <3j5crk$566@infmx.informix.com> davek@informix.com (David Kosenko) writes: >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. > >This rides on the FALSE assumption that "flushing" a page removes it from >the buffer cache. In fact, it simply updates the page on disk to reflect >the state of the page in memory. LRU cleaning has no discernable effect >on cacheing. Well, I think it DOES reduce your write cache percentage, but then, I've always thought that write cache percentage was overrated as a way of measuring your performance. As someone else has already pointed out, if your LRU_MIN_DIRTY is set very low, and you update the same page multiple times, you could end up writing a page to disk several times instead of once. But so what? If you didn't end up taking any resource away from something else in order to do it (OK, maybe your page cleaner took a REALLY MINISCULE amount of cpu time in the process), what difference does it make? Unlike checkpoints, LRU writes are NOT holding up other activity (except other writes to the same disk), so as long as your logs aren't on this disk, you aren't really impacting your performance. (I think that answers somebody's question.) But when it's time to checkpoint, the LRU write you did WILL save you some time in checkpointing, and since checkpoints DO stop other activity, this is generally a good thing. >{A lot of davek's stuff which I have just reiterated deleted} >For max performance relative to this, set LRU_MAX_DIRTY low (no higher than >10%), make your physical log as large as you can, and set your checkpoint >interval to be huge. Let filling up the physlog drive the checkpoints. The >major downsides to this are: 1) the length of time it will take to perform >fast recivery in the case of a crash; Well, this is a pretty major downside... >and 2) how long it will take for >logical logs to be freed (assuming you are doing logging). I don't really see where this is an issue. If you have continuous log backup on, they will be backed up when filled just as usual (and if you don't, they won't, just as usual). They just won't be freed. But when you reach the last free log, it will force a checkpoint anyway, and free any logs that don't have open transactions, so what difference did it make that the logs weren't freed earlier? June ---- June Tong Informix Software ---- ---- junet@informix.com (415)926-6140 ----