Re: INFORMIX and utilization of system resources on HP-UX 10.20

Andrzej, It seems to me that you are using Baan. If that's so, you should check the following: 1. Use multiplexing. It will help a lot. Really. (you need porting set 6.1b.04 or later, check inf_maint6.1 -v) 2. Set LRU_MAX_DIRTY and LRU_MIN_DIRTY to 2 and 1 (Baan sugest those values) 3. You should increase CLEANERS and LRUs 64 or more could be ok. Don't use 32 for CLEANERS (read Art S. Kagel article in Tech Notes Vol 8 Is. 3 on performance tunning, available through informix tech info center (go to http://www.informix.com ). 4. you should increase SHMVIRTSIZE Baan demands much more than 16M. check ipcs -m in order to see a good size. 5. Set OPTCOMPIND to 0 6. Set RESIDENT to 1 7. Set MAX_PDQPRIORITY to 0 IMHO, those changes should make your machine perform better, in that order of importance. The problem during dbexport dbimport could be long checkpoints. That's another scenario. Check if that's happenning. However, if the performace problem is durring operation, check my numerals 1 to 7. I assume that you are making continuos back up (ontape -c). If not, thats your main problem. Also I would increase LOGFILES and set LOGSIZE so you fill a log every hour, not for performance, but to avoid headaches (that if you are running an OLTP system) More changes could be suggested by Baan. Regards, Andrzej Piotrowski wrote: > This is a multi-part message in MIME format. > --------------1BDF045F91B4032E8276E3E0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > I have a new double HP9000 system with MC/ServiceGuard, and I,ve > installed IDS 7.3 UC7 on this cluster. At the beginning I've notticed, > that database is running rather slowly (thats mean it is unacceptable > slow ;-). I've carefully read release notes for IDS 7.3 and I had tuned > kernel as it was described in this document, but the situation was the > same. For instance I am doing dbexport & dbimport and there is onperf > runnig at background, which monitors cpu utilisation (machine has 2 > CPU). The diagram is awfully shaterred. In 2-3 sec. periods CPU > utilization can change from 0% to 80% and back to 0% and it is regular. > On the other way average utilization measured in longer periods isn't > constant, but becomes smaller and smaller. I have already set NOAGE > parameter to 1 in $ONCONFIG. > > Anybody knows what is going on? I'm not sure, if I should search the > solution at the HP-UX kernel or IDS 7.3 tuning. > > I'm attching my onconfig file. > Thanks for any advice. > --------------1BDF045F91B4032E8276E3E0 > Content-Type: text/plain; charset=us-ascii; > name="onconfig" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="onconfig" > > #************************************************************************** > # > # INFORMIX SOFTWARE, INC. > # > # Title: onconfig.std > # Description: INFORMIX-OnLine Configuration Parameters > # > #************************************************************************** <snap> > # Logical Log Configuration > > LOGFILES 5 # Number of logical log files > LOGSIZE 60000 # Logical log size (Kbytes) <snap> > # Log Archive Tape Device > > LTAPEDEV /baan/worek/ltapedev # Log tape device path > LTAPEBLK 512 # Log tape block size (Kbytes) > LTAPESIZE 25165824 # Max amount of data to put on log tape (Kbytes) <snap> > NETTYPE ipcshm,1,300,CPU # Configure poll thread(s) for nettype > NETTYPE soctcp,1,300,NET # 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) <snap> > CLEANERS 8 # Number of buffer cleaner processes > SHMBASE 0x0 # Shared memory base address > SHMVIRTSIZE 16384 # initial virtual shared memory segment size > SHMADD 16384 # Size of new shared memory segments (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited > CKPTINTVL 300 # Check point interval (in sec) > LRUS 4 # Number of LRU queues > LRU_MAX_DIRTY 25 # LRU percent dirty begin cleaning limit > LRU_MIN_DIRTY 15 # LRU percent dirty end cleaning limit> <snap> > # Parallel Database Queries (pdq) > 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 # List of dbspaces to skip> > # OPTCOMPIND > # 0 => Nested loop joins will be preferred (where > # possible) over sortmerge joins and hash joins. > # 1 => If the transaction isolation mode is not > # "repeatable read", optimizer behaves as in (2) > # below. Otherwise it behaves as in (0) above. > # 2 => Use costs regardless of the transaction isolation > # mode. Nested loop joins are not necessarily > # preferred. Optimizer bases its decision purely > # on costs. > OPTCOMPIND 2 # To hint the optimizer <snap> -- Arturo Rodr'guez Mutis Director de Inform'tica Melexa Ltda. PBX (571) 360 3055 FAX (571) 360 2562 e-mail melexa@colomsat.net.co