RE: IDS 10 disk configuration
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
> [mailto:owner-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