Neil

All the events that take place at a checkpoint, including waiting for all
critical processes to get out of critical and cleaning BUFFERS, need to take
place. Then, if you have 10 times as many dirty BUFFERS in a chunk then
this component of a checkpoint (page cleaner) will take longer - probably
less than 10 times as long.

Are you running Fuzzy checkpoints? This will help speed checkpoints as will
having the MAX DIRTY set lower (it is a FLOAT variable). Also have
sufficient Cleaners, one for each chunk. Confirm your dirty buffers with
onstat -R.

MW

> -----Original Message-----
> From: owner-informix-list@iiug.org
> [mailtowner-informix-list@iiug.org] On Behalf Of Neil Truby
> Sent: Wednesday, 3 August 2005 10:43 a.m.
> To: informix-list@iiug.org
> Subject: Re: IDS 10 disk configuration
>
> "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> news:42EFD602.60800@bloomberg.net...
> > david@smooth1.co.uk wrote:
> >> At checkpoint time chunks are assigned round robin to page
> cleaners
> >> for cleaning.
> >>
> >> ONE CHUNK WILL ONE GET ONE PAGE CLEANERS FLUSHING IT'S WRITES AT
> >> CHECKPOINT TIME.
> >>
> >> We had a 60Gb chunk and someone was loading lots of data into it.
> >>
> >> 5 minute checkpoint interval and checkpoints up to 6 minutes long!
> >>
> >> Just what I needed when running a program that inserts into temp
> >> tables.
> >>
> >> My program went from 2 minutes to 20 minutes!
> >
> > Good point David. The solution would be to use fractional
> values for
> > LRU_MIN/MAX_DIRTY to make sure that there are very few
> dirty pages at
> > checkpoint time. Not a complete solution, but it will help
> with 'larger'
> > chunks if not 'huge' ones.
>
>
> Are you both saying that an inevitable consequence of large
> chunks is long checkpoint times at times of high update?
>
> I guess this isn't just an IDS 10 thing ...?
>
>
>
>


sending to informix-list

Murray Wood (IList) schrieb:
> Neil
>
> All the events that take place at a checkpoint, including waiting for all
> critical processes to get out of critical and cleaning BUFFERS, need to take
> place. Then, if you have 10 times as many dirty BUFFERS in a chunk then
> this component of a checkpoint (page cleaner) will take longer - probably
> less than 10 times as long.
>
> Are you running Fuzzy checkpoints? This will help speed checkpoints as will
> having the MAX DIRTY set lower (it is a FLOAT variable). Also have
> sufficient Cleaners, one for each chunk. Confirm your dirty buffers with
> onstat -R.
>

Still the I/O for cleaning the LRU buffers during checkpoint
is by far more efficient than LRU writes.
One has to find the balance longer checkpoints and less I/O from
LRU writes between 2 checkpoints versus shorter checkpoints and
(much?) more write-I/O from LRU writes all the time.

If you issue 'onstat -R | tail' a few seconds before a checkpoint
takes place you get the picture of how much there is to do
for the CLEANERS
Of course CLEANERS at least equal to LRUS is a must.
For those using onmode -B,
CLEANERS > LRUS is a must.
(look into onstat -F and see the 'C' flagged cleaners
additional to one 'F' flagged cleaner per LRU, if it comes
heavy)

These findings are the only reason why it can be useful to
have less than 128 / 512 LRUS. If you do not have 512 LUNs
configured to you systems and have 512 CLEANERS at the same time
starting I/O you can watch nice but unwanted I/O queueing

dic_k

--
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe