OnLine and Baan IV

Hi All, I have recently taken over administration of an HP-UX / Informix / Baan site. I am looking for any suggestions for ways to improve the general configuration / performance of the database. Briefly we have a K460 database server 3 processors, 3 Gb memory, 2 autoraid each with 12 * 9.1Gb. There are two instances of OnLine on the server. There are 6 client HP servers referencing the main database server. Baan IV runs on all servers and connects to the database server using its own proprietory database driver. Does anyone else out there use Baan IV and Online 7.22.UC3 I have attached the configuration info from one of the large instance, the other is set up similarly. The system is very badly fragmented currently as the default values for the extent sizes have been used !!! I will fix this over the next few decades! Thanks in advance Fergus INFORMIX-OnLine Version 7.22.UC3 -- On-Line -- Up 20:46:10 -- 850912 Kbytes Configuration File: /usr/informix/etc/bbrlgld1 #************************************************************************** # # INFORMIX SOFTWARE, INC. # # Title: onconfig.std # Description: INFORMIX-OnLine Configuration Parameters # #************************************************************************** # Root Dbspace Configuration ROOTNAME rootdbs # Root dbspace name ROOTPATH /dev/raw_links/baanroot0 # Path for device containing root dbspace ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) ROOTSIZE 200000 # Size of root dbspace (Kbytes) # Disk Mirroring Configuration Parameters MIRROR 0 # Mirroring flag (Yes = 1, No = 0) MIRRORPATH # Path for device containing mirrored root MIRROROFFSET 0 # Offset into mirrored device (Kbytes) # Physical Log Configuration PHYSDBS plogdbs # Location (dbspace) of physical log PHYSFILE 200000 # Physical log file size (Kbytes) # Logical Log Configuration LOGFILES 23 # Number of logical log files LOGSIZE 15000 # Logical log size (Kbytes) # Diagnostics MSGPATH /usr/informix/logs/online.log # System message log file path CONSOLE /dev/console # System console message path ALARMPROGRAM /usr/informix/etc/log_full.sh # Alarm program path # System Archive Tape Device TAPEDEV /dev/rmt/2m # Tape device path TAPEBLK 128 # Tape block size (Kbytes) TAPESIZE 20000000 # Maximum amount of data to put on tape (Kbytes) # Log Archive Tape Device LTAPEDEV /dev/rmt/0m # Log tape device path LTAPEBLK 128 # Log tape block size (Kbytes) LTAPESIZE 4000000 # Max amount of data to put on log tape (Kbytes) # Optical STAGEBLOB ,1 # INFORMIX-OnLine/Optical staging area # System Configuration SERVERNUM 0 # Unique id corresponding to a OnLineinstance DBSERVERNAME bbrlgld1 # Name of default database server DBSERVERALIASES # List of alternate dbservernames NETTYPE soctcp,1,300,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) MULTIPROCESSOR 1 # 0 for single-processor, 1 formulti-processor NUMCPUVPS 2 # Number of user (cpu) vps SINGLE_CPU_VP 0 # 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 200000 # Maximum number of locks BUFFERS 150000 # Maximum number of shared buffers NUMAIOVPS 6 # Number of IO vps PHYSBUFF 64 # Physical log buffer size (Kbytes) LOGBUFF 64 # Logical log buffer size (Kbytes)LOGSMAX 1000 # Maximum number of logical log files CLEANERS 6 # Number of buffer cleaner processes SHMBASE 0x0 # Shared memory base address SHMVIRTSIZE 500000 # 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 8 # Number of LRU queues LRU_MAX_DIRTY 2 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 1 # 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 /usr/informix/etc/dr.lostfound # DR lost+found file path # CDR Variables CDR_LOGBUFFERS 2048 # size of log reading buffer pool (Kbytes) CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional) CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds) CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue (Kbytes) # Backup/Restore variables BAR_ACT_LOG /usr/informix/logs/bar_act.log BAR_MAX_BACKUP 0 BAR_RETRY 0 BAR_NB_XPORT_COUNT 10 BAR_XFER_BUF_SIZE 31 # Read Ahead Variables RA_PAGES # Number of pages to attempt to read ahead RA_THRESHOLD # Number of pages left before next group # DBSPACETEMP: # OnLine equivalent of DBTEMP for SE. This is the list of dbspaces # that the OnLine SQL Engine will use to create temp tables etc. # If specified it must be a colon separated list of dbspaces that exist # when the OnLine system is brought online. If not specified, or if # all dbspac

