Re: Perfomance Tuning

Andy and Paul, You're both wrong in where to start with performance tuning. The first step must be to learn really well about IDS and how it works. The next step is to look at the system from ALL angles. Use every source of information you have available. This includes OS performance information as well as IDS and application(including query optimizer output). I always recommend that system administrators should be monitoring performance for some time before they can start performance tuning. Otherwise they have little idea of whether or not the changes have been successful, or whether the improvement they have made in one area has affected other areas. Ever had a car engine tuned for speed and lost consumption, or vice versa. As to the original question I have observed that IDS, in common with many other multi-user systems, does slow down over time, in particular as tables increase in size. I have also observed that a factor in this can be user familiarity with the system. I would start by looking at table sizes - have they grown more than anticipated. If they have does that affect decisions about indexing etc. And I would query excessive write activity as the checkpoints are taking longer. Temp table generation could be a cause but so could the speed of filling up log buffers. And it could even be some effect in the OS. Without information gathered before the current situation it is difficult to know what has changed. The original question said that checkpoints now take 10 seconds as opposed to 6 previously. But what about checkpoint frequency? Has that changed? If it is now 10 seconds every 5 minutes and it used to 6 seconds every 3 minutes is that a significant piece of info? regards Malcolm ----- Original Message ----- From: "Andy Kent" <andykent.bristol@virgin.net> To: <informix-list@iiug.org> Sent: Thursday, December 11, 2003 9:22 AM Subject: Re: Perfomance Tuning > If you follow that logic you'll end up tuning the box to support a > 1,000,000 row sequential scan that should have been achievable through > an index lookup. > > The reality is usually more complex and more grotesque than that > example. > > Probably the most authoritative and comprehensive performance tuning > book you can buy (sadly based on A.N. Other database) devotes about > 75% of its content to SQL, indexing and optimisation. > > Admittedly he's talking about checkpoints and therefore write > activity, but the principle's still the same - all those writes could > be caused by unnecessary temp table generation. > > Andy > > > Paul Watson <paul@oninit.com> wrote in message news:<3FD75250.9258A064@oninit.com>... > > I'd disagree, I always start at the Unix config and work back to > > the SQL. Highly tuned SQL with a poor engfine config on poorly setup > > server will always be slow. > > > > > > Andy Kent wrote: > > > > > > Always, ALWAYS start performance tuning by looking at the SQL and how > > > the optimiser is running it. > > > > > > Andy > > > > > > bnyaguwa@okzim.co.zw (Bonny) wrote in message news:<699af31f.0312100246.2b806c4@posting.google.com>... > > > > I have IDS 7.31 running on HP-UX 11.0 and 4 Gig of memory. > > > > > > > > I have a 40 Gig database with on average 260 users and at peak about > > > > 315 users. > > > > I want to tune my database , as it has shown signs of slowing down > > > > recently. > > > > Checkpoints are taking on average 10 seconds,under normal processing > > > > there should be 6 seconds. > > > > I have posted my onconfig file,onstat -p .What parameters should i > > > > consider for tuning both from the Informix side and Unix side. > > > > > > > > Onconfig > > > > > > > > #************************************************************************** > > > > # > > > > # INFORMIX SOFTWARE, INC. > > > > # > > > > # Title: onconfig.std > > > > # Description: Informix Dynamic Server Configuration Parameters > > > > # > > > > #************************************************************************** > > > > > > > > # Root Dbspace Configuration > > > > > > > > ROOTNAME rootdbs # Root dbspace name > > > > ROOTPATH /dev/rootdbs # Path for device containing root> > > > dbspace > > > > ROOTOFFSET 0 # Offset of root dbspace into device > > > > (Kbytes) > > > > ROOTSIZE 1000000 # Size of root dbspace (Kbytes)> > > > > > > > # Disk Mirroring Configuration Parameters > > > > > > > > MIRROR 0 # Mirroring flag (Yes = 1, No = 0) > > > > MIRRORPATH # Path for device containingmirrored > > > > root > > > > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> > > > > > > > # Physical Log Configuration > > > > > > > > PHYSDBS rootdbs # Location (dbspace) of physical log > > > > PHYSFILE 250000 # Physical log file size (Kbytes)> > > > > > > > # Logical Log Configuration > > > > > > > > LOGFILES 30 # Number of logical log files > > > > LOGSIZE 5000 # Logical log size (Kbytes)> > > > > > > > # Diagnostics > > > > > > > > MSGPATH /u/informix/online.log # System message log file path > > > > CONSOLE /dev/console # System console message path > > > > ALARMPROGRAM /u/informix/etc/log_full.sh # Alarm program path> > > > SYSALARMPROGRAM /u/informix/etc/evidence.sh # System Alarm program > > > > path > > > > TBLSPACE_STATS 0> > > > > > > > # System Archive Tape Device > > > > > > > > TAPEDEV /dev/rmt/c8t3d0BEST # Tape device path > > > > TAPEBLK 6144 # Tape block size (Kbytes) > > > > TAPESIZE 80000000 # Maximum amount of data to put on > > > > tape (Kbytes)> > > > > > > > # Log Archive Tape Device > > > > > > > > LTAPEDEV /dev/rmt/1m # Log tape device pat > > > > LTAPEBLK 1024 # Log tape block size (Kbytes) > > > > LTAPESIZE 4000000 # Max amount of data to put on log > > > > tape (Kbytes)> > > > > > > > # Optical > > > > > > > > STAGEBLOB # Informix Dynamic Server/Optical > > > > staging area > > > > > > > > # System Configuration > > > > > > > > SERVERNUM 1 # Unique id corresponding to aDynamic > > > > Server instance > > > > DBSERVERNAME ok_srvr # Name of default database server > > > > DBSERVERALIASES ok_tcp # List of alternate dbservernames > > > > NETTYPE ipcshm,1,500,CPU # Configure poll thread(s) for> > > > nettype > > > > NETTYPE soctcp,1,5,NET # Configure poll thread(s) fornettype > > > > DEADLOCK_TIMEOUT 60 # Max time to wait of lock in> > > > distributed env. > > > > RESIDENT -1 # 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