RE: KAIO on Sun

Thanks to all for your input so far. (SunOS 5.5.1, IDS 7.22.UC2.) I increased the BUFFERS to 20,000, changed SINGLE_CPU_VP to 1, lowered NUMAIOVPS to 1.Here's onstat -p now: INFORMIX-OnLine Version 7.22.UC2 -- On-Line -- Up 00:52:42 -- 58056 Kbytes Profile dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 54931 60925 1821930 96.99 7276 10531 5640 0.00 isamtot open start read write rewrite delete commit rollbk 1457671 19974 39035 741930 118 3401 4 3227 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 430.09 108.64 11 22 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans 10136 1 4594064 0 0 4 107 515 ixda-RA idx-RA da-RA RA-pgsused lchwaits 43976 0 623 44323 0 The new bufwait ratio is: BR = (bufwaits / (bufwrits + pagreads)) * 100 = (10136 / (5640 + 50925)) * 100 = 17.9% That is worse than before and %cached on writes say 0.00! We've only been up about an hour with these changes. Should I monitor it for a while or change the LRUS and CLEANERS and bounce it again. Thanks, Dianne -----Original Message----- From: Art S. Kagel [mailto:kagel@bloomberg.net] Sent: October 27,1999 9:20 AM To: dianne.pendleton@autodesk.com Subject: Re: KAIO on Sun Dianne, You whole problem MAY be LRU contention. Your bufwait ratio is: BR = (bufwaits / (bufwrits + pagreads)) * 100 = (10977383 / (2118358 + 79053804)) * 100 = 13.52% Anything over 10% means performance death and values under 7% are preferred. To resolve this there are three parameters that affect bufwaits: BUFFERS: More buffers will reduce contention somewhat. With ONLY 800 buffers and millions of pages read and written I'd say this MAY be the biggest problem. Increase buffers so that 25% of memory is used you are now using only 1.6MB for buffers. LRUS: Much contention is for an LRU queue so that a new page can be read into a buffer or so that a buffer can be modified. If adding lots of buffers does not help increase LRUS to 32 or more (avoid 64 it triggers a bug) up to 127 (128 triggers an annoying but harmless message that looks deadly). Adjust CLEANERS to match LRUS. RA_: The readahead parameters affect LRU and buffer contention if set too high. Your values are on the low side for what I presume are singleton disks so this is not a problem. Art S. Kagel dianne.pendleton@autodesk.com wrote: > > SunSparc 20. SunOS 5.5.1. ODS 7.22.UC2. > > Does anyone have experience on this platform with KAIO verses AIO? > It appears that KAIO is on. I am wondering if it would be better to have > KAIO off and use AIO. > Here are some onstats: [SNIP] > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > 76823925 79053804 400538589 80.82 948062 2003597 2118358 55.25 > > isamtot open start read write rewrite delete commit > rollbk > 287997994 2355467 5012323 142620022 219283 348697 209260 330998 3 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > 0 0 0 102085.19 29782.74 3966 13180 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > 10977383 291 878182455 3 0 440 47442 89835 > > ixda-RA idx-RA da-RA RA-pgsused lchwaits > > Onconfig information: [SNIP] > LOCKS 10000 # Maximum number of locks > BUFFERS 800 # Maximum number of shared buffers [SNIP] > CLEANERS 8 # Number of buffer cleaner processes [SNIP] > LRUS 8 # Number of LRU queues [SNIP] > RA_PAGES 8 # Number of pages to attempt to read ahead > RA_THRESHOLD 4 # Number of pages left before next group [SNIP]> This is a very small database, hence the low parameters. Still, performance > could be better. > > Thanks, Dianne