From what I see, I would recommend the following (and ask the following questions of the system): First thing I would recommend right out of the blocks is to upgrade the database. For Baan, there has been the addition of connection multiplexing that helps out the fact that each user may make 6 session connections (onstat -g ses). From the $ONCONFIG file: If you backups seem to take a while, change the TAPEBLK to a higher number. Try 256, then 512 and see if that helps. DBSERVERALIASES and NETTYPE (and also the sqlhosts file): I do not see any local shared memory connection. Check with the $ONCONFIG/release release notes for your platform. It isn't that not having one is a problem, but that means everything locally done on the box is running thru the tcp/ip service (including backups). NUMCPUVPS: Since we have 3 CPUs, let's use the 3 CPUs. NOW, I don't know what else is running on the box, but since it looks like we are affinitizing the VPs, that is okay. NUMAIOVPS: Is KAIO on supported on HP.....Check this out from the release notes. SPECIAL NOTE: Make sure you have all the necessary HPUX patches from the HP website. I have the following: http://us-support.external.hp.com/ : which should get your the patches that may be necessary for KAIO. Once you get KAIO working, set this to 1. PHYSBUFF: I would increase the size of this to 128. It looks like it would help buffering of the physical log (onstat -l output). CKPTINTVL: How long are your checkpoints (onstat -m)?? If not too long, you can make this value higher...too say 600 or 1000. BUFFERS = 10% of system memory LOCKS = 50,000 (depending on user counts) LRU_MIN_DIRTY = 8 LRU_MAX_DIRTY = 12 SHMVIRTSIZE = 4MB * # users DD_HASHSIZE = 211 - Number of entries in the hash table DD_HASHMAX = 45 - Maximum length of one entry list Review each of these hash values with onstat -g dic Other thoughts about the environment (that you may or may not know): - You can fragment the large transactional tables - Do NOT detach indices - Run Update Statistics once a week - One database is created per company. Create each within their own dbspace - Results: Lots of tables and indices - Modify the ‘Next Extent’ for the system catalog to be LARGER - With so many tables and indices, the sysmaster is large Finally, are being a good DBA and running update stats in a timely and proper manner. There are some great tools on the www.iiug.org website for update stats running you may want to download. Tom Rieger Informix Software Irving, Texas Fergus Hayne wrote: > Hi All, > > I have recently taken over administration of an HP-UX / Informix / Baan > site. I am looking for any suggestions for ways to improve the general > configuration / performance of the database. > > Briefly we have a K460 database server 3 processors, 3 Gb memory, 2 autoraid > each with 12 * 9.1Gb. > There are two instances of OnLine on the server. There are 6 client HP > servers referencing the main database server. > > Baan IV runs on all servers and connects to the database server using its > own proprietory database driver. > > Does anyone else out there use Baan IV and Online 7.22.UC3 > > I have attached the configuration info from one of the large instance, the > other is set up similarly. > > The system is very badly fragmented currently as the default values for the > extent sizes have been used !!! > > I will fix this over the next few decades! > > Thanks in advance > Fergus > > INFORMIX-OnLine Version 7.22.UC3 -- On-Line -- Up 20:46:10 -- 850912 > Kbytes > > Configuration File: /usr/informix/etc/bbrlgld1 > #************************************************************************** > # > # INFORMIX SOFTWARE, INC. > # > # Title: onconfig.std > # Description: INFORMIX-OnLine Configuration Parameters > # > #************************************************************************** > > # Root Dbspace Configuration > > ROOTNAME rootdbs # Root dbspace name > ROOTPATH /dev/raw_links/baanroot0> # Path for device containing root dbspace > ROOTOFFSET 0 # Offset of root dbspace into device > (Kbytes) > ROOTSIZE 200000 # Size of root dbspace (Kbytes)> > # Disk Mirroring Configuration Parameters > > MIRROR 0 # Mirroring flag (Yes = 1, No = 0) > MIRRORPATH # Path for device containing mirrored root > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> > # Physical Log Configuration > > PHYSDBS plogdbs # Location (dbspace) of physical log > PHYSFILE 200000 # Physical log file size (Kbytes)> > # Logical Log Configuration > > LOGFILES 23 # Number of logical log files > LOGSIZE 15000 # Logical log size (Kbytes)> > # Diagnostics > > MSGPATH /usr/informix/logs/online.log # System message log file path > CONSOLE /dev/console # System console message path > ALARMPROGRAM /usr/informix/etc/log_full.sh # Alarm program path> > # System Archive Tape Device > > TAPEDEV /dev/rmt/2m # Tape device path > TAPEBLK 128 # Tape block size (Kbytes) > TAPESIZE 20000000 # Maximum amount of data to put on tape > (Kbytes)> > # Log Archive Tape Device > > LTAPEDEV /dev/rmt/0m # Log tape device path > LTAPEBLK 128 # Log tape block size (Kbytes) > LTAPESIZE 4000000 # Max amount of data to put on log tape > (Kbytes)> > # Optical > > STAGEBLOB ,1 # INFORMIX-OnLine/Optical staging area > > # System Configuration > > SERVERNUM 0 # Unique id corresponding to a OnLine> instance > DBSERVERNAME bbrlgld1 # Name of default database server > DBSERVERALIASES # List of alternate dbservernames > NETTYPE soctcp,1,300,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) > > 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 200000 # Maximum number of locks > BUFFERS 150000 # Maximum number of shared buffers > NUMAIOVPS 6 # Number of IO vps > PHYSBUFF 64 # Physical log buffer size (Kbytes) > LOGBUFF 64 # Logical log buffer size (Kbytes)> LOGSMAX 1000 # Maximum number of logical log fil

