RE: Buffer Waits Ratio
I am assuming that the stats given represent 30 days of activity.
If statistics have been reset since the engine was brought up,
that changes some things.
The formula uses page reads, because that is the number of pages
place into the buffer pool(I dont have that page in buffers go get it
from disk). Buffer reads would be the number of times the page was
read from the buffer pool(nothing is pulled from disk into the buffer pool)
This lets you calculate the
(times people waited on page)/(number of pages read from or written to disk)
I would just try to tune towards a better buffwait ratio
I know I have more than one system where we have
LRU queues with lengths around 1000. They seem
to perform well. As long os ovbuffs do not occur then
I can not think of any performance hit your system would have
due to the length of your LRU queues.
If you do start having ovbuffs that seems like a pretty big sign you
need longer LRU queues.
It seems like you could stand to have more LRU's, they are
probably a large part of the contention for buffers you are seeing.
It does not look like from the amount of activity you would
go through your buffers fast enough to replace items which
are being used constantly. I doubt more buffers would hurt though
I like the idea of increasing the number of CPU VP's.
I haven't had an oppurtunity to tune a system on a machine
near this size so do not know what kind of diminishing returns
one gets by adding CPU VP's.
Will
>===== Original Message From "Henderson, Scott" <SHenderson@purolator.com>
=====
>Friends,
>
>
>Informix Version: 7.30 FC7
>OS: HPUX 11.0
>Hardware: HP9000 Series 800 V2500
>Disk Array: EMC 3700
>Application: OLTP (strictly database server)
>Misc. 16 CPU, 8GB mem, 2 instances
>
>
>I've been making use of the bufwait ratio formula [ratio = (bufwaits /
>(pagreads + bufwrits)) * 100] on my production servers. During normal day
>to day usage it hovers at around 15%. I know the ideal target is 10%.
>During heavy activity in the afternoon I have seen measurements of >25%. I
>plan to increase BUFFERS,LRUS and CLEANERS and maybe NUMCPUVPS. I would
>appreciate if you guys/gals confirm my plan and also have a look at my
>onconfig file and recommend any improvements.
>
>Informix recommends 4 LRUS per NUMCPUVPS (Admin Guide Vol2 33-45)
>I have 6 CPUVPS, 28 LRUS (whoops) looking after 100000 BUFFERS, each LRU is
>looking after approximately 7000 pages.
>So, my questions are;
>
>1) Should I conform to the 4 LRUS/NUMCPUVPS?
>2) Is 7000 BUFFERS a high/low number of pages for each LRU, is there an
>optimized target?
>
>Also, could someone explain to me why the formula uses pagreads and not
>bufreads.
>
>
>
>
>
>#**************************************************************************
>#
># INFORMIX SOFTWARE, INC.
>#
># Title: onconfig.prod
># Description: Informix Dynamic Server Configuration Parameters
>#
>#**************************************************************************
>
># Root Dbspace Configuration
>
>ROOTNAME rootdbs # Root dbspace name
>ROOTPATH /dev/ifn_110001 # 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 1 # 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 49890 # Physical log file size (Kbytes)>
># Logical Log Configuration
>
>LOGFILES 100 # Number of logical log files
>LOGSIZE 5000 # Logical log size (Kbytes)>
># Diagnostics
>
>MSGPATH /home/informix/log/ccd.log # System message log
file
>path
>CONSOLE /dev/console # System consolemessage
>path
>ALARMPROGRAM /opt/informix_7.30/etc/no_log.sh # Alarm program path
>SYSALARMPROGRAM /opt/informix_7.30/etc/evidence.sh # System Alarm
>program path
>TBLSPACE_STATS 1>
># System Archive Tape Device
>
>#TAPEDEV /dev/null # Tape device path
>TAPEDEV /dev/rmt/c11t1d0BESTb # Tape device path
>#TAPEDEV /dev/rmt/c11t2d0BESTb # Tape device path
>TAPEBLK 64 # Tape block size (Kbytes)
>TAPESIZE 71303168 # Maximum amount of data to put on
>tape (Kbytes)>
># Log Archive Tape Device
>
>#LTAPEDEV /dev/null # Log tape device path
>LTAPEDEV /prod/informix/llogs/ccd/llog.today # Log tape
>device path
>LTAPEBLK 64 # Log tape block size (Kbytes)
>LTAPESIZE 2048000 # Max amount of data to put on log tape
>(Kbytes)>
># Optical
>
>STAGEBLOB # Informix Dynamic Server/Optical staging
>area
>
># System Configuration
>
>SERVERNUM 13 # Unique id corresponding to a Dynamic>Server instance
>DBSERVERNAME cortran0 # Name of default database server
>DBSERVERALIASES cortran1 # List of alternatedbservernames
>NETTYPE soctcp,1,100,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 6 # 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 400000 # Maximum number of locks
>BUFFERS 100000 # Maximum number of shared buffers
>NUMAIOVPS 24 # Number of IO vps
>PHYSBUFF 64 # Physical log buffer size (Kbytes)
>LOGBUFF 64 # Logical log buffer size
(Kbytes)>LOGSMAX 1024 # Maximum number of logical log files
>CLEANERS 24 # Number of buffer cleaner>processes
>SHMBASE 0x0 # Shared memory base address
>SHMVIRTSIZE 500000 # initial virtual shared memory segment size
>SHMADD 65536 # Size of new shared memory segments
>(Kbytes)
>SHMTOTAL 2000000 # Total shared memory (Kbytes). 0=>unlimited
>CKPTINTVL 180 # Check point interval (in sec)
>LRUS 28 # Number of LRU queues
>LRU_MAX_DIRTY 2