> Remember that a checkpoint is activated by time , or when the
> LRU_MAX_DIRTY is achieved.> The 9.4x version have decimal values for these parameters.
>
> Regards. Ferronato
Ferronato
AFAIR, LRU_MAX_DIRTY is set to reduce the amount of data to be written
during checkpoints, not to trigger checkpoints.
Reinhard.
↪ replying to Habichtsberg, Reinhard
Habichtsberg, Reinhard wrote:
>
>> Remember that a checkpoint is activated by time , or when the
>> LRU_MAX_DIRTY is achieved.>> The 9.4x version have decimal values for these parameters.
>>
>> Regards. Ferronato
>
> Ferronato
>
> AFAIR, LRU_MAX_DIRTY is set to reduce the amount of data to be written
> during checkpoints, not to trigger checkpoints.
>
> Reinhard.
Yes... The checkpoint will be triggered if you get to 75% of the physical buffer.
Th LRU_MAX_DIRTY will trigger the page cleaners to flush the dirty buffers.
This intends to reduce the number of buffers to be written at checkpoint time.
Decreasing the CHKPINTRVL (maybe misspelled it) will trigger more checkpoints, but hopefully they'll be shorter...
Checkpoint tunning is a very complex subject... With big checkpoint durations you'll have too many system blocking...
Some times you may choose to increase the checkpoint interval to minimize these stops (assuming the page cleaners can keep up with the work)...
But if your system crashes it can take a very long time to recover...
It's also worth taking a look (onstat -F -r 1) during your checkpoints. If you see that for the most time there is only one cleaner working (the "data" column represents the chunk), then your problem may be solved by better data distribution or possibly table fragmentation
There is no simple solution...
I have the feeling that there was some presentation or chat with the labs webcast about this issues... But I can't recall where I've seen it.
Some of this will probably suffer big changes in the future in a galaxy near you... :)
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...