RE: DS 7.23 performance

My replies embedded in your message, and the notes refer to the parameter(s) immediately above them. Remember the golden rule of tuning: Change ONLY one thing at a time and examine the effects of that change before moving on to another. Best regards, Nigel +-------------------------------------------------------------+ |Name : Edmund Nigel Gall Tel: (868) 636 3153 | |Title : Information Systems Specialist Fax: (868) 679 3770 | |Company: Process Plant Services Limited | |Address: Atlantic Avenue, Point Lisas Industrial Estate | | Point Lisas, Couva, Trinidad & Tobago, W.I. | +----- mailto:nigelg@ppsl.com ------ http://www.ppsl.com -----+ -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org]On Behalf Of Niclas Bjorkdahl Sent: Thursday, September 17, 1998 2:32 AM To: informix-list@iiug.org Subject: DS 7.23 performance We have upgraded from Online 5.06 to Dynamic Server 7.23.FC1 on OSF1 ver 4.0 and have major performance problems. Some applications now are up to 6 times slower. Applications also once in a while receives error -25587 and -25588. I've tried to increase LOCKS and BUFFERS, but then receives: oninit: Fatal error in shared memory creation ...and in the online.log: 17:21:26 shmat: [ENOMEM][12]: out of available data space, check systemMAXMEM 17:21:26 mt_shm_init: can't create virtual segment Increasing SHMVIRTSIZE causes: 13:13:10 shmat: [EINVAL][22]: shared memory base address illegal 13:13:10 using 0x2025ce000, needs 0x800000 13:13:10 mt_shm_init: can't create virtual segment ONCONFIG-PARAMETERS: SERVERNUM 0 # Unique id corresponding to a OnLineinstance DBSERVERNAME ebba_on DBSERVERALIASES t2000 # List of alternate dbservernames NETTYPE ipcshm,,,CPU # Configure poll thread(s) for nettype NETTYPE soctcp,,,NET # Configure poll thread(s) for nettype * Put the pol thread that is used by most users on the CPU VP. For e.g., if most of your suers are using sockets, then since the CPU VP is the one which gives the best performance, put ththe spctcp threads on the CPU VP, and let the ipcshm be on the NET VP. The ipcshm threads run on the same box as the database instance anyway, so performance wil not decrease for connections via ipc by much, but your socket connections will benefit from this. Result: faster user connections for soctcp users. DEADLOCK_TIMEOUT 60 # Max time to wait of lock indistributed env. RESIDENT 0 # Forced residency flag (Yes = 1, No = 0) * Does your platform support Forced Rsidency? If so, use it. We're about to install on a brand new 4100 running DU 4.0D and IDS 7.23.FC4, but I haven't read the Release Notes yet, so I don't know if forced residency is supported offhand. MULTIPROCESSOR 0 # 0 for single-processor, 1 formulti-processor * I presume you have only one or two processors? If to, then set this to 1. NUMCPUVPS 1 # Number of user (cpu) vps * Although Informix advises you to set this to be identical to the number of CPUs you have, some of us are of the opinion that since this just determines the number of actual processes (oninits) available in the UNIX process queue, then having more than the number of physical CPUs is not a bad thing (in theory); it just means that your Informix CPU VPs collectively spend more time on the CPU (as one is timesliced out, the other gets to run; your users are happy). Try icreasing this, in incrementals of one, after you've done the other things the other gurus have suggested (please do not mistake me for one of that elite group). SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vpsto one * If you're going to increase the NUMCPUVPS, then set this 0 (zero). Otherwise set it to 1. NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors * Use these if you have more than one CPU (not CPU VPs). Also, if the NOAGE parameter is supported (check your Release Notes), then set it to 1. # Shared Memory Parameters LOCKS 8000 # Maximum number of locks * IS your system starving for locks? Check the output of onstat -p; the lokwaits. Read the manual for a description of the onstat -p output. BUFFERS 2000 # Maximum number of shared buffers * This is quite low. Check the bufwaits value of onstat -p. I recall one of the gurus, Art Kagel, suggesting recently that perhaps a good figure is 5000 buffers for every gigabyte of data. NUMAIOVPS # Number of IO vps * Why is this blank? Even if you have KAIO (Kernel AIO) enabled, you should still have one AIO VP. PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 9 # Maximum number of logical log files * Not that it has any direct, immediate, impact on performance (until you get into a long transaction), but you may want to consider bumping this up to the teens at least. What's the size of your logical logs themselves? The size and number of these, together with the values of LTXHWM and LTXEHWM determine if users will be frozen when a rogue long transaction hits your system. For me, the more logical logs the better. CLEANERS 1 # Number of buffer cleaner processes * Tell me you have only one disk. Then this value would be nice. If not, set it to a minimum of one per active data disk. SHMBASE 0x200000000 # Shared memory base address * I'm not familiar with this paramater, but if your error log says to change it to 0x800000, then try it. SHMVIRTSIZE 8192 # initial virtual shared memory segmentsize SHMADD 8192 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited * You might want to learn about onstat -g ses and onstat -g mem, and ipcs and ipcrm (UNIX commands) and their relation to virtual memory management. It will guide you in setting these parameters correctly. 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 * If you're running an OLTP environment, set LRU_MAX_DIRTY to a value between 10 and 1 and LRU_MIN_DIRTY to a value between 5 and 0, knowing ofcourse that they cannot both be the same value, and that MAX and MIN means just that. This is influenced by checking if your message log says that checkpoints take more than a few seconds. LTXHWM 50 # Long transaction high water markpercentage LTXEHWM 60 # Long transaction high water mark (exclusive) @@N