Oninit cdi / Archive
Talk to an expert →

Re: Perfomance Tuning

Posted in 2003

Topics: Performance & Tuning, Storage & Space Management, Server Administration, Transactions, Locking & Isolation, Logging & Checkpoints, Networking & sqlhosts Configuration, Platform-Specific Issues, Versions, Editions & End-of-Life

Paul Watson — — source: Usenet: comp.databases.informix

No I'd end up with a box that had quick and well balanced IO, sufficient memory etc. Then I'd moved on the engine setup and finally the SQL. Bottom line, you need to start somewhere. Where you start is based on personal experience and the situation. Andy Kent wrote: > > 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 containing mirrored> > > > 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 a Dynamic> > > > 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) for nettype > > > > 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 # If non-zero, limit number of cpu vps> > > > to one > > > > > > > > NOAGE 1 # Process aging > > > > AFF_SPROC 0 # Affinity start processor > > > > AFF_NPROCS 0 # Affinity number of processors> > > > > > > > # Shared Memory Parameters > > > > > > > > LOCKS 400000 # Maximum number of locks > > > > BUFFERS 200000 # Maximum number of shared buffers > > > > NUMAIOVPS 8 # Number of IO vps > > > > PHYSBUFF 128 # Physical log buffer size (Kbytes) > > > > LOGBUFF 128 # Logical log buffer size (Kbytes)> > > > LOGSMAX 100 # Maximum number of logical log files > > > > CLEANERS 127 # Number of buffer cleaner processes > > > > SHMBASE 0x0 # Shared memory base address > > > > SHMVIRTSIZE 300000 # initial virtual shared memory> > > > segment size > > > > SHMADD 40000 # Size of new shared memory segments > > > > (Kbytes) > > > > SHMTOTAL 0 # Total shared memory (Kbytes). > > > > 0=>unlimited > > > > CKPTINTVL 360 # Check point interval (in sec) > > > > LRUS 127 # Number of LRU queues > > > > LRU_MAX_DIRTY 1 # LRU percent dirty begin cleaning> > > > limit > > > > LRU_MIN_DIRTY 0 # LRU percent dirty end cleaning limit > > > > LTXHWM 50 # Long transaction high water mark> > > > percentage > > > > LTXEHWM 60 # Long transaction high water mark > > > > (exclusive) > > > > TXTIMEOUT 0x12c # Tran

↪ replying to Paul Watson
Obnoxio The Clown — — source: Usenet: comp.databases.informix

Paul Watson wrote: > No I'd end up with a box that had quick and well balanced IO, > sufficient memory etc. Then I'd moved on the engine setup and > finally the SQL. I'd side with Andy on this one. Sorry, Andy. :o) > Andy Kent wrote: >> >> 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. -- "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche

Related threads

Glossary