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

This is a multi-part message in MIME format. --------------C4C26D4394 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Williams wrote: > > 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??? Sorry, but at the time the manuals were written, Informix Turbo/OnLine had been run on production systems for 5+ years. The tuning books are the unupdated versions. With V5.X, tuning LRUS and CLEANERS the same made sense. There was no way to otherwise guage the degree of simultaneous access by users (as that number would presumably vary), so tuning it based on cleaning activity was the way to go. With ODS (V7.X), the degree of simultaneous access is easy to determine: it equals the number of CPU VPs. So tuning LRUS and CPUVPS the same makes perfect sense. > 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. A mutex is set as the buffer is removed from a queue. It is then released. The process is repeated when the buffer is put back on. If the mutex for the receiving queue is busy, the thread will pick the next queue in line to place it on. It will cycle until it finds an available queue. Also keep in mind that only one thread per VP will be performing such an activity at a given time. So you can only have at most CPUVPS threads accessing the Qs. If you have CPUVPS Qs, you have enough. > 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. LRUs have no apprecialble affect on checkpoint duration. Buffers are sorted from the general pool for checkpoints, not from the LRU queues. The only issue is placing all the buffers onto the clean Q, which is synchronized to minimize 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. Again depends on V5.X or 7.X. For 7.X, Cleaners do little more that schedule i/o, whereas in 5.X they do the i/o. Having CLEANERS==disks on a 7.X system (where hundreds of disks is not uncommon) would be silly. For that matter, in a large 5.X system, it is equally silly. How much i/o bandwidth do you have available? At some point, you would flood your i/o bus, so keeping CLEANERS below that threshold is your best bet (consider the number of disks per controller, etc.). To get your checkpoints taking less time, the best solution is setting LRU_MAX_DIRTY and LRU_MIN_DIRTY lower. 5 and 7 is actually on the high side for your goal. Lowering them will reduce the number of buffers to be flushed (and the size of your buffer pool is a critical factor here - the larger the pool, the lower you make these values) and thus reduce your i/o time during checkpoints. That quickens the checkpoint. For the most part, the rest is just noise. > 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. 5.X era advice. With 7.X, async i/o is there along with parallel processing, so chunks are cleaned in parallel. I wouldn't worry about reconfiging your disks to get the "right" chunk ids. -- Dave Kosenko, Informix Professional Services **************************************************************************** While it is true that there is more than one way to skin a cat, the cat himself generally fails to appreciate the differences. --------------C4C26D4394 Content-Type: text/plain; charset=us-ascii; name="Ifxdiscl.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Ifxdiscl.txt" ************************************************************************* Note: please do not send me email asking about features, or asking about Informix problems and how to solve them. I answer what questions I can in this forum (comp.databases.informix) when I have the time to spare. For questions on features, call your local sales rep or check out the Informix web site (http://www.informix.com). For technical problems, call Informix tech support. ************************************************************************* Disclaimer: All opinions expressed in this message are well-reasoned and