Re: LRUs and Cleaners

Doug Agnew wrote: > > One of the comments made during the performance tuning presentation at SP99 > has left me with a small question. The comment was to the effect that a > good target value for LRUs was 1 LRU for every 750 buffers. That I > understand, and it seems the intention is to reduce the time required to > process each queue, which makes sense. > > Now, my dilemma.... > > We currently have 500,000 buffers, which would lead me to assign about 670 > LRUs (ok, 666 2/3, if you want to be picky about it). Currently LRUs are > at 80 and bufwaits/(pagreads+pagwrites), hereafter referred to as the "Kagel > bufwait percentage" (or KBP), is between 7 and 10% That "KBP" ratio is properly: bufwaits / (pagreads + bufwrits) Pagwrits tracks pages written from cache to disk but it is the filling of and updates to cache pages (pagreads and bufwrits respectively) that causes LRU contention. Recalculate. BTW, I like 5% or less better and use 7% as my own alarm value and 10% as my panic value. > BUT, I've also heard that Cleaners should be >= LRUs and Cleaners cannot > exceed 128. Neither can LRUs Doug! The max LRUs value for 7.xx is 128 (for 5.xx it was 32) and that triggers an annoying but harmless message at startup in some versions telling you that your physical log and logical log sizes are zero so I use 127 myself! Not to worry, Doug, targets are just that - targets to be sought not necessarily hit. You can get the same effect, of reducing flush times, by decreasing the LRU_MAX/MIN_DIRTY parameters a bit. > So, if I set LRUs where I want them and max Cleaners, will the cleaners to > LRU mismatch trash any gain I get from the increase in LRUs?? And what > metrics (in addition to the KBP) would be best for monitoring?? The best metric is the checkpoint duration. If it becomes unacceptably long you need to reduce the LRU_MAX/MIN_DIRTY or increase the number of LRUS and CLEANERS if possible. Art S. Kagel

On Thu, 05 Aug 1999 11:29:42 -0400, "Art S. Kagel" <kagel@bloomberg.net> wrote: >Doug Agnew wrote: >> >> One of the comments made during the performance tuning presentation at SP99 >> has left me with a small question. The comment was to the effect that a >> good target value for LRUs was 1 LRU for every 750 buffers. That I >> understand, and it seems the intention is to reduce the time required to >> process each queue, which makes sense. >> >> Now, my dilemma.... >> >> We currently have 500,000 buffers, which would lead me to assign about 670 >> LRUs (ok, 666 2/3, if you want to be picky about it). Currently LRUs are >> at 80 and bufwaits/(pagreads+pagwrites), hereafter referred to as the "Kagel >> bufwait percentage" (or KBP), is between 7 and 10% > >That "KBP" ratio is properly: > I personally like that fact that someone has finally named the new ratio, and I intend on enforcing the use of the acronym as often as possible. Maybe SP00 will have a new session - How's your 'KBP'? <;-) > >Pagwrits tracks pages written from cache to disk but it is the filling >of and updates to cache pages (pagreads and bufwrits respectively) that >causes LRU contention. > >Recalculate. BTW, I like 5% or less better and use 7% as my own alarm >value and 10% as my panic value. > >> BUT, I've also heard that Cleaners should be >= LRUs and Cleaners cannot >> exceed 128. > >Neither can LRUs Doug! The max LRUs value for 7.xx is 128 (for 5.xx it >was 32) and that triggers an annoying but harmless message at startup >in some versions telling you that your physical log and logical log >sizes are zero so I use 127 myself! Not to worry, Doug, targets are >just that - targets to be sought not necessarily hit. You can get the >same effect, of reducing flush times, by decreasing the >LRU_MAX/MIN_DIRTY parameters a bit. > >> So, if I set LRUs where I want them and max Cleaners, will the cleaners to >> LRU mismatch trash any gain I get from the increase in LRUs?? And what >> metrics (in addition to the KBP) would be best for monitoring?? > >The best metric is the checkpoint duration. If it becomes unacceptably >long you need to reduce the LRU_MAX/MIN_DIRTY or increase the number of >LRUS and CLEANERS if possible. > >Art S. Kagel Chris