KAIO on Sun
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:
AIO I/O queues:
q name/id len maxlen totalops dskread dskwrite dskcopy
kio 0 0 16 77771986 76823924 948062 0
adt 0 0 0 0 0 0 0
opt 0 0 0 0 0 0 0
msc 0 0 1 101 0 0 0
aio 0 0 2 33 8 2 0
pio 0 0 0 0 0 0 0
lio 0 0 0 0 0 0 0
gfd 3 0 1 1 1 0 0
gfd 4 0 1 1 1 0 0
gfd 5 0 0 0 0 0 0
gfd 6 0 1 1 1 0 0
AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup
errors
kio 0 i 18.9 36956299 36017743 938556 0 67745149 0.5 0
msc 0 i 0.0 101 0 0 0 102 1.0 0
aio 0 i 0.0 19 3 0 0 17 1.1 0
aio 1 i 0.0 9 1 1 0 11 0.8 0
aio 2 i 0.0 6 5 1 0 7 0.9 0
pio 0 i 0.0 0 0 0 0 1 0.0 0
lio 0 i 0.0 0 0 0 0 1 0.0 0
AIO big buffer usage summary:
class reads writes
pages ops pgs/op holes hl-ops hls/op pages ops pgs/op
kio 159281128 36017743 4.42 80227325 11735827 6.84 2003597
938556
2.13
adt 0 0 0.00 0 0 0.00 0 0 0.00
opt 0 0 0.00 0 0 0.00 0 0 0.00
msc 0 0 0.00 0 0 0.00 0 0 0.00
aio 1 1 1.00 0 0 0.00 0 0 0.00
pio 0 0 0.00 0 0 0.00 0 0 0.00
lio 0 0 0.00 0 0 0.00 0 0 0.00
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:
ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/online # Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)
ROOTSIZE 200000 # Size of root dbspace (Kbytes)
# Disk Mirroring Configuration Parameters
MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHYSDBS rootdbs # Location (dbspace) of physical log
PHYSFILE 2000 # Physical log file size (Kbytes)
# Logical Log Configuration
LOGFILES 50 # Number of logical log files
LOGSIZE 1000 # Logical log size (Kbytes)
SERVERNUM 24 # Unique id corresponding to a OnLineinstance
DBSERVERNAME ar7_1 # Name of default database server
DBSERVERALIASES ar7_1shm # List of alternate dbservernames
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed
env.
RESIDENT 1 # Forced residency flag (Yes = 1, No = 0)
MULTIPROCESSOR 0 # 0 for single-processor, 1 formulti-processor
NUMCPUVPS 1 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps toone
NOAGE 1 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
# Shared Memory Parameters
LOCKS 10000 # Maximum number of locks
BUFFERS 800 # Maximum number of shared buffers
NUMAIOVPS 3 # Number of IO vps
PHYSBUFF 16 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 50 # Maximum number of logical log files
CLEANERS 8 # Number of buffer cleaner processes
SHMBASE 0xa000000 # Shared memory base address
SHMVIRTSIZE 12288 # initial virtual shared memory segment size
SHMADD 8192 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 8 # Number of LRU queues
LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 50 # LRU percent dirty end cleaning limit
LTXHWM 50 # Long transaction high water markpercentage
LTXEHWM 60 # Long transaction high water mark
(exclusive)
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 32 # Stack size (Kbytes)
RA_PAGES 8 # Number of pages to attempt to read ahead
RA_THRESHOLD 4 # Number of pages left before next group
DBSPACETEMP tempdbs1 # Default temp dbspaces
OPTCOMPIND 2 # To hint the optimizer
This is a very small database, hence the low parameters. Still, performance
could be better.
Thanks, Dianne
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
Hi Art
Wow.............I just checked my bufwait ratio using your formula
and I get <drum roll>..................... 0.35%!!!
(Yes, I did remember to multiply)
IDS 7.31.UC2
Quad Processor K260
1 gig RAM
25 gig database
I did notice that my checkpoint times have gone down to 1 second or less
since I went to my HP Nike Model 20 array w/ all RAID 10.....
Here's my onstat -p
Informix Dynamic Server Version 7.31.UC2 -- On-Line -- Up 28 days
05:33:08 -- 275944 Kbytes
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
60734843 15347574 3019854116 97.99 15416718 11130352 1273497411 98.79
isamtot open start read write rewrite delete commit
rollbk
795701773 49886989 519594421 2712256867 696668973 9308500 1481774
262237 330
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 432275.87 27477.71 4210 8420
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
4578001 12 2016611412 0 0 957 3511926 4887631
ixda-RA idx-RA da-RA RA-pgsused lchwaits
2814863 584135 21738400 25027844 781857
Still getting a few bufwaits there, though........
I guess reading all your good useful postings about performance related
stuff has also helped <bg>
allen
"Art S. Kagel" wrote:
>
> 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