Re: Keeping clean pages in shared memory

June Tong (junet@informix.com) wrote: : 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 It would be interesting to know *WHY* you think that. I agree with Dave, write cacheing is *NOT* affected. : 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 I agree. It is more of a measure of how insert intensive your app is, and how well you have minimised block space wastage. : 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 CPU is not the issue. If you do four unnecessary writes, then you do eight unnecessary seeks, and unless you have bought more spindles than you really needed that will have a detrimental effect on disk queues and consequently on *READ* response times (although write response times are also affected, I agree that is unimportant (unless we're talking about a spindle with Logical logs on it)). : 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. A common fallacy. You *ARE* holding up *READS* to the same disk, and that *DOES* impact 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. But no *extra* checkpoint time is saved by cleaning a buffer five times, versus cleaning it once. Only the last flush saved you anything, the others were pure unnecessary overhead. : >{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... Agreed. But crashes should be a pretty rare event, whereas you're checkpointing all day, every day. : >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 ---- -- graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.