Re: LRU Parameters

David Kosenko wrote: > > Also sprach "Art S. Kagel" <kagel@bloomberg.com> : > > :By the way: Joao's CLEANERS value is much too low. With 32 LRUs one > :should have 32 CLEANERS unless one has > 32 chunks then add more than > :32 cleaners. You should have: #Chunks <= #CLEANERS >= #LRUs to > :minimize checkpoint times. > > I don't know that I agree with that, at least if you are talking about a 7.X > system. In 5.X, where CLEANERS actually handled performing the physical i/o, > what Art states above is unquestionably true. However, with 7.X, CLEANERS are > little more than administrative threads, going through the LRU queues or buffer > pool and placing page pointers onto the i/o queues. This means they have a LOT > less work to do (and never block), so a smaller number of cleaners should be > able to handle a lot more work than their 5.0 brethren. If you are using KAIO, you MIGHT want to restrict the CLEANERS further. Some have suggested that CLEANERS <= #CPU VPs is reasonable since the KAIO threads are linked to the number of CPU VPs and more than that many CLEANERS adds little. This is logical but misses that point that while some cleaners are performing administrative functions others could be queuing I/Os. Also with a fast disk farm I/Os are not the bottleneck to checkpoint times that they once were. I would say that even if you are using KAIO, then CLEANERS can exceed the number of KAIO threads and you WILL see improved checkpoint times. I'd guess that one can take advantage of 1.5*#CPU VPs < CLEANERS < 2*#CPU VPs. Try it, I'm either right or I'm wrong. Report back to us here, I'm open to being wrong. I'm not wrong often ;-), but it happens! :-( On the other hand, even in 7.xx, if you are using AIO VPs then my rule ABSOLUTELY holds and I would add: #LRUs <= #CLEANERS >= #Chunks #Chunks <= #AIO VPs <= 1.5 * #Chunks (For 7.21+, make that 2.5*Chunks for 7.1x [I/O was improved in 7.21]) BTW This all assumes that you normally have more than 500 dirty buffers at checkpoint time. If there are fewer than 500 dirty buffers (hard wired value) the engine decides to chuck the expensive calculations of how many CLEANERS to launch for which buffers and just launches one CLEANER and waits for it to finish. If you have fewer than 500 dirty buffers at checkpoint time (onstat -R just before a checkpoint) CLEANERS is irrelevent to the checkpoint duration. However, my rules still hold since at LRU write time (see onstat -F) each LRU that has reached the LRU_MAX_DIRTY threshhold will need its own CLEANER to make sure that the LRU is unlocked as quickly as possible. A CLEANER must be available when the LRU reaches LRU_MAX_DIRTY or unneccessary BUFWAITS will ensue. Art S. Kagel