Engine behaving strangely

Hi, WARNING, this is a long post, I've tried to include everything you will need to answer my question! ;o)) I have the following runtime environment: HP9000 K series, Dual processor, 128Mb Ram, (More on order but swamped in the quagmire of admin ) Approx 100 users, the machine runs both the server and the client applications communicating using shared memory. Running normal accounts type applications, nothing special. VERSIONS: HP-UX 10.20 hpk200:/> cat $INFORMIXDIR/etc/*-cr INFORMIX-4GL Run Time Facility Version 6.05.UC1 Copyright (C) 1984-1995 Informix Software, Inc. INFORMIX-SQL Run Time Facility Version 6.05.UC1 Copyright (C) 1984-1995 Informix Software, Inc. INFORMIX-OnLine Dynamic Server Version 7.24.UC5 Copyright (C) 1986-1998 Informix Software, Inc. ONCONFIG: hpk200:/> cat $INFORMIXDIR/etc/$ONCONFIG # Root Dbspace Configuration ROOTNAME rootdbs # Root dbspace nameROOTPATH /dev/online_root # Path for device containing root dbspace ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) ROOTSIZE 100000 # Size of root dbspace (Kbytes) # Disk Mirroring Configuration Parameters MIRROR 1 # Mirroring flag (Yes = 1, No = 0) MIRRORPATH /dev/ol_chunks/ol_ch_root_mirror # Path for device containing mirrored root MIRROROFFSET 0 # Offset into mirrored device (Kbytes) # Physical Log Configuration PHYSDBS dbs_plog # Location (dbspace) of physical log PHYSFILE 24400 # Physical log file size (Kbytes) # Logical Log Configuration LOGFILES 10 # Number of logical log files LOGSIZE 4000 # Logical log size (Kbytes) # Diagnostics MSGPATH /var/adm/online.log # System message log file path CONSOLE /dev/console # System console message path ALARMPROGRAM /opt/informix/etc/log_full.sh # Alarm program path # System Archive Tape Device TAPEDEV /dev/rmt/0m # Tape device path TAPEBLK 16 # Tape block size (Kbytes) TAPESIZE 2000000 # Maximum amount of data to put on tape (Kbytes) # Log Archive Tape Device LTAPEDEV /dev/null # Log tape device path LTAPEBLK 16 # Log tape block size (Kbytes) LTAPESIZE 2000000 # Max amount of data to put on log tape (Kbytes) # Optical STAGEBLOB # INFORMIX-OnLine/Optical staging area # System Configuration SERVERNUM 1 # Unique id corresponding to a OnLineinstance DBSERVERNAME live1 # Name of default database server DBSERVERALIASES live2 # List of alternate dbservernames NETTYPE ipcshm,1,250,CPU # Override sqlhosts nettype parameters NETTYPE soctcp,1,,NET # Override sqlhosts nettype parameters DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. RESIDENT 0 # Forced residency flag (Yes = 1, No = 0) MULTIPROCESSOR 1 # 0 for single-processor, 1 formulti-processor NUMCPUVPS 1 # Number of user (cpu) vps SINGLE_CPU_VP 1 # If non-zero, limit number of cpu vps toone NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors # Shared Memory Parameters LOCKS 500000 # Maximum number of locks BUFFERS 20000 # Maximum number of shared buffers NUMAIOVPS 30 # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 25 # Maximum number of logical log files CLEANERS 8 # Number of buffer cleaner processes SHMBASE 0x0 # Shared memory base address SHMVIRTSIZE 81928 # initial virtual shared memory segment size SHMADD 8192 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 200 # Check point interval (in sec) LRUS 8 # Number of LRU queues LRU_MAX_DIRTY 10 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 5 # 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) # System Page Size # BUFFSIZE - OnLine no longer supports this configuration parameter. # To determine the page size used by OnLine on your platform # see the last line of output from the command, 'onstat -b'. # Recovery Variables # OFF_RECVRY_THREADS: # Number of parallel worker threads during fast recovery or an offline restore. # ON_RECVRY_THREADS: # Number of parallel worker threads during an online restore. OFF_RECVRY_THREADS 10 # Default number of offline workerthreads ON_RECVRY_THREADS 1 # Default number of online worker threads # Data Replication Variables # DRAUTO: 0 manual, 1 retain type, 2 reverse type DRAUTO 0 # DR automatic switchover DRINTERVAL 30 # DR max time between DR buffer flushes (in sec) DRTIMEOUT 30 # DR network timeout (in sec)DRLOSTFOUND /opt/informix/etc/dr.lostfound # DR lost+found file path # Read Ahead Variables RA_PAGES 32 # Number of pages to attempt to read ahead RA_THRESHOLD 8 # Number of pages left before next group DBSPACETEMP dbs_temp1:dbs_temp2:dbs_temp3:dbs_temp4:dbs_temp5 # DUMP*: # For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No. DUMPDIR /dbwork # Preserve diagnostics in this directory DUMPSHMEM 1 # Dump a copy of shared memory DUMPGCORE 0 # Dump a core image using 'gcore' DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine) DUMPCNT 1 # Number of shared memory or gcore dumps for # a single user's session # ADT* # The following parameters control the type and level of secure auditing # present in the OnLine system. By default, ADTMODE is 0 and auditing # is disabled FILLFACTOR 90 # Fill factor for building indexes # method for OnLine to use when determining current time USEOSTIME 0 # 0: use internal time(fast), 1: get time from OS(slow) # Parallel Database Queries (pdq) # OFF => 0, LOW => 1, HIGH => 100 MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority DS_MAX_QUERIES

