Re: Baan on Informix 7.23 UC6

Tony Cullen wrote: > > Please ignore my last posting as I sent it as an attachment. I then noticed > that noone > else does this so here it comes without the attachment. Hi Tony, long time no-see. That is the preferred method, and in pure ASCII. > Hope someone can help here. We migrated from running BAAN IVc0 on tbase to > running it on > Informix version 7.23 UC6 over the weekend. Our porting set is 6.1c.04.01 > and we are > running on an AIX model F40 2 processor 166Mhz under AIX version 4.3. Since > the migration > our througput has gone out by a factor of 3-4 i.e jobs that took 10mins now > run for 30-40 mins. When you migrate from TBase to Informix, or any other relational DB, you can expect an overall drop in performance. I expect your sales person 'forgot' to mention that. Did his name sound like Fraud? ;-) Are you running in host mode, or is this just a DB server? > Can you check the stats below and if you need any other stats let me > know and I can > supply them. These were taken using the level 1 driver supplied by Baan but > I believe that > there is a level 2 driver for Informix on Baan which could improve matters. No, not for this Version I believe. That was just a myth propagated by Sales types to bolster your anticipation of better things to come. :-) > Has anyone > had any experience with it. For the meantime I would appreciate it if you > could give me > some pointers regarding the config to see if we can fix the existing setup. Before I look at the config, two things: 1) Do you have any customisations? So far, out of the Baan sites I have visited with performance problems, 100% of them have customisations. Changing the custom code, or simply adding an index has sorted about 95% of them. 2) Have you specifically spread your Baan tables over as many spindles as possible. If the answer is; "I'm not sure, Baan did that...", then the answer is NO! Keeping your IO spread as much as possible is your number one tuning ability with Baan / Informix. You might as well start there before you look at any other suggestions made about your config parameters. Changing your config will be fine tuning only. > Thankyou in anticipation Don't hold your breath Tony. You may get some improvement, but it will never be as quick as TBase. Using an RDBMS with Baan is a decision you make to safeguard your business, not speed things up. > THE STATS WHERE ZEROISED AT 10am and these readings were taken at 8:30 pm > so they relect a days work. > > ROOTPATH /dev/Iinfrootdbs # Path for device containing root dbspace I don't know if this IS a link, but it is a good idea to use links to chunk devices. > ROOTOFFSET 0 # Offset of root dbspace into device > (Kbytes) > ROOTSIZE 240000 # Size of root dbspace (Kbytes) Unbelievably large, unless you have left your physical log in there. Tell me there are no logical logs in there. ;-) > PHYSDBS phydbs # Location (dbspace) of physical log > PHYSFILE 270000 # Physical log file size (Kbytes) So it's not in the root dbspace. > # Logical Log Configuration > > LOGFILES 19 # Number of logical log files > LOGSIZE 10000 # Logical log size (Kbytes) Depending on the number of users, this does not look to be enough. I always start with 60 x 10Mb for Baan. > DBSERVERNAME baan_str # Name of default database server Stream pipes would suggest host mode. > DBSERVERALIASES baan_shm # List of alternate dbservernames I hope you are not using this for Baan connections. Maybe the odd dbaccess? You could remove this and use stream pipes for dbaccess as well. > NETTYPE ipcstr,1,100,CPU # Configure poll thread(s) for nettype > NETTYPE ipcshm,1,100,CPU # Configure poll thread(s) for nettype > NETTYPE sqlmux,1,100,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 If you are using host mode, then these parameters are probably killing the bshell performance. You only have 2 CPUs in the box? The bshells need at least one of those. Again, it depends on the number of users. But I would suggest using 1 CPU for IDS. This is how your NETTYPE is configured as well with one poll thread. > BUFFERS 40000 # Maximum number of shared buffers This does not seem to be very large. Remember that it is difficult to monitor memory on these boxes. It all gets 'allocated', but not actually used. You need to use all the memory you can after the bshells are running. > NUMAIOVPS 2 # Number of IO vps Make sure you are using raw disk with kernel AIO. If not, then switch on kernel AIO, or allocate 2 AIO VPs to every chunk. > PHYSBUFF 32 # Physical log buffer size (Kbytes) > LOGBUFF 32 # Logical log buffer size (Kbytes) Based on your onstat -l these need to go up. > SHMVIRTSIZE 160000 # initial virtual shared memory segment size > SHMADD 50000 # Size of new shared memory segments These might be a bit large if you don't have many users. > CLEANERS 7 # Number of buffer cleaner processes > LRUS 7 # Number of LRU queues Check onstat -g spi for LRU contention. If you have some, then you should increase LRUS and CLEANERS. > LRU_MAX_DIRTY 12 # LRU percent dirty begin cleaning limit > LRU_MIN_DIRTY 8 # LRU percent dirty end cleaning limit If your checkpoint duration is high, then lower these values. This can hit transaction processing. > # Read Ahead Variables > RA_PAGES 10 # Number of pages to attempt to read ahead > RA_THRESHOLD 5 # Number of pages left before next group These are strange values. 10 & 8 would be more like it. However, Baan cannot make much use of read ahead, so you may find less buffer contention by lowering or switching off these values. > DBSPACETEMP tmpdbs1,tmpdbs2 #temp dbspaces There is really little benefit in having more than one temp dbspace with Baan, because it doesn't use it much. However, if you have the spare disk, it won't hurt. > # Parallel Database Queries (pdq) > MAX_PDQPRIORITY 200 # Maximum allowed pdqpriority This is a percentage, and should therefore be between 0 and 100. Although Baan can make little use of PDQ, as with most other engine features. :-( > DD_HASHSIZE 20 > DD_HASHMAX 511 These are the wrong way round. DD_HASHSIZE should be the prime number, and a lot larger than DD_HASHMAX. Make sure these are large enough. Remember that every time you create