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

Stuart Cracraft wrote: > 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? In my opinion the disadvantage of setting the number of LRUs too low (means < number of CPU-VPs) are resulting waits on mutexes. I don't think this has any influence on checkpoints. > 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. > In the way i'm thinking of checkpoints, the following happens: After stopping all transactions, OnLine first flushes the Physical-Log-Buffer to disc. If the Physical-Log-Buffer is too big, only this action can last more than 1 second!!! Then OnLine starts all the Cleaners each on one chunk in the same order as these chunks were added to the OnLine-Instance. If you first added 30 chunks on the first array, then added 30 chunks on the 2nd array, ... this will result in OnLine starting 30 Cleaners which are writing to your first array, while all the other arrays are idle!!! If you are running RAID on your SSA's this should additionally result in heavy headpositioning on each disk. Imho, solving this can only be done by a reorganisation of the whole storage. > 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. A general hint in tuning is not to change too many parameters at once. I think the changed number of LRUs had no influence on the above result. I would try to reduce LRU_MAX_DIRTY and LRU_MAX_DIRTY step by step until you either got what wanted or you reached 1 and 0. If your checkpoints still last longer than you are willing to accept, perhaps try a smaller Physical-Log-Buffer. But maybe i'm missing something. So what do those people from Menlo Park, ... say? By the way, what is your checkpoint interval? Are the checkpoints occurring after this intervall or do they occure earlier, initiated by a 75% dirty Physical-Log-Buffer? > > 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? > > --StuartGood luck anyway martin - Dr. Materna GmbH | EMail: Martin.Berns@Materna.De Martin Berns | Tel.: +49 231/5599-231 Vosskuhle 37 | FAX: +49 231/5599-574 D-44141 Dortmund | X.400: S=BERNS;G=MARTIN;P=MATERNA;A=UMI-DE;C=DE