read and write cache percentages
Vic asked whether a 67% write-cache ratio (vs 97% read) was acceptable on Informix 7.2/HP-UX with ~240 users. Advice: the ratio depends on read/write mix; check ovbuff in onstat -p and add BUFFERS. After he posted his ONCONFIG and onstat output, Art Kagel diagnosed too few buffers (24,000 — suggested starting at 100,000), too few LRU queues (set LRUS to 127, avoiding 64/96 and 128), NOAGE enabled on HP-UX, and lower LRU_MAX_DIRTY (2-10)/LRU_MIN_DIRTY (0-5) to shorten long checkpoints. He also gave his undocumented bufwait ratio formula: bufwaits/(pagreads+bufwrits)*100, which should stay under 7% on 7.x (Vic's was ~25%). No follow-up confirming results is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
We are running 7.2 on hp 9000 with approx 240 users. I noticed the write cache percentage was 67%, the read cache percentage was 97%. Is the 67% ok. Are there any paramenters we should be looking at to increase this write cache percentage or is 67% an acceptable level? Thanks Vic Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.
In article <7mrhba$pd7$1@nnrp1.deja.com>,
Vic Newman <klball@my-deja.com> wrote:
> We are running 7.2 on hp 9000 with approx 240 users. I noticed the
> write cache percentage was 67%, the read cache percentage was 97%. Is
> the 67% ok. Are there any paramenters we should be looking at to
> increase this write cache percentage or is 67% an acceptable level?
Generally speaking 67% is too low. But this number depends on the type
of activities, performed in your system. For example, if you have 100 K
reads with cache ratio 98% and 1 K writes with cache ratio 70 % - I
think it's OK. But if balance between reads and writes is about 50/50 -
you need tuning. So, it's your choice is it OK, or not.
First step to increase cache ratio is to add more BUFFERS. Check column
ovbuff in "onstat -p" output - if there is some number there, you
certainly need to add some buffers. Other steps, such as tuning LRU
queues and flushing params are dependent on the system profile. To help
you in this tuning, we need your "onstat -a" and ONCONFIG file.
--
With best regards, Yuri Dovgart,
SAP R/3, Informix consultant,
"Telecominvest" company.
E-mail y_dovgart@tci.ukrtel.net
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
In article <7muke7$lt8$1@nnrp1.deja.com>,
Yuri Dovgart <y_dovgart@tci.ukrtel.net> wrote:
> In article <7mrhba$pd7$1@nnrp1.deja.com>,
> Vic Newman <klball@my-deja.com> wrote:
> > We are running 7.2 on hp 9000 with approx 240 users. I noticed
the
> > write cache percentage was 67%, the read cache percentage was 97%.
Is
> > the 67% ok. Are there any paramenters we should be looking at to
> > increase this write cache percentage or is 67% an acceptable level?
>
> Generally speaking 67% is too low. But this number depends on the type
> of activities, performed in your system. For example, if you have 100
K
> reads with cache ratio 98% and 1 K writes with cache ratio 70 % - I
> think it's OK. But if balance between reads and writes is about 50/50
-
> you need tuning. So, it's your choice is it OK, or not.
>
> First step to increase cache ratio is to add more BUFFERS. Check
column
> ovbuff in "onstat -p" output - if there is some number there, you
> certainly need to add some buffers. Other steps, such as tuning LRU
> queues and flushing params are dependent on the system profile. To
help
> you in this tuning, we need your "onstat -a" and ONCONFIG file.
>
> --
> With best regards, Yuri Dovgart,
> SAP R/3, Informix consultant,
> "Telecominvest" company.
> E-mail y_dovgart@tci.ukrtel.net
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
The ovbuff in onstat -p is 0. The output from ostat -a is quite lengthy
and I did not want to post the entire output because of that. Is there
a specific part of in that is helpful?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Post your ONCONFIG file, onstat -R, onstat -p, onstat -F, onstat -m,
onstat -l outputs and we'll look it over.
Art S. Kagel
Vic Newman wrote:
>
> In article <7muke7$lt8$1@nnrp1.deja.com>,
> Yuri Dovgart <y_dovgart@tci.ukrtel.net> wrote:
> > In article <7mrhba$pd7$1@nnrp1.deja.com>,
> > Vic Newman <klball@my-deja.com> wrote:
> > > We are running 7.2 on hp 9000 with approx 240 users. I noticed
> the
> > > write cache percentage was 67%, the read cache percentage was 97%.
> Is
> > > the 67% ok. Are there any paramenters we should be looking at to
> > > increase this write cache percentage or is 67% an acceptable level?
> >
> > Generally speaking 67% is too low. But this number depends on the type
> > of activities, performed in your system. For example, if you have 100
> K
> > reads with cache ratio 98% and 1 K writes with cache ratio 70 % - I
> > think it's OK. But if balance between reads and writes is about 50/50
> -
> > you need tuning. So, it's your choice is it OK, or not.
> >
> > First step to increase cache ratio is to add more BUFFERS. Check
> column
> > ovbuff in "onstat -p" output - if there is some number there, you
> > certainly need to add some buffers. Other steps, such as tuning LRU
> > queues and flushing params are dependent on the system profile. To
> help
> > you in this tuning, we need your "onstat -a" and ONCONFIG file.
> >
> > --
> > With best regards, Yuri Dovgart,
> > SAP R/3, Informix consultant,
> > "Telecominvest" company.
> > E-mail y_dovgart@tci.ukrtel.net
> >
> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.
> >
>
> The ovbuff in onstat -p is 0. The output from ostat -a is quite lengthy
> and I did not want to post the entire output because of that. Is there
> a specific part of in that is helpful?
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
In article <379345E3.E314EBB4@bloomberg.net>,
kagel@bloomberg.net wrote:
> Post your ONCONFIG file, onstat -R, onstat -p, onstat -F, onstat -m,
> onstat -l outputs and we'll look it over.>
> Art S. Kagel
>
> Vic Newman wrote:
> >
> > In article <7muke7$lt8$1@nnrp1.deja.com>,
> > Yuri Dovgart <y_dovgart@tci.ukrtel.net> wrote:
> > > In article <7mrhba$pd7$1@nnrp1.deja.com>,
> > > Vic Newman <klball@my-deja.com> wrote:
> > > > We are running 7.2 on hp 9000 with approx 240 users. I
noticed
> > the
> > > > write cache percentage was 67%, the read cache percentage was
97%.
> > Is
> > > > the 67% ok. Are there any paramenters we should be looking at
to
> > > > increase this write cache percentage or is 67% an acceptable
level?
> > >
> > > Generally speaking 67% is too low. But this number depends on the
type
> > > of activities, performed in your system. For example, if you have
100
> > K
> > > reads with cache ratio 98% and 1 K writes with cache ratio 70 % -
I
> > > think it's OK. But if balance between reads and writes is about
50/50
> > -
> > > you need tuning. So, it's your choice is it OK, or not.
> > >
> > > First step to increase cache ratio is to add more BUFFERS. Check
> > column
> > > ovbuff in "onstat -p" output - if there is some number there, you
> > > certainly need to add some buffers. Other steps, such as tuning
LRU
> > > queues and flushing params are dependent on the system profile. To
> > help
> > > you in this tuning, we need your "onstat -a" and ONCONFIG file.
> > >
> > > --
> > > With best regards, Yuri Dovgart,
> > > SAP R/3, Informix consultant,
> > > "Telecominvest" company.
> > > E-mail y_dovgart@tci.ukrtel.net
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Share what you know. Learn what you don't.
> > >
> >
> > The ovbuff in onstat -p is 0. The output from ostat -a is quite
lengthy
> > and I did not want to post the entire output because of that. Is
there
> > a specific part of in that is helpful?
> >
> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.
>
Listed below are the onconfig and onstat R, p, f, m and l.
Thanks for your input.
Vic
#***********************************************************************
***
#
# INFORMIX SOFTWARE, INC.
#
# Title: onconfig.sales_prod
# Description: INFORMIX-OnLine Configuration Parameters
#
#***********************************************************************
***
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace nameROOTPATH /dev/AR1LUN4/rlv0 # Path for device containing root
dbspace
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)
ROOTSIZE 100000 # Size of root dbspace (Kbytes)
# Disk Mirroring Configuration Parameters
MIRROR 1 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirroredroot
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHYSDBS rootdbs # Location (dbspace) of physical log
PHYSFILE 40000 # Physical log file size (Kbytes)
# Logical Log Configuration
LOGFILES 40 # Number of logical log files
LOGSIZE 1000 # Logical log size (Kbytes)
# Diagnostics
MSGPATH /var/informix/sales_prod.log # System message log file
path
CONSOLE /var/informix/sales_prod.con # System console message
path
ALARMPROGRAM /usr/informix/etc/autolog.sales # Alarm program path
# System Archive Tape Device
#TAPEDEV /dev/null # Tape device path
TAPEDEV /dev/rmt/0m # Tape device path
TAPEBLK 64 # Tape block size (Kbytes)
TAPESIZE 2000000 # Maximum amount of data to put on tape
(Kbytes)
# Log Archive Tape Device
LTAPEDEV /dev/null # Log tape device path
#LTAPEDEV /dev/rmt/0m # Log tape device path
LTAPEBLK 64 # Log tape block size (Kbytes)
LTAPESIZE 2000000 # Max amount of data to put on log tape
(Kbytes)
# Optical
STAGEBLOB # INFORMIX-OnLine/Optical staging area
# System Configuration
SERVERNUM 4 # Unique id corresponding to a OnLineinstance
DBSERVERNAME sales_prod # Name of default database serverDBSERVERALIASES salse_net_prod # List of alternate dbservernames
NETTYPE ipcshm,3,400,CPU # Configure poll thread(s) for nettype
NETTYPE soctcp,1,200,NET # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 60 # Max time to wait of lock indistributed env.
RESIDENT 0 # Forced residency flag (Yes = 1, No =
0)
MULTIPROCESSOR 1 # 0 for single-processor, 1 formulti-processor
NUMCPUVPS 3 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vpsto one
NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
# Shared Memory Parameters
LOCKS 500000 # Maximum number of locks
BUFFERS 24000 # Maximum number of shared buffers
NUMAIOVPS 4 # Number of IO vps
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 256 # Maximum number of logical log files
CLEANERS 4 # Number of buffer cleaner processes
SHMBASE 0x0 # Shared memory base address
SHMVIRTSIZE 24000 # initial virtual shared memory segmentsize
SHMADD 8192 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
CKPTINTVL 180 # Check point interval (in sec)
LRUS 8 # Number of LRU queues
LRU_MAX_DIRTY 50 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 40 # LRU percent dirty end cleaning limit
LTXHWM 50 # Long transaction high water markpercentage
LTXEHWM 60 # Long transaction high water mark
(exclusive)
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 32 # Stack size (Kbytes)
# System Page Size
# BUFFSIZE - OnLine no longer supports this configuration parameter.
# To determine the page size used by OnLine on your platform
# see the last line of output from the command, 'onstat -b'.
# Recovery Variables
# OFF_RECVRY_THREADS:
# Number of parallel worker threads during fast recovery or an offline
restore.
# ON_RECVRY_THREADS:
# Number of parallel worker threads during an online restore.@@N
Everything looks fine except you definitely need many more buffers.
I'd start with 100,000 and work from there. Also with 240 users you
can need more than 16 LRUS which is verified by your enormous bufwaits
ratio of 25%, it should be below 7%. Go for broke and configure 127
LRUs (128 triggers a harmless but annoying error message at startup).
Also I see you are runing on HP. HPUX is aggressive about aging long
running processes. You should have NOAGE set it your 7.22 supports it,
check the release notes for support and possible patches. Also I
notice very long checkpoints which will only get worse with more
buffers. Reset LRU_MAX_DIRTY to a value between 2 and 10 and
LRU_MIN_DIRTY to a value between 0 and 5 and adjust to reduce
checkpoint duration to an acceptable level.
Just NOAGE and increasing LRUs and buffers and you will see a
significant improvement and reduced system impact from the bufwait
spins.
Art S. Kagel
Vic Newman wrote:
>
> In article <379345E3.E314EBB4@bloomberg.net>,
> kagel@bloomberg.net wrote:
> > Post your ONCONFIG file, onstat -R, onstat -p, onstat -F, onstat -m,
> > onstat -l outputs and we'll look it over.> >
> > Art S. Kagel
> >
> > Vic Newman wrote:
> > >
> > > In article <7muke7$lt8$1@nnrp1.deja.com>,
> > > Yuri Dovgart <y_dovgart@tci.ukrtel.net> wrote:
> > > > In article <7mrhba$pd7$1@nnrp1.deja.com>,
> > > > Vic Newman <klball@my-deja.com> wrote:
> > > > > We are running 7.2 on hp 9000 with approx 240 users. I
> noticed
> > > the
> > > > > write cache percentage was 67%, the read cache percentage was
> 97%.
> > > Is
> > > > > the 67% ok. Are there any paramenters we should be looking at
> to
> > > > > increase this write cache percentage or is 67% an acceptable
> level?
> > > >
> > > > Generally speaking 67% is too low. But this number depends on the
> type
> > > > of activities, performed in your system. For example, if you have
> 100
> > > K
> > > > reads with cache ratio 98% and 1 K writes with cache ratio 70 % -
> I
> > > > think it's OK. But if balance between reads and writes is about
> 50/50
> > > -
> > > > you need tuning. So, it's your choice is it OK, or not.
> > > >
> > > > First step to increase cache ratio is to add more BUFFERS. Check
> > > column
> > > > ovbuff in "onstat -p" output - if there is some number there, you
> > > > certainly need to add some buffers. Other steps, such as tuning
> LRU
> > > > queues and flushing params are dependent on the system profile. To
> > > help
> > > > you in this tuning, we need your "onstat -a" and ONCONFIG file.
> > > >
> > > > --
> > > > With best regards, Yuri Dovgart,
> > > > SAP R/3, Informix consultant,
> > > > "Telecominvest" company.
> > > > E-mail y_dovgart@tci.ukrtel.net
> > > >
> > > > Sent via Deja.com http://www.deja.com/
> > > > Share what you know. Learn what you don't.
> > > >
> > >
> > > The ovbuff in onstat -p is 0. The output from ostat -a is quite
> lengthy
> > > and I did not want to post the entire output because of that. Is
> there
> > > a specific part of in that is helpful?
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Share what you know. Learn what you don't.
> >
>
> Listed below are the onconfig and onstat R, p, f, m and l.
> Thanks for your input.
>
> Vic
>
> #***********************************************************************
> ***
> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: onconfig.sales_prod
> # Description: INFORMIX-OnLine Configuration Parameters
> #
> #***********************************************************************
> ***
>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name> ROOTPATH /dev/AR1LUN4/rlv0 # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 100000 # 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 rootdbs # Location (dbspace) of physical log
> PHYSFILE 40000 # Physical log file size (Kbytes)>
> # Logical Log Configuration
>
> LOGFILES 40 # Number of logical log files
> LOGSIZE 1000 # Logical log size (Kbytes)>
> # Diagnostics
>
> MSGPATH /var/informix/sales_prod.log # System message log file
> path
> CONSOLE /var/informix/sales_prod.con # System console message
> path
> ALARMPROGRAM /usr/informix/etc/autolog.sales # Alarm program path
>
> # System Archive Tape Device
>
> #TAPEDEV /dev/null # Tape device path
> TAPEDEV /dev/rmt/0m # Tape device path
> TAPEBLK 64 # Tape block size (Kbytes)
> TAPESIZE 2000000 # Maximum amount of data to put on tape
> (Kbytes)>
> # Log Archive Tape Device
>
> LTAPEDEV /dev/null # Log tape device path
> #LTAPEDEV /dev/rmt/0m # Log tape device path
> LTAPEBLK 64 # Log tape block size (Kbytes)
> LTAPESIZE 2000000 # Max amount of data to put on log tape
> (Kbytes)>
> # Optical
>
> STAGEBLOB # INFORMIX-OnLine/Optical staging area
>
> # System Configuration
>
> SERVERNUM 4 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME sales_prod # Name of default database server> DBSERVERALIASES salse_net_prod # List of alternate dbservernames
> NETTYPE ipcshm,3,400,CPU # Configure poll thread(s) for nettype
> NETTYPE soctcp,1,200,NET # 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 3 # 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 500000 # Maximum number of locks
> BUFFERS 24000 # Maximum number of shared buffers
> NUMAIOVPS 4 # Number of IO vps
> PHYSBUFF 32 # Physical log buffer size (Kbytes)
> LOGBUFF 32 # Logical log buffer size (Kbytes)> LOGSMAX 256 # Maximum number of logical log files
> CLEANERS 4 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shar
Art,
Thanks for the valuable info. One final question. How did you
calculate the 25% buffer wait. I must justify my parameter changes and
I do not know how to calculate the bufwaits ratio, but I am learning
more everyday.
Thanks again,
Vic
In article <37939B9B.F60EE702@bloomberg.net>,
kagel@bloomberg.net wrote:
> Everything looks fine except you definitely need many more buffers.
> I'd start with 100,000 and work from there. Also with 240 users you
> can need more than 16 LRUS which is verified by your enormous
bufwaits
> ratio of 25%, it should be below 7%. Go for broke and configure 127
> LRUs (128 triggers a harmless but annoying error message at
startup).
> Also I see you are runing on HP. HPUX is aggressive about aging long
> running processes. You should have NOAGE set it your 7.22 supports
it,
> check the release notes for support and possible patches. Also I
> notice very long checkpoints which will only get worse with more
> buffers. Reset LRU_MAX_DIRTY to a value between 2 and 10 and
> LRU_MIN_DIRTY to a value between 0 and 5 and adjust to reduce
> checkpoint duration to an acceptable level.
>
> Just NOAGE and increasing LRUs and buffers and you will see a
> significant improvement and reduced system impact from the bufwait
> spins.
>
> Art S. Kagel
>
> Vic Newman wrote:
> >
> > In article <379345E3.E314EBB4@bloomberg.net>,
> > kagel@bloomberg.net wrote:
> > > Post your ONCONFIG file, onstat -R, onstat -p, onstat -F, onstat -
m,
> > > onstat -l outputs and we'll look it over.> > >
> > > Art S. Kagel
> > >
> > > Vic Newman wrote:
> > > >
> > > > In article <7muke7$lt8$1@nnrp1.deja.com>,
> > > > Yuri Dovgart <y_dovgart@tci.ukrtel.net> wrote:
> > > > > In article <7mrhba$pd7$1@nnrp1.deja.com>,
> > > > > Vic Newman <klball@my-deja.com> wrote:
> > > > > > We are running 7.2 on hp 9000 with approx 240 users. I
> > noticed
> > > > the
> > > > > > write cache percentage was 67%, the read cache percentage
was
> > 97%.
> > > > Is
> > > > > > the 67% ok. Are there any paramenters we should be looking
at
> > to
> > > > > > increase this write cache percentage or is 67% an acceptable
> > level?
> > > > >
> > > > > Generally speaking 67% is too low. But this number depends on
the
> > type
> > > > > of activities, performed in your system. For example, if you
have
> > 100
> > > > K
> > > > > reads with cache ratio 98% and 1 K writes with cache ratio 70
% -
> > I
> > > > > think it's OK. But if balance between reads and writes is
about
> > 50/50
> > > > -
> > > > > you need tuning. So, it's your choice is it OK, or not.
> > > > >
> > > > > First step to increase cache ratio is to add more BUFFERS.
Check
> > > > column
> > > > > ovbuff in "onstat -p" output - if there is some number there,
you
> > > > > certainly need to add some buffers. Other steps, such as
tuning
> > LRU
> > > > > queues and flushing params are dependent on the system
profile. To
> > > > help
> > > > > you in this tuning, we need your "onstat -a" and ONCONFIG
file.
> > > > >
> > > > > --
> > > > > With best regards, Yuri Dovgart,
> > > > > SAP R/3, Informix consultant,
> > > > > "Telecominvest" company.
> > > > > E-mail y_dovgart@tci.ukrtel.net
> > > > >
> > > > > Sent via Deja.com http://www.deja.com/
> > > > > Share what you know. Learn what you don't.
> > > > >
> > > >
> > > > The ovbuff in onstat -p is 0. The output from ostat -a is quite
> > lengthy
> > > > and I did not want to post the entire output because of that.
Is
> > there
> > > > a specific part of in that is helpful?
> > > >
> > > > Sent via Deja.com http://www.deja.com/
> > > > Share what you know. Learn what you don't.
> > >
> >
> > Listed below are the onconfig and onstat R, p, f, m and l.
> > Thanks for your input.
> >
> > Vic
> >
> >
#***********************************************************************
> > ***
> > #
> > # INFORMIX SOFTWARE, INC.
> > #
> > # Title: onconfig.sales_prod
> > # Description: INFORMIX-OnLine Configuration Parameters
> > #
> >
#***********************************************************************
> > ***
> >
> > # Root Dbspace Configuration
> >
> > ROOTNAME rootdbs # Root dbspace name> > ROOTPATH /dev/AR1LUN4/rlv0 # Path for device containing root
> > dbspace
> > ROOTOFFSET 0 # Offset of root dbspace into device
> > (Kbytes)
> > ROOTSIZE 100000 # Size of root dbspace (Kbytes)> >
> > # Disk Mirroring Configuration Parameters
> >
> > MIRROR 1 # 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 40000 # Physical log file size (Kbytes)> >
> > # Logical Log Configuration
> >
> > LOGFILES 40 # Number of logical log files
> > LOGSIZE 1000 # Logical log size (Kbytes)> >
> > # Diagnostics
> >
> > MSGPATH /var/informix/sales_prod.log # System message log
file
> > path
> > CONSOLE /var/informix/sales_prod.con # System console
message
> > path
> > ALARMPROGRAM /usr/informix/etc/autolog.sales # Alarm program path
> >
> > # System Archive Tape Device
> >
> > #TAPEDEV /dev/null # Tape device path
> > TAPEDEV /dev/rmt/0m # Tape device path
> > TAPEBLK 64 # Tape block size (Kbytes)
> > TAPESIZE 2000000 # Maximum amount of data to put ontape
> > (Kbytes)
> >
> > # Log Archive Tape Device
> >
> > LTAPEDEV /dev/null # Log tape device path
> > #LTAPEDEV /dev/rmt/0m # Log tape device path
> > LTAPEBLK 64 # Log tape block size (Kbytes)
> > LTAPESIZE 2000000 # Max amount of data to put on logtape
> > (Kbytes)
> >
> > # Optical
> >
> > STAGEBLOB # INFORMIX-OnLine/Optical staging
area
> >
> > # System Configuration
> >
> > SERVERNUM 4 # Unique id corresponding to aOnLine
> > instance
> > DBSERVERNAME sales_prod # Name of default database server> > DBSERVERALIASES salse_net_prod # List of alternate dbservernames
> > NETTYPE ipcshm,3,400,CPU # Configure poll thread(s) fornettype
> > NETTYPE soctcp,1,200,NET # Configure poll thread(s) fornettype
> > 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 3 # Number of user (cpu) vps
> > SINGLE_CPU_V
The bufwaits ratio, which is not documented, but which I developed
about 2 years ago when I noticed bufwaits HUGELY higher in 7.xx than in
5.xx, is:
bufwait_ratio = (bufwaits / (pagreads + bufwrits)) * 100
This figure should be below 7% on a healthy V7.xx system. If it is
significantly higher then either you are experiencing LRU contention or
are being hit with a bug I have identified that causes inordinate
numbers of bufwaits at certain values for LRUS (64 and 96 are known
trouble makers). Bufwaits ratio for any 5.xx servers should be below
2% (my few remaining 5.0x servers hover around 0.3%).
Art S. Kagel
Vic Newman wrote:
>
> Art,
> Thanks for the valuable info. One final question. How did you
> calculate the 25% buffer wait. I must justify my parameter changes and
> I do not know how to calculate the bufwaits ratio, but I am learning
> more everyday.
>
> Thanks again,
> Vic
>
> In article <37939B9B.F60EE702@bloomberg.net>,
> kagel@bloomberg.net wrote:
> > Everything looks fine except you definitely need many more buffers.
> > I'd start with 100,000 and work from there. Also with 240 users you
> > can need more than 16 LRUS which is verified by your enormous
> bufwaits
> > ratio of 25%, it should be below 7%. Go for broke and configure 127
> > LRUs (128 triggers a harmless but annoying error message at
> startup).
> > Also I see you are runing on HP. HPUX is aggressive about aging long
> > running processes. You should have NOAGE set it your 7.22 supports
> it,
> > check the release notes for support and possible patches. Also I
> > notice very long checkpoints which will only get worse with more
> > buffers. Reset LRU_MAX_DIRTY to a value between 2 and 10 and
> > LRU_MIN_DIRTY to a value between 0 and 5 and adjust to reduce
> > checkpoint duration to an acceptable level.
> >
> > Just NOAGE and increasing LRUs and buffers and you will see a
> > significant improvement and reduced system impact from the bufwait
> > spins.
> >
> > Art S. Kagel
> >
> > Vic Newman wrote:
> > >
> > > In article <379345E3.E314EBB4@bloomberg.net>,
> > > kagel@bloomberg.net wrote:
> > > > Post your ONCONFIG file, onstat -R, onstat -p, onstat -F, onstat -
> m,
> > > > onstat -l outputs and we'll look it over.> > > >
> > > > Art S. Kagel
> > > >
> > > > Vic Newman wrote:
> > > > >
> > > > > In article <7muke7$lt8$1@nnrp1.deja.com>,
> > > > > Yuri Dovgart <y_dovgart@tci.ukrtel.net> wrote:
> > > > > > In article <7mrhba$pd7$1@nnrp1.deja.com>,
> > > > > > Vic Newman <klball@my-deja.com> wrote:
> > > > > > > We are running 7.2 on hp 9000 with approx 240 users. I
> > > noticed
> > > > > the
> > > > > > > write cache percentage was 67%, the read cache percentage
> was
> > > 97%.
> > > > > Is
> > > > > > > the 67% ok. Are there any paramenters we should be looking
> at
> > > to
> > > > > > > increase this write cache percentage or is 67% an acceptable
> > > level?
> > > > > >
> > > > > > Generally speaking 67% is too low. But this number depends on
> the
> > > type
> > > > > > of activities, performed in your system. For example, if you
> have
> > > 100
> > > > > K
> > > > > > reads with cache ratio 98% and 1 K writes with cache ratio 70
> % -
> > > I
> > > > > > think it's OK. But if balance between reads and writes is
> about
> > > 50/50
> > > > > -
> > > > > > you need tuning. So, it's your choice is it OK, or not.
> > > > > >
> > > > > > First step to increase cache ratio is to add more BUFFERS.
> Check
> > > > > column
> > > > > > ovbuff in "onstat -p" output - if there is some number there,
> you
> > > > > > certainly need to add some buffers. Other steps, such as
> tuning
> > > LRU
> > > > > > queues and flushing params are dependent on the system
> profile. To
> > > > > help
> > > > > > you in this tuning, we need your "onstat -a" and ONCONFIG
> file.
> > > > > >
> > > > > > --
> > > > > > With best regards, Yuri Dovgart,
> > > > > > SAP R/3, Informix consultant,
> > > > > > "Telecominvest" company.
> > > > > > E-mail y_dovgart@tci.ukrtel.net
> > > > > >
> > > > > > Sent via Deja.com http://www.deja.com/
> > > > > > Share what you know. Learn what you don't.
> > > > > >
> > > > >
> > > > > The ovbuff in onstat -p is 0. The output from ostat -a is quite
> > > lengthy
> > > > > and I did not want to post the entire output because of that.
> Is
> > > there
> > > > > a specific part of in that is helpful?
> > > > >
> > > > > Sent via Deja.com http://www.deja.com/
> > > > > Share what you know. Learn what you don't.
> > > >
> > >
> > > Listed below are the onconfig and onstat R, p, f, m and l.
> > > Thanks for your input.
> > >
> > > Vic
> > >
> > >
> #***********************************************************************
> > > ***
> > > #
> > > # INFORMIX SOFTWARE, INC.
> > > #
> > > # Title: onconfig.sales_prod
> > > # Description: INFORMIX-OnLine Configuration Parameters
> > > #
> > >
> #***********************************************************************
> > > ***
> > >
> > > # Root Dbspace Configuration
> > >
> > > ROOTNAME rootdbs # Root dbspace name> > > ROOTPATH /dev/AR1LUN4/rlv0 # Path for device containing root
> > > dbspace
> > > ROOTOFFSET 0 # Offset of root dbspace into device
> > > (Kbytes)
> > > ROOTSIZE 100000 # 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 rootdbs # Location (dbspace) of physical log
> > > PHYSFILE 40000 # Physical log file size (Kbytes)> > >
> > > # Logical Log Configuration
> > >
> > > LOGFILES 40 # Number of logical log files
> > > LOGSIZE 1000 # Logical log size (Kbytes)> > >
> > > # Diagnostics
> > >
> > > MSGPATH /var/informix/sales_prod.log # System message log
> file
> > > path
> > > CONSOLE /var/informix/sales_prod.con # System console
> message
> > > path
> > > ALARMPROGRAM /usr/informix/etc/autolog.sales # Alarm program path
> > >
> > > # System Archive Tape Device
> > >
> > > #TAPEDEV /dev/null # Tape device path
> > > TAPEDEV /dev/rmt/0m # Tape device path
> > > TAPEBLK 64 # Tape block size (Kbytes)
> > > TAPESIZE 2000000 # Maximum amount of data to put on> tape
> > > (Kbytes)
> > >
> > > # Log Archive Tape Device
> > >
> > > LTAPEDEV /dev/null # Log tape device path
> > > #LTAPEDEV /dev/rmt/0m # Log tape device path
> > > LTAPEBLK 64 # Log tape block size (Kbytes)@@