Question about IDS scalabiltiy

What does ( how many processors ) can Informix ( IDS 7.3 ) scale to for optimum processing......

NUMCPUVPS = (physical CPUs) - 1 Informix can utilize any number of CPUs that have been defined within the ONCONFIG file. John Carlson Informix DBA WHSmith USA Carlos Bolden wrote: > > What does ( how many processors ) can Informix ( IDS 7.3 ) scale to for > optimum processing......

OK....now that's obvious : - ) Here is the problem I am running into: We have a system ( NCR WorldMark 5100s -- 32 p166 - 2 gig of ram 800 or so dedicated to informix ( RESIDENT=1) using KAIO, raid 5 about 200 or so gigabytes dedicated to the database, while this is not optimal it is there for safety purposes, IDS 7.3UC8 ). We cannot make it do work. We have changed this, that and the other. We have tuned for this, ran for that and have had not much success. It seems like somthing is holding it back ( or as the bossman would say, the magic smoke is gone ) Has anyone ever seen anything like this. I know this is a vague description but it just won't do any real work. WE have 300 or so process attached to the database to do work, each one of theses processes open up about 10 to 30 cursors. We use TopEnd from BEA and a transaction server for this system. If you would like more info: mailto:cbolden@harrahs.com Work Carlos Bolden Carlson@WHSmith <carlson1@bellsouth.net> wrote in message news:374B0798.97252A0E@bellsouth.net... > NUMCPUVPS = (physical CPUs) - 1> > Informix can utilize any number of CPUs that have been defined within > the ONCONFIG file. > > > John Carlson > Informix DBA > WHSmith USA > > > Carlos Bolden wrote: > > > > What does ( how many processors ) can Informix ( IDS 7.3 ) scale to for > > optimum processing......

Carlos Bolden wrote: > > What does ( how many processors ) can Informix ( IDS 7.3 ) scale to for > optimum processing...... I've run with as many as 28 CPU VPs on a 32 CPU system with 140 AIO VPs and 20 NET VPs and we were still running our application servers on the same box! IDS just keeps on scaling and scaling and scaling...... Art S. Kagel

Carlos Bolden wrote: > > OK....now that's obvious > : - ) > > Here is the problem I am running into: AHH! Now we get to the real question! For everyone's edification, and especially anyone new to the group: It is almost always more productive to post your problem, with as much information as is reasonable (ie don't post onstat -a output unless someone asks for it but if relevant a particular onstat report and your versions, platform, and onconfig file usually help) RATHER than to post a question or propose a solution and ask our opinions on it in a vacuum. In this case I answered the original question assuming Carlos was planning a new machine and was wondering if he could take good advantage of the new Quagmire E9999 with 4,000 600MHZ Pentium IV CPUs and here he really has a serious performance problem. Lecture over on to the problem. > We have a system > ( NCR WorldMark 5100s -- 32 p166 - 2 gig of ram 800 or so dedicated to > informix ( RESIDENT=1) using KAIO, raid 5 about 200 or so gigabytes > dedicated to the database, while this is not optimal it is there for safety > purposes, IDS 7.3UC8 ). We cannot make it do work. We have changed this, > that and the other. We have tuned for this, ran for that and have had not > much success. It seems like somthing is holding it back ( or as the bossman > would say, the magic smoke is gone ) > > Has anyone ever seen anything like this. I know this is a vague description > but it just won't do any real work. WE have 300 or so process attached to > the database to do work, each one of theses processes open up about 10 to 30 > cursors. We use TopEnd from BEA and a transaction server for this system. There can be many reasons for the problem, some of which are: o NCR requires several patches and optional packages for KAIO to work properly. You may not have applied all of these. Reread the release notes and get the white paper on installing IDS on NCR that NCR has put out. o The database has concurrency problems like page mode locking on tables. o The application is poorly designed to limit concurrency and/or is single threading updates/inserts. This can happen in interactive programs that lock a row while it is being modified online by a user interactively. Similarly if a separate serial number table is used to simulate Oracle-like sequences and the sequence record is kept locked while a multi-table transaction is saved and committed rather than making that a separate singleton transaction. This alone will single thread inserts. On the engine side: o Physical log is too small and is causing checkpoints to happen so frequently that no real work can get done. o The checkpoint interval is too short. o The checkpoint duration is too long. o Logical and physical logs are on the same drives as the database tables on a very busy transaction system. o All of your HOT tables reside on the same drive(s). o Your SMP system is Numa architecture and you are not affining your VPs or your applications (don't remember NCR well enough). o Your table statistics and data distributions are sorely out of date or missing. (Have you updated stats according to the recommendations in the release notes and performance guide, or run my dostats.ec utility which does this for you? Recently?) So how to determine what is the problem and how to fix. Post the following: ONCONFIG file onstat -R (preferably shortly before an expected checkpoint) onstat -F (at least 1/2 day after the last startup or onstat -z) onstat -l (again shortly before an expected checkpoint) onstat -p (same as for -F need 1/2 days stats here) onstat -g seg onstat -k (just the first 20 and last few lines) onstat -g iov (same as for -F need 1/2 days stats here) onstat -g iof (same as for -F need 1/2 days stats here) Perhaps someone will spot the problem in something obvious. If not you will just have to play detective and poke and prod and see what jumps out of the shadows. In any event we need more info to help. Art S. Kagel