Re: Informix 7.1.2.UC1: LRUS in /usr/informix/etc/onconfig

Stuart Cracraft wrote: > > The On-Line manual on page 12-36 says LRUS should be either 4 or the > number of virtual cpus -- this is a very low number. > > Most of the Informix Press tuning books and chapters on tuning, say > LRUS should be equal to CLEANERS and shouldn't be too small. This is > typically a higher number. > > Who is right? Why the difference? These new recommendations also mystified me, when the default upto 5.xx was always 8. However, in my experience the tuning value of setting LRUS is over rated. > On an interactive time-sharing system attempting to service many > user's interactive GUI queries, what is the disadvantage of setting > LRU's too low? Could a low LRU be tied to a longer checkpoint > duration? I can only assume that Informix's thinking is that it is quicker to scan a linked list, than to skip to a new queue. > That is, if LRU_MIN_DIRTY and LRU_MAX_DIRTY are both held > constant, say 5 and 7 respectively, does a higher or lower LRU result > in a shorter checkpoint duration? My feeling is that if you need to lower these parameters this much in order to reduce chunk writes, then your LRU queues are too long, and increasing LRUS would shorten them. > I want the absolute bare minimum checkpoint duration of one or > two seconds long on a SparcCenter 1000e with 768mb of memory, > 6 cpus, 4 Sparc Storage Arrays having 30 disks each. If you are having problems with the checkpoint interval being too frequent then you should be looking at increasing the size of your physical log. A common mistake is to make the checkpoint interval too long, in order to reduce the number of checkpoints. This however means that the duration of each checkpoint is increased. So look at obtaining an interval of between 5 and 10 minutes, depending on the system. > So far, setting LRU_MIN_DIRTY and LRU_MAX_DIRTY down to > 5 and 7 respectively, with CLEANERS at 29 and LRU > at 5 (LRU formerlyl at 16) has resulted in approximately 1/5th the > checkpoint durations of when CLEANERS was at 29 and LRU was at 16 > and LRU_MIN_DIRTY was at 55 and LRU_MAX_DIRTY was at 60. But I'd > like to get it down another factor of 2. Right now, my checkpoint > durations are at 5-10 seconds which is just at the outside limit of > tolerable interactive response in a GUI. It really isn't responsive. You mention CLEANERS=29, but how many disks do you have? You should start with one page cleaner per disk spindle and work up from there. If you have too many page cleaners running, then they may well be condending for the same disk. > I can't have a checkpoint interrupt a user's GUI query to the > database engine and slow it down by 5-10 seconds. Hence my > search for the "mythical" 1-2 second checkpoint. I quite agree. What is the balance of idle writes to chunk writes? If there aren't enough idle writes occuring then you need to increase LRUS (since LRU_MAX_DIRTY and LRU_MIN_DIRTY are already so low) in order for LRU_MAX_DIRTY to kick in earlier and increase idle writes. Hope these are enough thoughts, -- Mark. +-------------------------------------------------------------------------+ |Mark D. Stock - The West Solutions Group http://www.west.co.za | | | |Email: marks@west.co.za +------------------------------------------------+ |Tel: +27 11 803 2151 |If it doesn't work... force it! | |Fax: +27 11 803 2189 |If it breaks... it needed replacing anyway! | |Cell: +27 83 250 2325 |Well, that's how I code anyway! | +------------------------+------------------------------------------------+