Re: ONCONFIG - comments

Juan Pablo wrote: My comments below: > Hi: > Let me begin by saying thanks to all of the frequent posters to this group. > I wanted to offer my config for comments. > thanks > ============================================================ > Hola: > Muchas gracias por el tiempo y su ayuda. Estoy dejando mi archivo > ONCONFIG para poder recibir comentarios que me permitar optimizar la > performance del motor. > > gracias > > ============================================================ > HP-UX 11.11 (64 bits) > 4 CPU's > 12 GB Memory > Array VA7400 > Informix 7.31 FD8 > ============================================================ > <SNIP> > SERVERNUM 1 # Unique id corresponding to a Dynamic> Server instance > DBSERVERNAME magoo_shm # Name of default database server > DBSERVERALIASES magoo_tcp # List of alternate dbservernames > NETTYPE ipcshm,3,250,CPU # Configure poll thread(s) for nettype TCP connections should ALWAYS use NET VPs and shared memory only CPU VPs. Having said that, since you ONLY have 3 CPU VPs, that's indeed what's happening, the engine first assigns SHM polling threads to the CPU VPs then since there are no more CPU VPs it starts 3 NET VPs for the following NETTYPE entry. Just make it explicit and change to: NETTYPE soctcp,3,250,NET > NETTYPE soctcp,3,250,CPU # Configure poll thread(s) for nettype > DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed > env. > RESIDENT 0 # Forced residency flag (Yes = 1, No = 0) On HPUX with PA-RISC RESIDENT must always be set to -1 (on ia64 it's not mandatory, but at least set RESIDENT to 1). You don't specify your processor type, so... RESIDENT -1 > MULTIPROCESSOR 1 # 0 for single-processor, 1 for> multi-processor > NUMCPUVPS 3 # Number of user (cpu) vps > SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to> one > On HPUX on any platform always set NOAGE to 1 as HPUX is VERY aggressive about downgrading the priority of long running processes like IDS's oninit processes. So: NOAGE 1 > NOAGE 0 # Process aging > AFF_SPROC 0 # Affinity start processor > AFF_NPROCS 0 # Affinity number of processors> > # Shared Memory Parameters > > LOCKS 1024000 # Maximum number of locks > BUFFERS 850000 # Maximum number of shared buffers Even if all of your chunks are RAW and you are using KAIO, you should set NUMAIOVPS to a value between 4 and 6 or writes to the console and message logs will slow down the engine. > NUMAIOVPS 1 # Number of IO vps > PHYSBUFF 512 # Physical log buffer size (Kbytes) > LOGBUFF 512 # Logical log buffer size (Kbytes)> LOGSMAX 64 # Maximum number of logical log files > CLEANERS 128 # Number of buffer cleaner processes > SHMBASE 0x0 # Shared memory base address > SHMVIRTSIZE 632000 # initial virtual shared memory segment size > SHMADD 252800 # Size of new shared memory segments (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited > CKPTINTVL 300 # Check point interval (in sec) This is one of two specific values for LRUS (64 & 96) that I once suspected will cause very slow performance and high LRU contention. Informix was never able to reproduce the problem but several users reported it to me some years ago, and since it was never reproduced in the lab I suspect that it is still a problem. Please send me a copy of your onstat -p output so I can see if this is still true. Meanwhile, it is better to set LRUS to 95 or 97 to avoid the possibility that it is still a problem. > LRUS 96 # Number of LRU queues <SNIP> Your RA_ paramaters are too close together. With a fast disk array that has good caching this is not needed and will tend to reduce your cache hit percentages and increase buffer turnover which will drive performance down. I'd suggest lowering RA_THRESHOLD to 8. If you think you are performing lots of sequential IO then leave RA_PAGES alone, otherwise drop that to 16. I can tell from the onstat -p output if this is really a problem for you. > # Read Ahead Variables > RA_PAGES 32 # Number of pages to attempt to read ahead > RA_THRESHOLD 30 # Number of pages left before next group> It's a good idea to include one or more 'normal' dbspaces in DBSPACETEMP so they are used to create logged temp tables instead of the databases' home dbspaces or rootdbs. > DBSPACETEMP tmpdbs1,tmpdbs2,tmpdbs3,tmpdbs4 # Default temp dbspaces > ><SNIP> Art S. Kagel