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

In article <4rsf8p$kt@sjx-ixn4.ix.netcom.com>, Stuart Cracraft <cracraft@ix.netcom.com> writes >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? > I'd say Informix Press is right. Possibly the maunals have not been updated recently. Remember when the inital set of manuals were written Informix had not been run on production systems. the Informix manual sound like an initial 'guess' by the programming team??? >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? > LRU's too low means the there is contention among the queues and Informix runs slower as processes have to wait before the can update the queues. There is one mutex per queue which controls give thread can update the queue. Remember queues come in pairs and as buffers are modified they are removed from the free queue and moved to the modified queue. Something has to stop two threads from moving the same buffer at the same time. >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? > Higher LRU reduces checkpoint duration - less contention for queues. Don't go silly though if LRU > CLEANERS you get no further benefit. Even each thread has it's own queue effectively than added queues has no effect on queue contention. >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. > >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. > >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. > >Your thoughts on LRU variable? Other relevant variables? > >--Stuart > > Yes lots of other factors affect checkpoint duration. First set LRUS=CLEANERS=number of physical disk on the system. Keep LRU_MIN_DIRTY and LRU_MAX_DIRTY at 5 and 7. run onstat -F to list types of disk writes - most should be LRU writes and Chunk Writes should be very low. onstat -D should indicate that disk writes are balanced across chunks Next check that if you sort the chunks by chunk id that they are spread round robin across the disks. i.e. with N physical disks that chunks 1 to N are all on different disks and chunks N+1 to 2*N are on different disk etc. Remember that chunks are cleaned in chunk id order so the above is required to allow avoid disk contention when page cleaning. E-mail me if you want more info. -- David Williams