Two quick points about your configuration; it's recommended by HP and by Informix that you set RESIDENT=1; secondly, unless you want your entire UNIX server to freeze up, you must not use kaio (fixed in v7.24 UC8 I believe). Neil Truby Londis Stores Hampton Hill, UK

I get error 22 if I try to set RESIDENT = 1, I believe this is a known bug. -- --------------------------------------- Tony Flaherty aef@mfs.misys.co.uk Analyst Programmer Misys Financial Systems All statements and opinions are my own, Misys don't pay me enough to have opinions on their behalf . Neil Truby wrote in message <7mf69m$k6c$1@taliesin.netcom.net.uk>... >Two quick points about your configuration; it's recommended by HP and by >Informix that you set RESIDENT=1; secondly, unless you want your entire UNIX >server to freeze up, you must not use kaio (fixed in v7.24 UC8 I believe). > >Neil Truby >Londis Stores >Hampton Hill, UK > >

Ok, I think I've fixed the problem, <embarrassing blushes> It was a small validation table which has grown unexpectedly and didn't have the right indexes on it (can you say DOH!) However if anyone could answer my more general questions about BUFFERS and shared memory I would be grateful. --------------------------------------- Tony Flaherty aef@mfs.misys.co.uk Analyst Programmer Misys Financial Systems All statements and opinions are my own, Misys don't pay me enough to have opinions on their behalf .

Tony Flaherty wrote: > > Ok, > I think I've fixed the problem, <embarrassing blushes> It was a small > validation table which has grown unexpectedly and didn't have the right > indexes on it (can you say DOH!) DOH! Couldn't resist. ;-} > However if anyone could answer my more general questions about BUFFERS > and shared memory I would be grateful. RESIDENT probably gets an errno 22 (invalid argument to a system call) because you do not have enough memory to force residency. When you get the upgrade to a GIG or so definitely set RESIDENT it makes a BIG difference on most systems, HP most of all. Also you only have 128MB of physical RAM but the Resident shared memory segment (onstat -g seg) is about 80MB and the Virtual segment another 70MB (or the other way) which add up to over 150MB (see the onstat header line) which is definitely swapping up a storm on a table scan like you ended up diagnosing. Last, the NOAGE parameter is critical on HPUX because the OS is absolutely brutal about aggressively aging older processes and such aged processes get HUGE timeslices when they are finally given one to make up for some of the delay caused by the lowered priority. So you have the engines processes doing nothing for long stretches and then hogging the machine for a long time in between sleeps. Art S. Kagel