RE: 9.40 vs 9.21 performance

Eric Rowell wrote > Are you running Solaris? No, Tru64 5.1B as from 2 days earlier ( The management did not want it simple:-)) ES40 2GB, 3 CPU > > What is your ONCONFIG settings? PHYSDBS rootdbs # Location (dbspace) of physlog PHYSFILE 50000 # Physical log file size (Kbytes) LOGFILES 41 # Number of logical log files LOGSIZE 20000 # Logical log size (Kbytes) NETTYPE soctcp,2,,NET # Configure poll thread(s) for nettype NETTYPE ipcshm,2,,CPU # Configure poll thread(s) for nettype DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. RESIDENT 1 # Forced residency flag (Yes = 1, No = 0) MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor NUMCPUVPS 2 # Number of user (cpu) vps SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors # Shared Memory Parameters LOCKS 1000000 # Maximum number of locks BUFFERS 200000 # Maximum number of shared buffers NUMAIOVPS 2 # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes) CLEANERS 16 # Number of buffer cleaner processes SHMBASE 0x200000000 # Shared memory base address SHMVIRTSIZE 564132 # initial virtual shared memory segment size SHMADD 262144 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 300 # Check point interval (in sec) LRUS 15 # Number of LRU queues LRU_MAX_DIRTY 10.000000 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 5.000000 # LRU percent dirty end cleaning limit LTXHWM 70 # Long transaction high water mark percentage LTXEHWM 80 # Long transaction high water mark (exclusive) TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 128 # Stack size (Kbytes) DYNAMIC_LOGS 2 OFF_RECVRY_THREADS 10 # Default number of offline worker threads ON_RECVRY_THREADS 2 # Default number of online worker threads DRINTERVAL 30 # DR max time between DR buffer flushes (in sec) DRTIMEOUT 30 # DR network timeout (in sec)DRLOSTFOUND /usr/informix94/etc/dr.lostfound # DR lost+found file path # CDR Variables CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional) CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds) CDR_QUEUEMEM 32000 # Maximum amount of memory for any CDR queue (Kb ytes) CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 ma x) CDR_SERIAL 0,0 # Serial Column Sequence CDR_DBSPACE # dbspace for syscdr database CDR_QHDR_DBSPACE # CDR queue dbspace (default same as catalog) CDR_QDATA_SBSPACE sbspace1 # List of CDR queue smart blob spaces CDR_MAX_DYNAMIC_LOGS -1 # Dynamic log addition disabled by default RA_PAGES 128 # Number of pages to attempt to read ahead RA_THRESHOLD 64 # Number of pages left before next group DBSPACETEMP tempdbs1,tempdbs2 # Default temp dbspaces DUMPDIR /usr/informix94/logs # 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 Dynamic Server) DUMPCNT 1 # Number of shared memory or gcore dumps for # a single user's session FILLFACTOR 90 # Fill factor for building indexes MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority DS_MAX_QUERIES # Maximum number of decision support queries DS_TOTAL_MEMORY # Decision support memory (Kbytes) DS_MAX_SCANS 1048576 # Maximum number of decision support scans DATASKIP off OPTCOMPIND 2 # To hint the optimizer ONDBSPACEDOWN 0 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAITOPCACHEMAX 0 # Maximum optical cache size (Kbytes) > > What was memory usage at the time of the slow down? Segment Summary: id key addr size ovhd class blkused bl kfree 16384 1397639169 200000000 570425344 436992 R* 137542 1722 16385 1397639170 222000000 578813952 18176 V 28768 112544 15362 1397639171 244800000 8388608 768 M 1232 816 15363 1397639172 245000000 8388608 768 M 1230 818 Total: - - 1166016512 - - 168772 115900 > What if any env settings where set at startup that normally where not? > Standard settings. No PDQ. > > > On Wed, 2004-02-25 at 04:43, Colin Bull wrote: > > Neil Truby > > > > > > > > > We've been trying to expand this into a general case that IBM > > > Tech Support > > > will look at, and not been too successful. > > > This leads me to suspect that the problem may exist with > databases and > > > tables that have been successivley converted from 7 -> 9 > -> 9.40 .... > > > Will keep looking. > > > > > > > > We have just gone live with an upgrade to 9.4 FC2 and one table with > > 300,000 rows by 107 bytes took consistently 6-7 minutes on > an underspecced test servers. On the live server after about > 15 hours, we > > killed the process off, dropped all contraints and indexes, > and loaded data in 3 minutes. Constraints and indexes took another 3 > > minutes. The CPU load during the first attempt was around > 90% most of the time. We have not got a clue why !! > > > > Colin Bull > > c.bull@videonetworks.com > > ________________________________________________________________________ This email has been scanned for all known viruses by the MessageLabs Email Security System. ________________________________________________________________________ sending to informix-list

Colin Bull wrote: > ( The management did not want it > simple:-)) They hired you, didn't they? :o) -- "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche