write cache / NETTYPE
How important is the % Write cache on the onstat -p (listed below)? I read
you should shoot for 85%..... ours is very low... 8% and sometimes 0%. How
do you tune the database for write cache. We do mostly reads and inserts and
very few updates.
Also does anyone have some information about NETTYPE. We only have one
NETTYPE (VP class: CPU) in our onconfig. I see other people with 2 (CPU and
NET.) How do you determine what you need?
This is for Informix 7.2.4UC8 on Pyramid MS with 4 CPUs and 512M memory.
Thanks in advance!
Val
onstat -p
INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:21:45 --
34472 Kb
ytes
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
513199 1693266 16044039 96.80 66368 140418 80799 17.86
isamtot open start read write rewrite delete commit
rollbk
13148588 805474 1867135 4603303 10191 9550 4174 1624 0
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 28431.32 11586.86 272 974
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
40160 0 8939027 0 0 64 2132 14592
ixda-RA idx-RA da-RA RA-pgsused lchwaits
17698 41 245539 262064 8127
onstat -c
INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:22:39 --
34472 Kb
ytes
Configuration File: /tras/informix.new/etc/onconfig_natl.new
#**************************************************************************
#
# INFORMIX SOFTWARE, INC.
#
# Title: onconfig_natl.new
# Description: INFORMIX-OnLine Configuration Parameters
#
#**************************************************************************
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dev/rawrootdbs # 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 /dev/rawrootdbsm # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHYSDBS rootdbs # Location (dbspace) of physical log
PHYSFILE 12500 # Physical log file size (Kbytes)
# Logical Log Configuration
LOGFILES 10 # Number of logical log files
LOGSIZE 6250 # Logical log size (Kbytes)
# Diagnostics
MSGPATH /tras/informix.new/tras.new.log # System message log file
path
CONSOLE /dev/console # System console message path
ALARMPROGRAM /tras/informix.new/etc/log_full.sh # Alarm program path
TBLSPACE_STATS 1
# System Archive Tape Device
TAPEDEV /dev/ios0/rstape111h # Tape device path
TAPEBLK 20 # Tape block size (Kbytes)
TAPESIZE 4000000 # Maximum amount of data to put on tape
(Kbytes)
# Log Archive Tape Device
LTAPEDEV /dev/null # Log tape device path
LTAPEBLK 16 # Log tape block size (Kbytes)
LTAPESIZE 10240 # Max amount of data to put on log tape
(Kbytes)
# Optical
STAGEBLOB # INFORMIX-OnLine/Optical staging area
# System Configuration
SERVERNUM 17 # Unique id corresponding to a OnLineinstance
DBSERVERNAME natl_new # Name of default database server
DBSERVERALIASES # List of alternate dbservernames
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 formulti-processor
NUMCPUVPS 2 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps toone
NOAGE 1 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 2 # Affinity number of processors
# Shared Memory Parameters
LOCKS 15000 # Maximum number of locks
BUFFERS 8000 # Maximum number of shared buffers
NUMAIOVPS 6 # Number of IO vps
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 30 # Maximum number of logical log files
CLEANERS 16 # Number of buffer cleaner processes
SHMBASE 0x20000000 # Shared memory base address
SHMVIRTSIZE 16384 # initial virtual shared memory segment size
SHMADD 8192 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 16 # 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 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.
OFF_RECVRY_THREADS 10 # Default number of offline workerthreads
ON_RECVRY_THREADS 1 # Default number of online worker threads
# Data Replication Variables
# DRAUTO: 0 manual, 1 retain type, 2 reverse type
DRAUTO 0 # DR automatic switchover
DRINTERVAL 30 # DR max time between DR buffer flushes (in
sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /tras/informix.new/etc/dr.lostfound # DR lost+found filepath
# CDR Variables
CDR_LOGBUFFERS 2048 # size of log reading buffer pool (Kbytes)
CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional)
CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue
(Kb
ytes)
# Backup/Restore variables
BAR_ACT_LOG /tmp/bar_act.log
BAR_MAX_BACKUP 0
BAR_RETRY 1
BAR_NB_XPORT_COUNT 10
BAR_XFER_BUF_SIZE 31
# Read Ahead Variables
RA_PAGES
Valerie,
My first impression is that your buffers are WAY too low. Info I have
suggests that up to 25% of your memory be used for buffers (assuming this is
an OLTP and not DSS application). In that case, your buffers should be in
the 64000 range.
Just a quick thought. And waiting for Art to weigh in with his always
helpful insights....
Doug
Webber Valerie H wrote in message <7saoa8$5l8$1@news.xmission.com>...
>
>How important is the % Write cache on the onstat -p (listed below)? I read
>you should shoot for 85%..... ours is very low... 8% and sometimes 0%. How
>do you tune the database for write cache. We do mostly reads and inserts
and
>very few updates.
>
>Also does anyone have some information about NETTYPE. We only have one
>NETTYPE (VP class: CPU) in our onconfig. I see other people with 2 (CPU and
>NET.) How do you determine what you need?
>
>This is for Informix 7.2.4UC8 on Pyramid MS with 4 CPUs and 512M memory.
>
>Thanks in advance!
>Val
>onstat -p>
>INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:21:45 --
>34472 Kb
>ytes
>
>Profile
>dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
>513199 1693266 16044039 96.80 66368 140418 80799 17.86
>
>isamtot open start read write rewrite delete commit
>rollbk
>13148588 805474 1867135 4603303 10191 9550 4174 1624 0
>
>ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
>0 0 0 28431.32 11586.86 272 974
>
>bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
>40160 0 8939027 0 0 64 2132 14592
>
>ixda-RA idx-RA da-RA RA-pgsused lchwaits
>17698 41 245539 262064 8127
>
>onstat -c>
>INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:22:39 --
>34472 Kb
>ytes
>
>Configuration File: /tras/informix.new/etc/onconfig_natl.new
>#**************************************************************************
>#
># INFORMIX SOFTWARE, INC.
>#
># Title: onconfig_natl.new
># Description: INFORMIX-OnLine Configuration Parameters
>#
>#**************************************************************************
>
># Root Dbspace Configuration
>
>ROOTNAME rootdbs # Root dbspace name
>ROOTPATH /dev/rawrootdbs # 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 /dev/rawrootdbsm # Path for device containing mirrored root
>MIRROROFFSET 0 # Offset into mirrored device (Kbytes)>
># Physical Log Configuration
>
>PHYSDBS rootdbs # Location (dbspace) of physical log
>PHYSFILE 12500 # Physical log file size (Kbytes)>
># Logical Log Configuration
>
>LOGFILES 10 # Number of logical log files
>LOGSIZE 6250 # Logical log size (Kbytes)>
># Diagnostics
>
>MSGPATH /tras/informix.new/tras.new.log # System message log file
>path
>CONSOLE /dev/console # System console message path
>ALARMPROGRAM /tras/informix.new/etc/log_full.sh # Alarm program path
>TBLSPACE_STATS 1>
># System Archive Tape Device
>
>TAPEDEV /dev/ios0/rstape111h # Tape device path
>TAPEBLK 20 # Tape block size (Kbytes)
>TAPESIZE 4000000 # Maximum amount of data to put on tape
>(Kbytes)>
># Log Archive Tape Device
>
>LTAPEDEV /dev/null # Log tape device path
>LTAPEBLK 16 # Log tape block size (Kbytes)
>LTAPESIZE 10240 # Max amount of data to put on log tape
>(Kbytes)>
># Optical
>
>STAGEBLOB # INFORMIX-OnLine/Optical staging area
>
># System Configuration
>
>SERVERNUM 17 # Unique id corresponding to a OnLine>instance
>DBSERVERNAME natl_new # Name of default database server
>DBSERVERALIASES # List of alternate dbservernames
>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 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 2 # Affinity number of processors>
># Shared Memory Parameters
>
>LOCKS 15000 # Maximum number of locks
>BUFFERS 8000 # Maximum number of shared buffers
>NUMAIOVPS 6 # Number of IO vps
>PHYSBUFF 32 # Physical log buffer size (Kbytes)
>LOGBUFF 32 # Logical log buffer size (Kbytes)>LOGSMAX 30 # Maximum number of logical log files
>CLEANERS 16 # Number of buffer cleaner processes
>SHMBASE 0x20000000 # Shared memory base address
>SHMVIRTSIZE 16384 # initial virtual shared memory segmentsize
>SHMADD 8192 # Size of new shared memory segments
>(Kbytes)
>SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
>CKPTINTVL 300 # Check point interval (in sec)
>LRUS 16 # 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 # 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.
>
>OFF_RECVRY_THREADS 10 # Default number of offline worker>threads
>ON_RECVRY_THREADS 1 # Default number of online worker threads>
># Data Replication Variables
># DRAUTO: 0 manual, 1 retain type, 2 reverse type
>DRAUTO 0 # DR automatic switchover
>DRINTERVAL 30 # DR max time between DR buffer flushes (in
>sec)
>DRTIMEOUT 30 # DR network timeout (i
I agree, crank up your buffers. Even Inserts will take advantage of the page
being already in cache! Plus Index modifications will greatly improve.
Gee, I need to shoot for 85% on write cache? Does that mean I need to
reduce buffering since I regularly see 93%-95% on writes and 97%-98%
on reads with 30G of DB? :-)
S.W.
Doug Agnew <dagnew@charlottepipe.com> wrote in message
news:CF5G3.5625$9W2.9723@news2.mco...
> Valerie,
>
> My first impression is that your buffers are WAY too low. Info I have
> suggests that up to 25% of your memory be used for buffers (assuming this
is
> an OLTP and not DSS application). In that case, your buffers should be in
> the 64000 range.
>
> Just a quick thought. And waiting for Art to weigh in with his always
> helpful insights....
>
>
> Doug
>
> Webber Valerie H wrote in message <7saoa8$5l8$1@news.xmission.com>...
> >
> >How important is the % Write cache on the onstat -p (listed below)? I
read
> >you should shoot for 85%..... ours is very low... 8% and sometimes 0%.
How
> >do you tune the database for write cache. We do mostly reads and inserts
> and
> >very few updates.
> >
> >Also does anyone have some information about NETTYPE. We only have one
> >NETTYPE (VP class: CPU) in our onconfig. I see other people with 2 (CPU
and
> >NET.) How do you determine what you need?
> >
> >This is for Informix 7.2.4UC8 on Pyramid MS with 4 CPUs and 512M memory.
> >
> >Thanks in advance!
> >Val
> >onstat -p> >
> >INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:21:45 --
> >34472 Kb
> >ytes
> >
> >Profile
> >dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> >513199 1693266 16044039 96.80 66368 140418 80799 17.86
> >
> >isamtot open start read write rewrite delete commit
> >rollbk
> >13148588 805474 1867135 4603303 10191 9550 4174 1624 0
> >
> >ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> >0 0 0 28431.32 11586.86 272 974
> >
> >bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> >40160 0 8939027 0 0 64 2132 14592
> >
> >ixda-RA idx-RA da-RA RA-pgsused lchwaits
> >17698 41 245539 262064 8127
> >
> >onstat -c> >
> >INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:22:39 --
> >34472 Kb
> >ytes
> >
> >Configuration File: /tras/informix.new/etc/onconfig_natl.new
>
>#**************************************************************************
>
> >#
> ># INFORMIX SOFTWARE, INC.
> >#
> ># Title: onconfig_natl.new
> ># Description: INFORMIX-OnLine Configuration Parameters
> >#
>
>#**************************************************************************
> >
> ># Root Dbspace Configuration
> >
> >ROOTNAME rootdbs # Root dbspace name
> >ROOTPATH /dev/rawrootdbs # 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 /dev/rawrootdbsm # Path for device containing mirroredroot
> >MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> >
> ># Physical Log Configuration
> >
> >PHYSDBS rootdbs # Location (dbspace) of physical log
> >PHYSFILE 12500 # Physical log file size (Kbytes)> >
> ># Logical Log Configuration
> >
> >LOGFILES 10 # Number of logical log files
> >LOGSIZE 6250 # Logical log size (Kbytes)> >
> ># Diagnostics
> >
> >MSGPATH /tras/informix.new/tras.new.log # System message log file
> >path
> >CONSOLE /dev/console # System console message path
> >ALARMPROGRAM /tras/informix.new/etc/log_full.sh # Alarm program path
> >TBLSPACE_STATS 1> >
> ># System Archive Tape Device
> >
> >TAPEDEV /dev/ios0/rstape111h # Tape device path
> >TAPEBLK 20 # Tape block size (Kbytes)
> >TAPESIZE 4000000 # Maximum amount of data to put on tape
> >(Kbytes)> >
> ># Log Archive Tape Device
> >
> >LTAPEDEV /dev/null # Log tape device path
> >LTAPEBLK 16 # Log tape block size (Kbytes)
> >LTAPESIZE 10240 # Max amount of data to put on log tape
> >(Kbytes)> >
> ># Optical
> >
> >STAGEBLOB # INFORMIX-OnLine/Optical staging area
> >
> ># System Configuration
> >
> >SERVERNUM 17 # Unique id corresponding to a OnLine> >instance
> >DBSERVERNAME natl_new # Name of default database server
> >DBSERVERALIASES # List of alternate dbservernames
> >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 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 2 # Affinity number of processors> >
> ># Shared Memory Parameters
> >
> >LOCKS 15000 # Maximum number of locks
> >BUFFERS 8000 # Maximum number of shared buffers
> >NUMAIOVPS 6 # Number of IO vps
> >PHYSBUFF 32 # Physical log buffer size (Kbytes)
> >LOGBUFF 32 # Logical log buffer size (Kbytes)> >LOGSMAX 30 # Maximum number of logical log files
> >CLEANERS 16 # Number of buffer cleaner processes
> >SHMBASE 0x20000000 # Shared memory base address
> >SHMVIRTSIZE 16384 # initial virtual shared memory segment> size
> >SHMADD 8192 # Size of new shared memory segments
> >(Kbytes)
> >SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> >CKPTINTVL 300 # Check point interval (in sec)
> >LRUS 16 # 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 # 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 On
I'm with Doug here. You are woefully short on BUFFERS. Your onstat -p
shows 500,000 pages read in 40 hours which means that you are turning over
almost all of your buffers every 40 minutes! That is why you do not have
a decent write cache%. The read cache% shows that most queries are
intense and short, that's OK (though you may want to watch chunk activity
for bottlenecks and opportunities to fragment and spread the load).
Another thing, the LRU_MAX/MIN_DIRTY values are VERY low for a small
server with little update activity. This will also contribute to low
write cache%. Make those 10,5 or 20,10. I know I usually recommend 2,0
or 1,0 but that presumes massive buffer pools and huge transaction rates.
As to the NETTYPE, you only have one connection name (DBSERVERNAME) and no
aliases so you only NEED one NETTYPE. That value looks fine to me.
Webber Valerie H wrote:
>
> How important is the % Write cache on the onstat -p (listed below)? I read
> you should shoot for 85%..... ours is very low... 8% and sometimes 0%. How
> do you tune the database for write cache. We do mostly reads and inserts and
> very few updates.
>
> Also does anyone have some information about NETTYPE. We only have one
> NETTYPE (VP class: CPU) in our onconfig. I see other people with 2 (CPU and
> NET.) How do you determine what you need?
>
> This is for Informix 7.2.4UC8 on Pyramid MS with 4 CPUs and 512M memory.
>
> Thanks in advance!
> Val
> onstat -p>
> INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:21:45 --
> 34472 Kb
> ytes
>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 513199 1693266 16044039 96.80 66368 140418 80799 17.86
>
> isamtot open start read write rewrite delete commit
> rollbk
> 13148588 805474 1867135 4603303 10191 9550 4174 1624 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 28431.32 11586.86 272 974
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 40160 0 8939027 0 0 64 2132 14592
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 17698 41 245539 262064 8127
>
> onstat -c>
> INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:22:39 --
> 34472 Kb
> ytes
>
> Configuration File: /tras/informix.new/etc/onconfig_natl.new
> #**************************************************************************
> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: onconfig_natl.new
> # Description: INFORMIX-OnLine Configuration Parameters
> #
> #**************************************************************************
>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name
> ROOTPATH /dev/rawrootdbs # 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 /dev/rawrootdbsm # Path for device containing mirrored root
> MIRROROFFSET 0 # Offset into mirrored device (Kbytes)>
> # Physical Log Configuration
>
> PHYSDBS rootdbs # Location (dbspace) of physical log
> PHYSFILE 12500 # Physical log file size (Kbytes)>
> # Logical Log Configuration
>
> LOGFILES 10 # Number of logical log files
> LOGSIZE 6250 # Logical log size (Kbytes)>
> # Diagnostics
>
> MSGPATH /tras/informix.new/tras.new.log # System message log file
> path
> CONSOLE /dev/console # System console message path
> ALARMPROGRAM /tras/informix.new/etc/log_full.sh # Alarm program path
> TBLSPACE_STATS 1>
> # System Archive Tape Device
>
> TAPEDEV /dev/ios0/rstape111h # Tape device path
> TAPEBLK 20 # Tape block size (Kbytes)
> TAPESIZE 4000000 # Maximum amount of data to put on tape
> (Kbytes)>
> # Log Archive Tape Device
>
> LTAPEDEV /dev/null # Log tape device path
> LTAPEBLK 16 # Log tape block size (Kbytes)
> LTAPESIZE 10240 # Max amount of data to put on log tape
> (Kbytes)>
> # Optical
>
> STAGEBLOB # INFORMIX-OnLine/Optical staging area
>
> # System Configuration
>
> SERVERNUM 17 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME natl_new # Name of default database server
> DBSERVERALIASES # List of alternate dbservernames
> 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 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 2 # Affinity number of processors>
> # Shared Memory Parameters
>
> LOCKS 15000 # Maximum number of locks
> BUFFERS 8000 # Maximum number of shared buffers
> NUMAIOVPS 6 # Number of IO vps
> PHYSBUFF 32 # Physical log buffer size (Kbytes)
> LOGBUFF 32 # Logical log buffer size (Kbytes)> LOGSMAX 30 # Maximum number of logical log files
> CLEANERS 16 # Number of buffer cleaner processes
> SHMBASE 0x20000000 # Shared memory base address
> SHMVIRTSIZE 16384 # initial virtual shared memory segment size
> SHMADD 8192 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
> CKPTINTVL 300 # Check point interval (in sec)
> LRUS 16 # 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 # 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_RECV
Webber Valerie H wrote:
> How important is the % Write cache on the onstat -p (listed below)?
> I read you should shoot for 85%..... ours is very low... 8% and
> sometimes 0%. How do you tune the database for write cache. We do
> mostly reads and inserts and very few updates.
>
>[...another Q snipped...]
>
> This is for Informix 7.2.4UC8 on Pyramid MS with 4 CPUs and 512M
> memory.
> onstat -p>
> INFORMIX-OnLine Version 7.24.UC8 -- On-Line -- Up 1 days 16:21:45 --
> 34472 Kbytes
>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 513199 1693266 16044039 96.80 66368 140418 80799 17.86
I've seen Art and Doug's responses. I don't think the write cache
is very important to you at all. You are doing at least 10 physical
reads per physical write, and about 200 bufreads per bufwrite, so it
is unlikely that tuning your write cache percentage will help very
much.
Since you've got 512 MB of memory and are only using 32 MB for your
OnLine shared memory, you could probably afford to increase the amount
used for OnLine -- which is what both Art and Doug recommended. But
in my view, if you have a read-intensive application, you do not need
to be concerned about the write cache ratio.
FWIW: I developed a system, oh, many many moons ago, in which there
was a big data update run one night a week, followed by a lot of
reading and some minimal insert (and even less update) activity for
the rest of the week. If the stats were zeroed after the update run,
then the write cache ratio was substantially zero for the rest of the
week. It didn't matter -- the application worked acceptably fast and
the read cache ratio was right up in the 99% range.
--
Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net)
Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN
#include <disclaimer.h>