RE: KAIO on Sun and CPU question and update statistics

Another related question. This database is about 500 Mb. in size. I currently run update statistics high on the entire database because it only takes about 10 minutes to do. Is this detrimental to performance? I know all about the medium distribution only, high on index, low on the rest guidelines. I do this on our big database. But will high on all hurt anything on this little database? Thanks, Dianne -----Original Message----- From: Dianne Pendleton Sent: October 26,1999 2:50 PM To: 'informix-list@iiug.org' Subject: RE: KAIO on Sun and CPU question Another related question. This server has 2 cpu's. Following Informix's guidelines, I have the database set up as a single-processor server. This server is only used for one application, Remedy. There is only one database. What would be the down-side to setting up the database as a multiprocessor with NUMCPUVP's = 2? Thanks, Dianne -----Original Message----- From: Dianne Pendleton Sent: October 26,1999 2:22 PM To: informix-list@iiug.org Subject: 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 db

dianne.pendleton@autodesk.com wrote: > > Another related question. > > This database is about 500 Mb. in size. I currently run update statistics > high on the entire database because it only takes about 10 minutes to do. > Is this detrimental to performance? I know all about the medium > distribution only, high on index, low on the rest guidelines. I do this on > our big database. But will high on all hurt anything on this little > database? [SNIP] No. It actually supplies better stats in general than the "guideline" that you mention does, it just takes much longer to run. If you are happy with the runtime and have the sort memory and disk space to do the whole database at once, great! No harm, no worries. Art S. Kagel