Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
In a thread on BUFFERS tuning, Esteban Casuscelli advised that if buffers are increased, LRUS should be increased too, since raising LRUS alone with the same buffers reduces buffers per LRU. The remaining messages were sumGirl thanking the group and light banter from neil truby and David Williams. No further technical content.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
I don't know what rule or recommendation are you following but if I
increase buffers I would increase LRUS to spread buffers along LRUS.
If you keep the same value for buffers and increase LRUS you 'll
decrease the number of buffer per LRU.
esteban.-
"David Williams" <djw@smooth1.fsnet.co.uk> wrote in message news:<c6rhje$vjg$1@news7.svr.pol.co.uk>...
> "sumGirl" <emebohw@netscape.net> wrote in message
> news:a5e13cff.0404290943.71aa323@posting.google.com...
> > > CLEANERS and LRUS seem to be sufficient without more info. How many
> chunks
> > > do you have? Set CLEANERS to at least 1.5*#chunks plus a few, if the 84
> is
> > > more than that then leave it. Looks like you're running 9.4, try
> reducing
> > > LRU_MAX/MIN_DIRTY to 1.0 and 0.5 or 1.0 & 0 that alone should cut
> checkpoint
> > > time in half.
> > > Art S. Kagel
> >
> > Thanks again Art. I have 137 chunks, so about 210? I was thinking that
> > there was a rule that when you raise the number of CLEANERS, you
> > should also up the LRUs? I likely am way off base there, I dont know.
> >
> > I will tweak the CLEANERS and then if needed lower my MAX/MINs...which
> > is another confusing subject based on the 9.4 Performance Guide.
> >
>
> CLEANERS 127
> LRU 127>
> After a while look at onstat -u and the informix ones at the top are the
> page cleaners. Check if
> any have all 0's against them and adjust accordingly allowing for futures
> peaks in load.
>
> > Thanks for all the wisdom!
This is the friendliest and most prolific discussion group I have ever
been in, no one has implied I am a knucklehead and thats very
refreshing!
-thanks :)
↪ replying to sumGirl
neil truby — — source: Usenet: comp.databases.informix
"sumGirl" <emebohw@netscape.net> wrote in message
news:a5e13cff.0404300621.2e638651@posting.google.com...
> This is the friendliest and most prolific discussion group I have ever
> been in, no one has implied I am a knucklehead ...
Yet.
Only because you're a girlie and we don't get to talk to many of those since
Impy went SQL Server.
:-)
↪ replying to neil truby
David Williams — — source: Usenet: comp.databases.informix
"neil truby" <neil.truby@ntlworld.com> wrote in message
news:Qvzkc.73$If2.23@newsfe5-gui.server.ntli.net...
>
> "sumGirl" <emebohw@netscape.net> wrote in message
> news:a5e13cff.0404300621.2e638651@posting.google.com...
> > This is the friendliest and most prolific discussion group I have ever
> > been in, no one has implied I am a knucklehead ...
>
> Yet.
> Only because you're a girlie and we don't get to talk to many of those
since
> Impy went SQL Server.
> :-)
>
Impy went SQL Server?? When?? I knew she disappeared...
>
↪ replying to sumGirl
David Williams — — source: Usenet: comp.databases.informix
"sumGirl" <emebohw@netscape.net> wrote in message
news:a5e13cff.0404300621.2e638651@posting.google.com...
> This is the friendliest and most prolific discussion group I have ever
> been in, no one has implied I am a knucklehead and thats very
> refreshing!
>
> -thanks :)
No problem..
..
..
..
see I can be nice...
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.