BUFFERS! Arghhh!!! Please help before I do something silly!

I am confused. I posted last week with questions about how I should tweak my onconfig after I added memory to my RS6000 (from 4 gig to 8 gig). One of the comments that really stuck with me and in the responses many folks agreed with was that I should "up my BUFFERS" but today I did a search on recent posts within this discussion group and found lots of folks warning against raising buffers...thus the ARRGGGHHHH! I was all set to "up my BUFFERS" tomorrow evening during some scheduled maintenance, but now I am stressing out about it. Currently they are set to 150000 and I thought I would up them to 250000. My LRUS are 64 with MAX=2 and MIN=1. CLEANERS is 64. My onstat -p shows: Profile dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 837490266 1775724194 31188844029 97.31 60473686 93925793 1331212927 95.46 isamtot open start read write rewrite delete commit rollbk 25468560992 735055107 1059426981 17957662729 500662646 73455418 19821141 101437 136 gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs 0 0 0 0 0 0 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 1278095.70 240872.17 1203 3339 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans 45505823 10 13791335622 0 0 4186 11273841 22592571 ixda-RA idx-RA da-RA RA-pgsused lchwaits 85339757 24810309 590953578 697853835 35715367 This is my production server and while at the moment I simply a frazzled chic and not a damsel in distress, if I come in Thursday after this change to a sluggish database my tail will be a target and I will definitly be cooked!

On Tue, 27 Apr 2004 16:29:36 -0400, sumGirl wrote: More buffers CAN'T slow you down unless you do not have enough system memory to support them and it causes swapping, either by the engine or by your other apps. Go for it. Oh, BTW, avoid LRU=64 (or 32 or 96 also) any other values (like 63 or 65) are OK. I hold that there is a subtle bug in the LRU queue rehash algorithm that Informix has never tracked down that will cause excessive bufwaits if you set LRUS to any of those three particular values. After the change look at the onstat -P output, the first line (partnum 0) at the 'other' column. If there are a significant number of buffers in 'other' for partnum 0 after some normal activity, those are unneeded buffers and you can drop BUFFERS with no production effect, though some DBAs leave the overhead so that the unusual HUGE job does not flush all of production out of the cache. Art S. Kagel > I am confused. I posted last week with questions about how I should tweak my > onconfig after I added memory to my RS6000 (from 4 gig to 8 gig). One of the > comments that really stuck with me and in the responses many folks agreed > with was that I should "up my BUFFERS" but today I did a search on recent > posts within this discussion group and found lots of folks warning against > raising buffers...thus the ARRGGGHHHH! > > I was all set to "up my BUFFERS" tomorrow evening during some scheduled > maintenance, but now I am stressing out about it. Currently they are set to > 150000 and I thought I would up them to 250000. My LRUS are 64 with MAX=2 > and MIN=1. CLEANERS is 64. My onstat -p shows: > > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > 837490266 1775724194 31188844029 97.31 60473686 93925793 1331212927 95.46 > > isamtot open start read write rewrite delete commit > rollbk > 25468560992 735055107 1059426981 17957662729 500662646 73455418 19821141 > 101437 > 136 > > gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs 0 0 > 0 0 0 0 0 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 > 0 1278095.70 240872.17 1203 3339 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > 45505823 10 13791335622 0 0 4186 11273841 22592571 > > ixda-RA idx-RA da-RA RA-pgsused lchwaits 85339757 24810309 590953578 > 697853835 35715367 > > This is my production server and while at the moment I simply a frazzled > chic and not a damsel in distress, if I come in Thursday after this change > to a sluggish database my tail will be a target and I will definitly be > cooked!

On Tue, 27 Apr 2004 16:29:36 -0400, sumGirl wrote: My last should say (about using the onstat -P output): "and you can drop BUFFERS by the number shown in 'other' on that line with no production effect" Sorry about that. Art S. Kagel

sumGirl wrote: > I am confused. I posted last week with questions about how I should > tweak my onconfig after I added memory to my RS6000 (from 4 gig to 8 > gig). One of the comments that really stuck with me and in the > responses many folks agreed with was that I should "up my BUFFERS" but > today I did a search on recent posts within this discussion group and > found lots of folks warning against raising buffers...thus the > ARRGGGHHHH! > > I was all set to "up my BUFFERS" tomorrow evening during some > scheduled maintenance, but now I am stressing out about it. Currently > they are set to 150000 and I thought I would up them to 250000. My > LRUS are 64 with MAX=2 and MIN=1. CLEANERS is 64. My onstat -p shows: Have you addressed all the other points yet? Do you wish to deal with them one by one? If you are after reliable improvements in a hurry, you'll have to spend more time online discussing all the suggestions. I've reviewed the suggestions, and I think if you are NOT using KAIO then the setting NUMAIOVPS=2 is going to be the most crippling. What is the output of onstat -g iov? As to the increase in buffers... The counter-argument to adding hundreds of thousands of buffers is that more dirty pages can be stacked up, so your checkpoints can be longer. Art, how does the BTR formula and recommendations go? Anyway, list all the suggestions in point form, then either understand them and plan your action, or ask further questions until you know what each idea means and what the ramifications are.