Here is what I have seen on a quick check: You do not use the NOAGE or AFF parameters, there are VERY important in an HP environment according to most HP users and Informix. RESIDENT 0 - residence MAY be important if you do not have enough memory and the resident segment is being swapped. The NETTYPE pararmeter specifies one CPU VP listener for the single TCP connection name. This will use FAR more system resources than having a NET VP listener for TCP operations and using only ONE of the CPU VPs means that if the second CPU VP is free but the first one is busy new requests have to wait unneccessarily. I recommend using CPU VP listeners ONLY for shared memory connections and then using ALL of the CPU VPs as listeners. I recommend using NET VPs for TCP listeners and you can configure as many or as few as you need to insure responsiveness. You have fewer CLEANERS than LRUS, CLEANERS s/b >= LRUS for best checkpoint performance. Your bufwaits ratio is good so you may not need more LRUS but 8 is very few, keep an eye on it. Your IO stats shows that kaio is enabled but all IO is being done by AIO VPs! This can only mean that all of those disk chunks in /dev/raw_links are links to COOKED, or block, devices. Just because you are using device files rather than filesystem files does not mean that you are using RAW I/O. The block devices ('b' in the first perms column of the "ls -l" listing) are COOKED devices for which all I/O goes through the buffer cache, it just avoids the FS drivers! Change the links to the equivalent RAW or character ('c' in the first perm column) devices, usually found in /dev/rdsk or starting or ending with an 'r' in its name, depending on the UNIX version to get true RAW I/O. If you continue to use COOKED devices or files increase the number of AIO VPS to 2x then number of chunks for a V7.22 engine. Otherwise 6 is plenty. I cannot tell but make sure that there is not more than one Virtual Segment (onstat -g seg) because an additional segment can cause the server and your apps to slow down because HP PA-RISC processors only have 4 dedicated registers for shared memory segment base addresses. Having more than 4 shared memory segments will cause the registers to thrash. (Actually since you do not use shared memory connections and do not have to attach a message segment you MAY be able to live with ONE additional virtual segment.) Fergus Hayne wrote: > > Hi All, > > I have recently taken over administration of an HP-UX / Informix / Baan > site. I am looking for any suggestions for ways to improve the general > configuration / performance of the database. > > Briefly we have a K460 database server 3 processors, 3 Gb memory, 2 autoraid > each with 12 * 9.1Gb. > There are two instances of OnLine on the server. There are 6 client HP > servers referencing the main database server. > > Baan IV runs on all servers and connects to the database server using its > own proprietory database driver. [SNIP] Art S. Kagel

At the 1998 IWUC, there was a presentation on tuning Informix for various ERP systems and specific recommendations were made for each, including Baan. If you can locate a copy of the proceedings, the information there may be of assistance. Doug Agnew Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.