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

Mark D Stock wrote: > > 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. If LRU_MAX_DIRTY is set to 5 with 10 LRUS, the start flush point is going to be essentially the same as a LRU_MAX_DIRTY of 5 with 20 LRUS. Why? Because dirty buffers are generally spread evenly across all Qs (we access LRUs randomly, more or less). So while it takes fewer dirty buffers to reach that point, because you now have more LRUS to work with, they will reach that point no faster. So increasing LRUS will not have a significant impact on reducing chunk writes. As I have said here before, to reduce chunk writes, decrease LRU_MAX_DIRTY. > > > 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. The issue doesn't appear to be checkpoint *frequency*, but rather checkpoint *duration*. Increasing the physlog size will only make an impact if your CKPTINTVL is NOT driving checkpoint frequency. The downside to LESS frequent checkpoints is longer fast recovery time in the event of a crash. > > 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. This is only true if you have not appropriately tuned LRU_MAX_DIRTY; with it set low, assuming your i/o system can keep up, checkpoints will be no longer when they occur infrequently than when they occur frequently. If 10% of the buffer pool is dirty, it will take X amount of time whether the previous checkpoint was 3 or 30 minutes ago. > 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. As I have said before, such advise is only valud for 5.X or earlier versions. With DSA (V 7.X), cleaners do little actual work. Setting them == to the number of disks is most likely excessive. With DSA, number of AIO Vps is the significant factor (unless KAIO is enabled for your port). > 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. Again, increasing LRUS will do little to nothing to decrease checkpoint duration. Decreasing LRU_MAX_DIRTY as a direct influence on this - the lower it's value, the faster the checkpoint. QED. -- 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.