Question on SHMVIRTSIZE
Mary Gregory (IDS 9.40.FC4 on HP-UX, 6 CPUs, 12GB RAM) asked how to tell whether raising SHMVIRTSIZE would help, having seen a batch job drop from 19 to 12 hours after an increase even though the engine was never dynamically adding segments. Replies suggested monitoring onstat -p cache hit rates, onstat -g mem/ses/mgm and onstat -g seg. The consensus advice: if no extra virtual segments are being added (onstat -g seg), more SHMVIRTSIZE buys nothing; her read/write cache rates (96.9%/87.2%) and high bufwaits/latchwaits pointed instead to raising BUFFERS (to 200k-300k) plus LRUS/CLEANERS, with fuzzy checkpoints limiting the checkpoint impact. No confirmation of the outcome is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Are there any parameters that can be monitored to help determine whether or not increasing SHMVIRTSIZE will provide any benefit, or whether or not it is necessary? The only one I am aware of is if the engine dynamically allocates more memory, then this parameter should be increased. Our system was not dynamically adding more memory, but I increased this parameter anyway because we added more memory to the server, and now things are running much faster. I'm wondering if adding more virtual memory will increase things even more, but I have to assume there is a point where I will hit diminishing returns. Thanks for your thoughts. Mary Gregory Senior Systems Programmer Rheem Water Heating
More info would help with suggestions; - total memory on system - # of cpus - OS and version - version of IDS Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Mary Gregory Sent: Monday, April 30, 2007 2:34 PM To: ids@iiug.org Subject: Question on SHMVIRTSIZE [9043] Are there any parameters that can be monitored to help determine whether or not increasing SHMVIRTSIZE will provide any benefit, or whether or not it is necessary? The only one I am aware of is if the engine dynamically allocates more memory, then this parameter should be increased. Our system was not dynamically adding more memory, but I increased this parameter anyway because we added more memory to the server, and now things are running much faster. I'm wondering if adding more virtual memory will increase things even more, but I have to assume there is a point where I will hit diminishing returns. Thanks for your thoughts. Mary Gregory Senior Systems Programmer Rheem Water Heating ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.
HP-UX 11.11 IDS 9.40.FC4 6 CPU's 12 GB Memory -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Robert Roussey(IT) Sent: Monday, April 30, 2007 3:29 PM To: ids@iiug.org Subject: RE: Question on SHMVIRTSIZE [9044] More info would help with suggestions; - total memory on system - # of cpus - OS and version - version of IDS Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Mary Gregory Sent: Monday, April 30, 2007 2:34 PM To: ids@iiug.org Subject: Question on SHMVIRTSIZE [9043] Are there any parameters that can be monitored to help determine whether or not increasing SHMVIRTSIZE will provide any benefit, or whether or not it is necessary? The only one I am aware of is if the engine dynamically allocates more memory, then this parameter should be increased. Our system was not dynamically adding more memory, but I increased this parameter anyway because we added more memory to the server, and now things are running much faster. I'm wondering if adding more virtual memory will increase things even more, but I have to assume there is a point where I will hit diminishing returns. Thanks for your thoughts. Mary Gregory Senior Systems Programmer Rheem Water Heating ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.
I would think that adding more BUFFERS would get you more performance
improvement than increasing the SHMVRTSIZE. However increasing both propably
won't hurt, either way I'd add more BUFFERS.
Before you do that post the current values as well as an onstat -p.
----- Original Message ----
From: Mary Gregory <mary.gregory@rheem.com>
To: ids@iiug.org
Sent: Monday, April 30, 2007 3:37:42 PM
Subject: RE: Question on SHMVIRTSIZE [9045]
HP-UX 11.11
IDS 9.40.FC4
6 CPU's
12 GB Memory
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Robert Roussey(IT)
Sent: Monday, April 30, 2007 3:29 PM
To: ids@iiug.org
Subject: RE: Question on SHMVIRTSIZE [9044]
More info would help with suggestions;
- total memory on system
- # of cpus
- OS and version
- version of IDS
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Mary Gregory
Sent: Monday, April 30, 2007 2:34 PM
To: ids@iiug.org
Subject: Question on SHMVIRTSIZE [9043]
Are there any parameters that can be monitored to help determine whether
or not increasing SHMVIRTSIZE will provide any benefit, or whether or
not it is necessary? The only one I am aware of is if the engine
dynamically allocates more memory, then this parameter should be
increased. Our system was not dynamically adding more memory, but I
increased this parameter anyway because we added more memory to the
server, and now things are running much faster. I'm wondering if adding
more virtual memory will increase things even more, but I have to assume
there is a point where I will hit diminishing returns. Thanks for your
thoughts.
Mary Gregory
Senior Systems Programmer
Rheem Water Heating
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
I agree, but since we added more physical memory to the server, we have
been making parameter changes slowly and one at a time. I can tell you
that by adding more virtual memory, we took a 19 hour batch job down to
12 hours. Like I said before, I'm curious to know if there are any
statistics I could have looked at that would have helped me determine
that increasing the virtual memory would have provided such a big
benefit.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DL
Redden
Sent: Monday, April 30, 2007 9:08 PM
To: ids@iiug.org
Subject: Re: Question on SHMVIRTSIZE [9046]
I would think that adding more BUFFERS would get you more performance
improvement than increasing the SHMVRTSIZE. However increasing both
propably
won't hurt, either way I'd add more BUFFERS.
Before you do that post the current values as well as an onstat -p.
----- Original Message ----
From: Mary Gregory <mary.gregory@rheem.com>
To: ids@iiug.org
Sent: Monday, April 30, 2007 3:37:42 PM
Subject: RE: Question on SHMVIRTSIZE [9045]
HP-UX 11.11
IDS 9.40.FC4
6 CPU's
12 GB Memory
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Robert Roussey(IT)
Sent: Monday, April 30, 2007 3:29 PM
To: ids@iiug.org
Subject: RE: Question on SHMVIRTSIZE [9044]
More info would help with suggestions;
- total memory on system
- # of cpus
- OS and version
- version of IDS
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Mary Gregory
Sent: Monday, April 30, 2007 2:34 PM
To: ids@iiug.org
Subject: Question on SHMVIRTSIZE [9043]
Are there any parameters that can be monitored to help determine whether
or not increasing SHMVIRTSIZE will provide any benefit, or whether or
not it is necessary? The only one I am aware of is if the engine
dynamically allocates more memory, then this parameter should be
increased. Our system was not dynamically adding more memory, but I
increased this parameter anyway because we added more memory to the
server, and now things are running much faster. I'm wondering if adding
more virtual memory will increase things even more, but I have to assume
there is a point where I will hit diminishing returns. Thanks for your
thoughts.
Mary Gregory
Senior Systems Programmer
Rheem Water Heating
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
You can try check performance using cache statistics of IDS:
- reset statistics: onstat -z
- run expected load in expected time
- print statistics: onstat -p
e.g.:
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits
bufwrits %cached
561 566 92033 99.39 1725 3258
22100 92.19
The first 4 values show the statistics of reads from disks, pages,
buffers and the cache rate in percent. The last 4 values show the
corresponding statistics of writes.
Good cache rates for reads are >= 98% and for writes >= 85% .
Andreas
On Tuesday 01 May 2007 15:19, Mary Gregory wrote:
> I agree, but since we added more physical memory to the server, we
> have been making parameter changes slowly and one at a time. I can
> tell you that by adding more virtual memory, we took a 19 hour batch
> job down to 12 hours. Like I said before, I'm curious to know if
> there are any statistics I could have looked at that would have
> helped me determine that increasing the virtual memory would have
> provided such a big benefit.
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> DL Redden
> Sent: Monday, April 30, 2007 9:08 PM
> To: ids@iiug.org
> Subject: Re: Question on SHMVIRTSIZE [9046]
>
> I would think that adding more BUFFERS would get you more performance
> improvement than increasing the SHMVRTSIZE. However increasing both
> propably
> won't hurt, either way I'd add more BUFFERS.
>
> Before you do that post the current values as well as an onstat -p.
>
> ----- Original Message ----
> From: Mary Gregory <mary.gregory@rheem.com>
> To: ids@iiug.org
> Sent: Monday, April 30, 2007 3:37:42 PM
> Subject: RE: Question on SHMVIRTSIZE [9045]
>
> HP-UX 11.11
> IDS 9.40.FC4
> 6 CPU's
> 12 GB Memory
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Robert Roussey(IT)
> Sent: Monday, April 30, 2007 3:29 PM
> To: ids@iiug.org
> Subject: RE: Question on SHMVIRTSIZE [9044]
>
> More info would help with suggestions;
> - total memory on system
> - # of cpus
> - OS and version
> - version of IDS
>
> Bob Roussey
> Unix / Informix Administration
> Spirit Airlines
> Robert.Roussey@SpiritAir.com
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Mary Gregory
> Sent: Monday, April 30, 2007 2:34 PM
> To: ids@iiug.org
> Subject: Question on SHMVIRTSIZE [9043]
>
> Are there any parameters that can be monitored to help determine
> whether
>
> or not increasing SHMVIRTSIZE will provide any benefit, or whether or
> not it is necessary? The only one I am aware of is if the engine
> dynamically allocates more memory, then this parameter should be
> increased. Our system was not dynamically adding more memory, but I
> increased this parameter anyway because we added more memory to the
> server, and now things are running much faster. I'm wondering if
> adding more virtual memory will increase things even more, but I have
> to assume
>
> there is a point where I will hit diminishing returns. Thanks for
> your thoughts.
>
> Mary Gregory
> Senior Systems Programmer
> Rheem Water Heating
>
> *********************************************************************
>***
>
> *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
> *********************************************************************
>***
>
> *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
> *********************************************************************
>*** *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
> *********************************************************************
>*** *******
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
> *********************************************************************
>********** Forum Note: Use "Reply" to post a response in the
> discussion forum.
--
Andreas Breitfeld; Informix Development Munich
IBM Deutschland GmbH; Vorsitzender des Aufsichtsrats: Hans Ulrich
Maerki; Geschäftsführung: Martin Jetter (Vorsitzender), Rudolf Bauer,
Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Andreas
Kerstan; Sitz der Gesellschaft: Stuttgart; Registergericht: Amtsgericht
Stuttgart, HRB 14562; WEEE-Reg.-Nr. DE 99369940
If you know the session of the batch job, you can see what pieces of
memory it is using with "onstat -g mem".
"onstat -g ses" will show all sessions and their total use of SHM.
If you are using PDQ for the batch job, you should see it reflected by
getting snapshots of "onstat -g mgm" while it is running.
Maybe post your ONCONFIG file and people can comment on it as well as
a 24hr snapshot of "onstat -p".
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Mary Gregory
Sent: Tuesday, May 01, 2007 9:20 AM
To: ids@iiug.org
Subject: RE: Question on SHMVIRTSIZE [9047]
I agree, but since we added more physical memory to the server, we have
been making parameter changes slowly and one at a time. I can tell you
that by adding more virtual memory, we took a 19 hour batch job down to
12 hours. Like I said before, I'm curious to know if there are any
statistics I could have looked at that would have helped me determine
that increasing the virtual memory would have provided such a big
benefit.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DL
Redden
Sent: Monday, April 30, 2007 9:08 PM
To: ids@iiug.org
Subject: Re: Question on SHMVIRTSIZE [9046]
I would think that adding more BUFFERS would get you more performance
improvement than increasing the SHMVRTSIZE. However increasing both
propably
won't hurt, either way I'd add more BUFFERS.
Before you do that post the current values as well as an onstat -p.
----- Original Message ----
From: Mary Gregory <mary.gregory@rheem.com>
To: ids@iiug.org
Sent: Monday, April 30, 2007 3:37:42 PM
Subject: RE: Question on SHMVIRTSIZE [9045]
HP-UX 11.11
IDS 9.40.FC4
6 CPU's
12 GB Memory
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Robert Roussey(IT)
Sent: Monday, April 30, 2007 3:29 PM
To: ids@iiug.org
Subject: RE: Question on SHMVIRTSIZE [9044]
More info would help with suggestions;
- total memory on system
- # of cpus
- OS and version
- version of IDS
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Mary Gregory
Sent: Monday, April 30, 2007 2:34 PM
To: ids@iiug.org
Subject: Question on SHMVIRTSIZE [9043]
Are there any parameters that can be monitored to help determine whether
or not increasing SHMVIRTSIZE will provide any benefit, or whether or
not it is necessary? The only one I am aware of is if the engine
dynamically allocates more memory, then this parameter should be
increased. Our system was not dynamically adding more memory, but I
increased this parameter anyway because we added more memory to the
server, and now things are running much faster. I'm wondering if adding
more virtual memory will increase things even more, but I have to assume
there is a point where I will hit diminishing returns. Thanks for your
thoughts.
Mary Gregory
Senior Systems Programmer
Rheem Water Heating
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
************************************************************************
*******
Forum Note: Use "Reply" to post a response in the discussion forum.
I still haven't found a good way to determine whether or not adding more
virtual memory to the instance would speed up queries or not. I think I
might try to add another 128 MB just to see what happens. Also, I am
thinking about adding some more BUFFERS but I am trying to be very
cautious about not increasing my checkpoint times. From what I see
right now, everything is performing really well and I don't really need
to make any changes but you all might see something I don't. (I removed
some of the onconfig file parameters to save a little space.)
ONCONFIG PARAMETERS
ROOTNAME a_rootdbs # Root dbspace nameROOTPATH /dev/inf/chunk001 # Path for device containing root
dbspace
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)
ROOTSIZE 500000 # Size of root dbspace (Kbytes)PHYSDBS a_plogdbs # Location (dbspace) of physical log
PHYSFILE 100000 # Physical log file size (Kbytes)
LOGFILES 41 # Number of logical log files
LOGSIZE 50000 # Logical log size (Kbytes)
SERVERNUM 1 # Unique id corresponding to a OnLineinstance
DBSERVERNAME online_shm # Name of default database server
DBSERVERALIASES online_tcp # List of alternate dbservernames
NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 240 # Max time to wait of lock indistributed env.
RESIDENT 1 # Forced residency flag (Yes = 1, No =
0)
MULTIPROCESSOR 1 # 0 for single-processor, 1 formulti-processor
NUMCPUVPS 5 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vpsto one
NOAGE 1 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
LOCKS 500000 # Maximum number of locks
BUFFERS 155000 # Maximum number of shared buffers
NUMAIOVPS 2 # Number of IO vps
PHYSBUFF 64 # Physical log buffer size (Kbytes)
LOGBUFF 64 # Logical log buffer size (Kbytes)
CLEANERS 64 # Number of buffer cleaner processes
SHMBASE 0x0 # Shared memory base address
SHMVIRTSIZE 1792000 # initial virtual shared memory segmentsize
SHMADD 256000 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
CKPTINTVL 600 # Check point interval (in sec)
LRUS 64 # Number of LRU queues
LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 64 # Stack size (Kbytes)
DYNAMIC_LOGS 2
LTXHWM 40
LTXEHWM 55
# Read Ahead Variables
RA_PAGES 20 # Number of pages to attempt to readahead
RA_THRESHOLD 8 # Number of pages left before next group
DBSPACETEMPtempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
FILLFACTOR 90 # Fill factor for building indexes
# Parallel Database Queries (pdq)
MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority#DS_MAX_QUERIES # Maximum number of decision support
queries
#DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
OFF AFTER THE IMPORT
DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURNTHIS OFF AFTER THE IMPORT
DS_MAX_SCANS 1048576 # Maximum number of decision supportscans
DATASKIP off
OPTCOMPIND 2 # To hint the optimizer
DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
OFF (0)
ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
ABORT, 2 = WAITOPCACHEMAX 0 # Maximum optical cache size (Kbytes)
# HETERO_COMMIT (Gateway participation in distributed transactions)
# 1 => Heterogeneous Commit is enabled
# 0 (or any other value) => Heterogeneous Commit is disabled
HETERO_COMMIT 0
BLOCKTIMEOUT 3600 # Default timeout for system block
SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarmprogram path
# Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
OPT_GOAL -1
ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 oranything but 1)
BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
DS_MAX_QUERIES 6 # Maximum number of decision supportqueries
ONSTAT -P
IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
14:29:2
2 -- 2196484 Kbytes
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
87.17
isamtot open start read write rewrite delete commit
rollbk
12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
9953760 3
732
gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 157714.53 101146.03 1047 2882
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
34018215 3531 16248413925 10 0 2150 3447796
2746919
ixda-RA idx-RA da-RA RA-pgsused lchwaits
137210564 13433495 105455888 253872383 7973596
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Robert Roussey(IT)
Sent: Wednesday, May 02, 2007 5:14 PM
To: ids@iiug.org
Subject: RE: Question on SHMVIRTSIZE [9061]
If you know the session of the batch job, you can see what pieces of
memory it is using with "onstat -g mem".
"onstat -g ses" will show all sessions and their total use of SHM.
If you are using PDQ for the batch job, you should see it reflected by
getting snapshots of "onstat -g mgm" while it is running.
Maybe post your ONCONFIG file and people can comment on it as well as
a 24hr snapshot of "onstat -p".
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
I started to reply to this and then put it aside while I dealt with other
issues.
Certainly the easiest way to determine if it benefits is to run a benchmark
on a clean box, and then add the memory and re-run the benchmark. Alas that
is not always possible.
I would be more apt to determine if there was a performance issue first that
I am trying to address and then look at the resources required to resolve
that issue - of which memory could well be a resource.
In a vacuum, you might ask yourself, what is happening with the memory that
we are using? Are we exercising all of it?
Certainly your cache hit rate is lowish and you have high bufwaits and
latchwaits. But if there is no preceived issue, then I would leave well
enough alone.
j.
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org]On Behalf Of
Mary Gregory
Sent: Tuesday, May 08, 2007 12:07 PM
To: ids@iiug.org
Subject: RE: Question on SHMVIRTSIZE [9094]
I still haven't found a good way to determine whether or not adding more
virtual memory to the instance would speed up queries or not. I think I
might try to add another 128 MB just to see what happens. Also, I am
thinking about adding some more BUFFERS but I am trying to be very
cautious about not increasing my checkpoint times. From what I see
right now, everything is performing really well and I don't really need
to make any changes but you all might see something I don't. (I removed
some of the onconfig file parameters to save a little space.)
ONCONFIG PARAMETERS
ROOTNAME a_rootdbs # Root dbspace nameROOTPATH /dev/inf/chunk001 # Path for device containing root
dbspace
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)
ROOTSIZE 500000 # Size of root dbspace (Kbytes)PHYSDBS a_plogdbs # Location (dbspace) of physical log
PHYSFILE 100000 # Physical log file size (Kbytes)
LOGFILES 41 # Number of logical log files
LOGSIZE 50000 # Logical log size (Kbytes)
SERVERNUM 1 # Unique id corresponding to a OnLineinstance
DBSERVERNAME online_shm # Name of default database server
DBSERVERALIASES online_tcp # List of alternate dbservernames
NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
DEADLOCK_TIMEOUT 240 # Max time to wait of lock indistributed env.
RESIDENT 1 # Forced residency flag (Yes = 1, No =
0)
MULTIPROCESSOR 1 # 0 for single-processor, 1 formulti-processor
NUMCPUVPS 5 # Number of user (cpu) vps
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vpsto one
NOAGE 1 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
LOCKS 500000 # Maximum number of locks
BUFFERS 155000 # Maximum number of shared buffers
NUMAIOVPS 2 # Number of IO vps
PHYSBUFF 64 # Physical log buffer size (Kbytes)
LOGBUFF 64 # Logical log buffer size (Kbytes)
CLEANERS 64 # Number of buffer cleaner processes
SHMBASE 0x0 # Shared memory base address
SHMVIRTSIZE 1792000 # initial virtual shared memory segmentsize
SHMADD 256000 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
CKPTINTVL 600 # Check point interval (in sec)
LRUS 64 # Number of LRU queues
LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 64 # Stack size (Kbytes)
DYNAMIC_LOGS 2
LTXHWM 40
LTXEHWM 55
# Read Ahead Variables
RA_PAGES 20 # Number of pages to attempt to readahead
RA_THRESHOLD 8 # Number of pages left before next group
DBSPACETEMPtempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
FILLFACTOR 90 # Fill factor for building indexes
# Parallel Database Queries (pdq)
MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority#DS_MAX_QUERIES # Maximum number of decision support
queries
#DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
OFF AFTER THE IMPORT
DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURNTHIS OFF AFTER THE IMPORT
DS_MAX_SCANS 1048576 # Maximum number of decision supportscans
DATASKIP off
OPTCOMPIND 2 # To hint the optimizer
DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
OFF (0)
ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
ABORT, 2 = WAITOPCACHEMAX 0 # Maximum optical cache size (Kbytes)
# HETERO_COMMIT (Gateway participation in distributed transactions)
# 1 => Heterogeneous Commit is enabled
# 0 (or any other value) => Heterogeneous Commit is disabled
HETERO_COMMIT 0
BLOCKTIMEOUT 3600 # Default timeout for system block
SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarmprogram path
# Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
OPT_GOAL -1
ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 oranything but 1)
BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
DS_MAX_QUERIES 6 # Maximum number of decision supportqueries
ONSTAT -P
IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
14:29:2
2 -- 2196484 Kbytes
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
87.17
isamtot open start read write rewrite delete commit
rollbk
12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
9953760 3
732
gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 157714.53 101146.03 1047 2882
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
34018215 3531 16248413925 10 0 2150 3447796
2746919
ixda-RA idx-RA da-RA RA-pgsused lchwaits
137210564 13433495 105455888 253872383 7973596
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
Robert Roussey(IT)
Sent: Wednesday, May 02, 2007 5:14 PM
To: ids@iiug.org
Subject: RE: Question on SHMVIRTSIZE [9061]
If you know the session of the batch job, you can see what pieces of
memory it is using with "onstat -g mem".
"onstat -g ses" will show all sessions and their total use of SHM.
If you are using PDQ for the batch job, you should see it reflected by
getting snapshots of "onstat -g mgm" while it is running.
Maybe post your ONCONFIG file and people can comment on it as well as
a 24hr snapshot of "onstat -p".
Bob Roussey
Unix / Informix Administration
Spirit Airlines
Robert.Roussey@SpiritAir.com
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
On 08/05/07, Mary Gregory <mary.gregory@rheem.com> wrote:
> I still haven't found a good way to determine whether or not adding more
> virtual memory to the instance would speed up queries or not. I think I
> might try to add another 128 MB just to see what happens. Also, I am
> thinking about adding some more BUFFERS but I am trying to be very
> cautious about not increasing my checkpoint times. From what I see
> right now, everything is performing really well and I don't really need
> to make any changes but you all might see something I don't. (I removed
> some of the onconfig file parameters to save a little space.)
>
> ONCONFIG PARAMETERS
>
> ROOTNAME a_rootdbs # Root dbspace name> ROOTPATH /dev/inf/chunk001 # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 500000 # Size of root dbspace (Kbytes)> PHYSDBS a_plogdbs # Location (dbspace) of physical log
> PHYSFILE 100000 # Physical log file size (Kbytes)
> LOGFILES 41 # Number of logical log files
> LOGSIZE 50000 # Logical log size (Kbytes)
> SERVERNUM 1 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME online_shm # Name of default database server
> DBSERVERALIASES online_tcp # List of alternate dbservernames
> NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
> NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
> DEADLOCK_TIMEOUT 240 # 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 5 # 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
> LOCKS 500000 # Maximum number of locks
> BUFFERS 155000 # Maximum number of shared buffers
> NUMAIOVPS 2 # Number of IO vps
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)
> CLEANERS 64 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shared memory base address
> SHMVIRTSIZE 1792000 # initial virtual shared memory segment> size
> SHMADD 256000 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> CKPTINTVL 600 # Check point interval (in sec)
> LRUS 64 # Number of LRU queues
> LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 64 # Stack size (Kbytes)
>
> DYNAMIC_LOGS 2
> LTXHWM 40
> LTXEHWM 55>
> # Read Ahead Variables
> RA_PAGES 20 # Number of pages to attempt to read> ahead
> RA_THRESHOLD 8 # Number of pages left before next group
>
> DBSPACETEMP> tempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
>
> FILLFACTOR 90 # Fill factor for building indexes>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority> #DS_MAX_QUERIES # Maximum number of decision support
> queries
> #DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
> OFF AFTER THE IMPORT
> DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN> THIS OFF AFTER THE IMPORT
> DS_MAX_SCANS 1048576 # Maximum number of decision support> scans
> DATASKIP off
> OPTCOMPIND 2 # To hint the optimizer
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
> OFF (0)
> ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
> ABORT, 2 = WAIT> OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
> # HETERO_COMMIT (Gateway participation in distributed transactions)
> # 1 => Heterogeneous Commit is enabled
> # 0 (or any other value) => Heterogeneous Commit is disabled
> HETERO_COMMIT 0
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarm> program path
> # Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
> OPT_GOAL -1
> ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or> anything but 1)
> BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
> DS_MAX_QUERIES 6 # Maximum number of decision support> queries
>
> ONSTAT -P
>
> IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
> 14:29:2
> 2 -- 2196484 Kbytes>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
> 87.17
>
> isamtot open start read write rewrite delete commit
> rollbk
> 12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
> 9953760 3
> 732
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 0 0 0 0 0 0 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 157714.53 101146.03 1047 2882
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 34018215 3531 16248413925 10 0 2150 3447796
> 2746919
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 137210564 13433495 105455888 253872383 7973596
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Robert Roussey(IT)
> Sent: Wednesday, May 02, 2007 5:14 PM
> To: ids@iiug.org
> Subject: RE: Question on SHMVIRTSIZE [9061]
>
> If you know the session of the batch job, you can see what pieces of
> memory it is using with "onstat -g mem".
> "onstat -g ses" will show all sessions and their total use of SHM.
> If you are using PDQ for the batch job, you should see it reflected by
> getting snapshots of "onstat -g mgm" while it is running.
>
> Maybe post your ONCONFIG file and people can comment on it as well as
> a 24hr snapshot of "onstat -p".
>
> Bob Roussey
> Unix / Informix Administration
> Spirit Airlines
> Robert.Roussey@SpiritAir.com
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
Mary
With 9.4 you will be using 'fuzzy' checkpoints, therefore increasing
BUFFERS will have minimal effect on checkpoints. Your Buffers Read and
Write %ages are looowww, I would bump buffers to 200000 (to start)
then 250000 or even 300000. (Can't remember your platform but have a
recollection of plenty of memory and even on a 4Kb page machine this
is only 1.2 Gb). That will improve your %ages. Also you need to
increase LRUs (and Cleaners) to reduce the number of Buffer Waits. Try
127 for each.
If the engine has not added any additional virtual segment (onstat -g
seg) then there is little point in increasing SHMVIRTSIZE as more is
not required.
Keith
Your metrics indicate that you MAY need more BUFFERS:
BR = (34018215 / (243924199 + 1308089992)) * 100.00 = 2.1900
BTR = (((243924199 + 1308089992) / 155000) / 110.5) = 90.6153
RAU = (253872383/(137210564+13433495+105455888)) * 100.00 = 99.1300
The BTR of 90.6 is VERY high. You are turning over your entire buffer pool
every 39.7 seconds (or at least thrashing some subset many times a minute)! I
would take that 128MB you want to add to the virtual memory pool and use it and
more to add another 150000 buffers. You can fine tune that by monitoring onstat
-P over time to determine the actual number of buffers being thrashed (probably
it's a small number of tables that are highly active and are perpetually
forcing each other's pages out of the cache).
Art S. Kagel
----- Original Message -----
From: Keith Simmons <ids@iiug.org>
At: 5/09 5:14:22
On 08/05/07, Mary Gregory <mary.gregory@rheem.com> wrote:
> I still haven't found a good way to determine whether or not adding more
> virtual memory to the instance would speed up queries or not. I think I
> might try to add another 128 MB just to see what happens. Also, I am
> thinking about adding some more BUFFERS but I am trying to be very
> cautious about not increasing my checkpoint times. From what I see
> right now, everything is performing really well and I don't really need
> to make any changes but you all might see something I don't. (I removed
> some of the onconfig file parameters to save a little space.)
>
> ONCONFIG PARAMETERS
>
> ROOTNAME a_rootdbs # Root dbspace name> ROOTPATH /dev/inf/chunk001 # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 500000 # Size of root dbspace (Kbytes)> PHYSDBS a_plogdbs # Location (dbspace) of physical log
> PHYSFILE 100000 # Physical log file size (Kbytes)
> LOGFILES 41 # Number of logical log files
> LOGSIZE 50000 # Logical log size (Kbytes)
> SERVERNUM 1 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME online_shm # Name of default database server
> DBSERVERALIASES online_tcp # List of alternate dbservernames
> NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
> NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
> DEADLOCK_TIMEOUT 240 # 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 5 # 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
> LOCKS 500000 # Maximum number of locks
> BUFFERS 155000 # Maximum number of shared buffers
> NUMAIOVPS 2 # Number of IO vps
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)
> CLEANERS 64 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shared memory base address
> SHMVIRTSIZE 1792000 # initial virtual shared memory segment> size
> SHMADD 256000 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> CKPTINTVL 600 # Check point interval (in sec)
> LRUS 64 # Number of LRU queues
> LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 64 # Stack size (Kbytes)
>
> DYNAMIC_LOGS 2
> LTXHWM 40
> LTXEHWM 55>
> # Read Ahead Variables
> RA_PAGES 20 # Number of pages to attempt to read> ahead
> RA_THRESHOLD 8 # Number of pages left before next group
>
> DBSPACETEMP> tempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
>
> FILLFACTOR 90 # Fill factor for building indexes>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority> #DS_MAX_QUERIES # Maximum number of decision support
> queries
> #DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
> OFF AFTER THE IMPORT
> DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN> THIS OFF AFTER THE IMPORT
> DS_MAX_SCANS 1048576 # Maximum number of decision support> scans
> DATASKIP off
> OPTCOMPIND 2 # To hint the optimizer
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
> OFF (0)
> ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
> ABORT, 2 = WAIT> OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
> # HETERO_COMMIT (Gateway participation in distributed transactions)
> # 1 => Heterogeneous Commit is enabled
> # 0 (or any other value) => Heterogeneous Commit is disabled
> HETERO_COMMIT 0
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarm> program path
> # Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
> OPT_GOAL -1
> ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or> anything but 1)
> BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
> DS_MAX_QUERIES 6 # Maximum number of decision support> queries
>
> ONSTAT -P
>
> IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
> 14:29:2
> 2 -- 2196484 Kbytes>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
> 87.17
>
> isamtot open start read write rewrite delete commit
> rollbk
> 12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
> 9953760 3
> 732
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 0 0 0 0 0 0 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 157714.53 101146.03 1047 2882
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 34018215 3531 16248413925 10 0 2150 3447796
> 2746919
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 137210564 13433495 105455888 253872383 7973596
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Robert Roussey(IT)
> Sent: Wednesday, May 02, 2007 5:14 PM
> To: ids@iiug.org
> Subject: RE: Question on SHMVIRTSIZE [9061]
>
> If you know the session of the batch job, you can see what pieces of
> memory it is using with "onstat -g mem".
> "onstat -g ses" will show all sessions and their total use of SHM.
> If you are using PDQ for the batch job, you should see it reflected by
> getting snapshots of "onstat -g mgm" while it is running.
>
> Maybe post your ONCONFIG file and people can comment on it as well as
> a 24hr snapshot of "onstat -p".
>
> Bob Roussey
> Unix / Informix Administration
> Spirit Airlines
> Robert.Roussey@SpiritAir.com
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
Mary
With 9.4 you will be using 'fuzzy' checkpoints, therefore increasing
BUFFERS will have minimal effect on checkpoints. Your
Art,
What is a respectable BTR? I know that it depends but do you, or anyone else
for that matter, have any rules of thumb that make you start to worry on say a
primarily OLTP instance and a primarily OLAP instance?
Thanks,
DL
----- Original Message ----
From: "ART KAGEL, BLOOMBERG/ 731 LEXIN" <kagel@bloomberg.net>
To: ids@iiug.org
Sent: Monday, May 14, 2007 11:29:04 AM
Subject: Re: Question on SHMVIRTSIZE [9144]
Your metrics indicate that you MAY need more BUFFERS:
BR = (34018215 / (243924199 + 1308089992)) * 100.00 = 2.1900
BTR = (((243924199 + 1308089992) / 155000) / 110.5) = 90.6153
RAU = (253872383/(137210564+13433495+105455888)) * 100.00 = 99.1300
The BTR of 90.6 is VERY high. You are turning over your entire buffer pool
every 39.7 seconds (or at least thrashing some subset many times a minute)! I
would take that 128MB you want to add to the virtual memory pool and use it
and
more to add another 150000 buffers. You can fine tune that by monitoring
onstat-P over time to determine the actual number of buffers being thrashed
(probably
it's a small number of tables that are highly active and are perpetually
forcing each other's pages out of the cache).
Art S. Kagel
----- Original Message -----
From: Keith Simmons <ids@iiug.org>
At: 5/09 5:14:22
On 08/05/07, Mary Gregory <mary.gregory@rheem.com> wrote:
> I still haven't found a good way to determine whether or not adding more
> virtual memory to the instance would speed up queries or not. I think I
> might try to add another 128 MB just to see what happens. Also, I am
> thinking about adding some more BUFFERS but I am trying to be very
> cautious about not increasing my checkpoint times. From what I see
> right now, everything is performing really well and I don't really need
> to make any changes but you all might see something I don't. (I removed
> some of the onconfig file parameters to save a little space.)
>
> ONCONFIG PARAMETERS
>
> ROOTNAME a_rootdbs # Root dbspace name> ROOTPATH /dev/inf/chunk001 # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 500000 # Size of root dbspace (Kbytes)> PHYSDBS a_plogdbs # Location (dbspace) of physical log
> PHYSFILE 100000 # Physical log file size (Kbytes)
> LOGFILES 41 # Number of logical log files
> LOGSIZE 50000 # Logical log size (Kbytes)
> SERVERNUM 1 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME online_shm # Name of default database server
> DBSERVERALIASES online_tcp # List of alternate dbservernames
> NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
> NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
> DEADLOCK_TIMEOUT 240 # 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 5 # 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
> LOCKS 500000 # Maximum number of locks
> BUFFERS 155000 # Maximum number of shared buffers
> NUMAIOVPS 2 # Number of IO vps
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)
> CLEANERS 64 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shared memory base address
> SHMVIRTSIZE 1792000 # initial virtual shared memory segment> size
> SHMADD 256000 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> CKPTINTVL 600 # Check point interval (in sec)
> LRUS 64 # Number of LRU queues
> LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 64 # Stack size (Kbytes)
>
> DYNAMIC_LOGS 2
> LTXHWM 40
> LTXEHWM 55>
> # Read Ahead Variables
> RA_PAGES 20 # Number of pages to attempt to read> ahead
> RA_THRESHOLD 8 # Number of pages left before next group
>
> DBSPACETEMP> tempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
>
> FILLFACTOR 90 # Fill factor for building indexes>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority> #DS_MAX_QUERIES # Maximum number of decision support
> queries
> #DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
> OFF AFTER THE IMPORT
> DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN> THIS OFF AFTER THE IMPORT
> DS_MAX_SCANS 1048576 # Maximum number of decision support> scans
> DATASKIP off
> OPTCOMPIND 2 # To hint the optimizer
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
> OFF (0)
> ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
> ABORT, 2 = WAIT> OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
> # HETERO_COMMIT (Gateway participation in distributed transactions)
> # 1 => Heterogeneous Commit is enabled
> # 0 (or any other value) => Heterogeneous Commit is disabled
> HETERO_COMMIT 0
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarm> program path
> # Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
> OPT_GOAL -1
> ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or> anything but 1)
> BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
> DS_MAX_QUERIES 6 # Maximum number of decision support> queries
>
> ONSTAT -P
>
> IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
> 14:29:2
> 2 -- 2196484 Kbytes>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
> 87.17
>
> isamtot open start read write rewrite delete commit
> rollbk
> 12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
> 9953760 3
> 732
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 0 0 0 0 0 0 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 157714.53 101146.03 1047 2882
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 34018215 3531 16248413925 10 0 2150 3447796
> 2746919
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 137210564 13433495 105455888 253872383 7973596
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Robert Roussey(IT)
> Sent: Wednesday, May 02, 2007 5:14 PM
> To: ids@iiug.org
> Subject: RE: Question on SHMVIRTSIZE [9061]
>
> If you know the session of the batch job, you can see what pieces of
> memory it is using with "onstat -g mem".
> "onstat -g ses" will show all sessions and their total use of SHM.
> If you are using PDQ for the batch job, you should see it reflected by
> getting snapshots of "onstat -g mgm" while it is running.
>
> Maybe post your ONCONFIG file and people can comment on it as well a
My rule of thumb for BTR is single digits. Six or lower is fine for most OLTP
but even 8 or 9 is good. When I see 12 or higher the server is noticably
slowed.
Art S. Kagel
----- Original Message -----
From: DL Redden <ids@iiug.org>
At: 5/17 18:10:42
Art,
What is a respectable BTR? I know that it depends but do you, or anyone else
for that matter, have any rules of thumb that make you start to worry on say a
primarily OLTP instance and a primarily OLAP instance?
Thanks,
DL
----- Original Message ----
From: "ART KAGEL, BLOOMBERG/ 731 LEXIN" <kagel@bloomberg.net>
To: ids@iiug.org
Sent: Monday, May 14, 2007 11:29:04 AM
Subject: Re: Question on SHMVIRTSIZE [9144]
Your metrics indicate that you MAY need more BUFFERS:
BR = (34018215 / (243924199 + 1308089992)) * 100.00 = 2.1900
BTR = (((243924199 + 1308089992) / 155000) / 110.5) = 90.6153
RAU = (253872383/(137210564+13433495+105455888)) * 100.00 = 99.1300
The BTR of 90.6 is VERY high. You are turning over your entire buffer pool
every 39.7 seconds (or at least thrashing some subset many times a minute)! I
would take that 128MB you want to add to the virtual memory pool and use it
and
more to add another 150000 buffers. You can fine tune that by monitoring
onstat-P over time to determine the actual number of buffers being thrashed
(probably
it's a small number of tables that are highly active and are perpetually
forcing each other's pages out of the cache).
Art S. Kagel
----- Original Message -----
From: Keith Simmons <ids@iiug.org>
At: 5/09 5:14:22
On 08/05/07, Mary Gregory <mary.gregory@rheem.com> wrote:
> I still haven't found a good way to determine whether or not adding more
> virtual memory to the instance would speed up queries or not. I think I
> might try to add another 128 MB just to see what happens. Also, I am
> thinking about adding some more BUFFERS but I am trying to be very
> cautious about not increasing my checkpoint times. From what I see
> right now, everything is performing really well and I don't really need
> to make any changes but you all might see something I don't. (I removed
> some of the onconfig file parameters to save a little space.)
>
> ONCONFIG PARAMETERS
>
> ROOTNAME a_rootdbs # Root dbspace name> ROOTPATH /dev/inf/chunk001 # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 500000 # Size of root dbspace (Kbytes)> PHYSDBS a_plogdbs # Location (dbspace) of physical log
> PHYSFILE 100000 # Physical log file size (Kbytes)
> LOGFILES 41 # Number of logical log files
> LOGSIZE 50000 # Logical log size (Kbytes)
> SERVERNUM 1 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME online_shm # Name of default database server
> DBSERVERALIASES online_tcp # List of alternate dbservernames
> NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
> NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
> DEADLOCK_TIMEOUT 240 # 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 5 # 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
> LOCKS 500000 # Maximum number of locks
> BUFFERS 155000 # Maximum number of shared buffers
> NUMAIOVPS 2 # Number of IO vps
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)
> CLEANERS 64 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shared memory base address
> SHMVIRTSIZE 1792000 # initial virtual shared memory segment> size
> SHMADD 256000 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> CKPTINTVL 600 # Check point interval (in sec)
> LRUS 64 # Number of LRU queues
> LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 64 # Stack size (Kbytes)
>
> DYNAMIC_LOGS 2
> LTXHWM 40
> LTXEHWM 55>
> # Read Ahead Variables
> RA_PAGES 20 # Number of pages to attempt to read> ahead
> RA_THRESHOLD 8 # Number of pages left before next group
>
> DBSPACETEMP> tempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
>
> FILLFACTOR 90 # Fill factor for building indexes>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority> #DS_MAX_QUERIES # Maximum number of decision support
> queries
> #DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
> OFF AFTER THE IMPORT
> DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN> THIS OFF AFTER THE IMPORT
> DS_MAX_SCANS 1048576 # Maximum number of decision support> scans
> DATASKIP off
> OPTCOMPIND 2 # To hint the optimizer
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
> OFF (0)
> ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
> ABORT, 2 = WAIT> OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
> # HETERO_COMMIT (Gateway participation in distributed transactions)
> # 1 => Heterogeneous Commit is enabled
> # 0 (or any other value) => Heterogeneous Commit is disabled
> HETERO_COMMIT 0
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarm> program path
> # Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
> OPT_GOAL -1
> ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or> anything but 1)
> BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
> DS_MAX_QUERIES 6 # Maximum number of decision support> queries
>
> ONSTAT -P
>
> IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
> 14:29:2
> 2 -- 2196484 Kbytes>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
> 87.17
>
> isamtot open start read write rewrite delete commit
> rollbk
> 12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
> 9953760 3
> 732
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 0 0 0 0 0 0 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 157714.53 101146.03 1047 2882
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 34018215 3531 16248413925 10 0 2150 3447796
> 2746919
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 137210564 13433495 105455888 253872383 7973596
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Robert Roussey(IT)
> Sent: Wednesday, May 02, 2007 5:14 PM
> To: ids@iiug.org
> Subject: RE: Question on SHMVIRTSIZE [9061]
>
> If you know the session of the batch job, you can see what pieces of
> memory it is using with "onstat -g mem".
> "onstat -g
So, I increased BUFFERS to 200000, LRUS and CLEANERS to 127. Read-cache
percent has gone down from 96% to 92%. Does this tell me that I again
need to add more BUFFERS, or I have passed the point of diminishing
returns and I should reduce the number of BUFFERS?
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
ART KAGEL, BLOOMBERG/ 731 LEXIN
Sent: Monday, May 14, 2007 11:29 AM
To: ids@iiug.org
Subject: Re: Question on SHMVIRTSIZE [9144]
Your metrics indicate that you MAY need more BUFFERS:
BR = (34018215 / (243924199 + 1308089992)) * 100.00 = 2.1900
BTR = (((243924199 + 1308089992) / 155000) / 110.5) = 90.6153
RAU = (253872383/(137210564+13433495+105455888)) * 100.00 = 99.1300
The BTR of 90.6 is VERY high. You are turning over your entire buffer
pool
every 39.7 seconds (or at least thrashing some subset many times a
minute)! I
would take that 128MB you want to add to the virtual memory pool and use
it
and
more to add another 150000 buffers. You can fine tune that by monitoring
onstat-P over time to determine the actual number of buffers being thrashed
(probably
it's a small number of tables that are highly active and are perpetually
forcing each other's pages out of the cache).
Art S. Kagel
----- Original Message -----
From: Keith Simmons <ids@iiug.org>
At: 5/09 5:14:22
On 08/05/07, Mary Gregory <mary.gregory@rheem.com> wrote:
> I still haven't found a good way to determine whether or not adding
more
> virtual memory to the instance would speed up queries or not. I think
I
> might try to add another 128 MB just to see what happens. Also, I am
> thinking about adding some more BUFFERS but I am trying to be very
> cautious about not increasing my checkpoint times. From what I see
> right now, everything is performing really well and I don't really
need
> to make any changes but you all might see something I don't. (I
removed
> some of the onconfig file parameters to save a little space.)
>
> ONCONFIG PARAMETERS
>
> ROOTNAME a_rootdbs # Root dbspace name> ROOTPATH /dev/inf/chunk001 # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 500000 # Size of root dbspace (Kbytes)> PHYSDBS a_plogdbs # Location (dbspace) of physical log
> PHYSFILE 100000 # Physical log file size (Kbytes)
> LOGFILES 41 # Number of logical log files
> LOGSIZE 50000 # Logical log size (Kbytes)
> SERVERNUM 1 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME online_shm # Name of default database server
> DBSERVERALIASES online_tcp # List of alternate dbservernames
> NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
> NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
> DEADLOCK_TIMEOUT 240 # 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 5 # 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
> LOCKS 500000 # Maximum number of locks
> BUFFERS 155000 # Maximum number of shared buffers
> NUMAIOVPS 2 # Number of IO vps
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)
> CLEANERS 64 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shared memory base address
> SHMVIRTSIZE 1792000 # initial virtual shared memory segment> size
> SHMADD 256000 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> CKPTINTVL 600 # Check point interval (in sec)
> LRUS 64 # Number of LRU queues
> LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 64 # Stack size (Kbytes)
>
> DYNAMIC_LOGS 2
> LTXHWM 40
> LTXEHWM 55>
> # Read Ahead Variables
> RA_PAGES 20 # Number of pages to attempt to read> ahead
> RA_THRESHOLD 8 # Number of pages left before next group
>
> DBSPACETEMP> tempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
>
> FILLFACTOR 90 # Fill factor for building indexes>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority> #DS_MAX_QUERIES # Maximum number of decision support
> queries
> #DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
> OFF AFTER THE IMPORT
> DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN> THIS OFF AFTER THE IMPORT
> DS_MAX_SCANS 1048576 # Maximum number of decision support> scans
> DATASKIP off
> OPTCOMPIND 2 # To hint the optimizer
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
> OFF (0)
> ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
> ABORT, 2 = WAIT> OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
> # HETERO_COMMIT (Gateway participation in distributed transactions)
> # 1 => Heterogeneous Commit is enabled
> # 0 (or any other value) => Heterogeneous Commit is disabled
> HETERO_COMMIT 0
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarm> program path
> # Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
> OPT_GOAL -1
> ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or> anything but 1)
> BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
> DS_MAX_QUERIES 6 # Maximum number of decision support> queries
>
> ONSTAT -P
>
> IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
> 14:29:2
> 2 -- 2196484 Kbytes>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
> 87.17
>
> isamtot open start read write rewrite delete commit
> rollbk
> 12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
> 9953760 3
> 732
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 0 0 0 0 0 0 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 157714.53 101146.03 1047 2882
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 34018215 3531 16248413925 10 0 2150 3447796
> 2746919
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 137210564 13433495 105455888 253872383 7973596
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Robert Roussey(IT)
> Sent: Wednesday, May 02, 2007 5:14 PM
> To: ids@iiug.org
> Subject: RE: Question on SHMVIRTSIZE [9061]
>
> If you know the session of the batch job, you can see what pieces of
> memory it is using with "onstat -g mem".
> "onstat -g ses" will show all sessions and their total use of SHM.
> If you are using PDQ for the batch job, you should see it reflected by
> getting snapshots of "onstat -g mgm" while it is r
Cache% went down slightly because the increased number of active dirty buffers
(instead of thrashing 50000 buffers you're now modifying 80000 buffers) has
increased the LRU flush rate. If your checkpoints are fast, increase the
LRU_MIN/MAX_DIRTY settings slightly if you want the cache rate back up, but 92%
is not bad at all and making this change may cause longer checkpoints (IDS
11.10 - Cheetah will solve this one finally). Check your metrics again, if they
are better don't worry about it. How's performance overall?
Art S. Kagel
----- Original Message -----
From: Mary Gregory <ids@iiug.org>
At: 5/21 10:07:06
So, I increased BUFFERS to 200000, LRUS and CLEANERS to 127. Read-cache
percent has gone down from 96% to 92%. Does this tell me that I again
need to add more BUFFERS, or I have passed the point of diminishing
returns and I should reduce the number of BUFFERS?
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
ART KAGEL, BLOOMBERG/ 731 LEXIN
Sent: Monday, May 14, 2007 11:29 AM
To: ids@iiug.org
Subject: Re: Question on SHMVIRTSIZE [9144]
Your metrics indicate that you MAY need more BUFFERS:
BR = (34018215 / (243924199 + 1308089992)) * 100.00 = 2.1900
BTR = (((243924199 + 1308089992) / 155000) / 110.5) = 90.6153
RAU = (253872383/(137210564+13433495+105455888)) * 100.00 = 99.1300
The BTR of 90.6 is VERY high. You are turning over your entire buffer
pool
every 39.7 seconds (or at least thrashing some subset many times a
minute)! I
would take that 128MB you want to add to the virtual memory pool and use
it
and
more to add another 150000 buffers. You can fine tune that by monitoring
onstat-P over time to determine the actual number of buffers being thrashed
(probably
it's a small number of tables that are highly active and are perpetually
forcing each other's pages out of the cache).
Art S. Kagel
----- Original Message -----
From: Keith Simmons <ids@iiug.org>
At: 5/09 5:14:22
On 08/05/07, Mary Gregory <mary.gregory@rheem.com> wrote:
> I still haven't found a good way to determine whether or not adding
more
> virtual memory to the instance would speed up queries or not. I think
I
> might try to add another 128 MB just to see what happens. Also, I am
> thinking about adding some more BUFFERS but I am trying to be very
> cautious about not increasing my checkpoint times. From what I see
> right now, everything is performing really well and I don't really
need
> to make any changes but you all might see something I don't. (I
removed
> some of the onconfig file parameters to save a little space.)
>
> ONCONFIG PARAMETERS
>
> ROOTNAME a_rootdbs # Root dbspace name> ROOTPATH /dev/inf/chunk001 # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 500000 # Size of root dbspace (Kbytes)> PHYSDBS a_plogdbs # Location (dbspace) of physical log
> PHYSFILE 100000 # Physical log file size (Kbytes)
> LOGFILES 41 # Number of logical log files
> LOGSIZE 50000 # Logical log size (Kbytes)
> SERVERNUM 1 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME online_shm # Name of default database server
> DBSERVERALIASES online_tcp # List of alternate dbservernames
> NETTYPE ipcshm,3,75,CPU # Configure poll thread(s) for nettype
> NETTYPE soctcp,6,200,NET # Configure poll thread(s) for nettype
> DEADLOCK_TIMEOUT 240 # 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 5 # 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
> LOCKS 500000 # Maximum number of locks
> BUFFERS 155000 # Maximum number of shared buffers
> NUMAIOVPS 2 # Number of IO vps
> PHYSBUFF 64 # Physical log buffer size (Kbytes)
> LOGBUFF 64 # Logical log buffer size (Kbytes)
> CLEANERS 64 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shared memory base address
> SHMVIRTSIZE 1792000 # initial virtual shared memory segment> size
> SHMADD 256000 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> CKPTINTVL 600 # Check point interval (in sec)
> LRUS 64 # Number of LRU queues
> LRU_MAX_DIRTY 4.000 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 2.000 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 64 # Stack size (Kbytes)
>
> DYNAMIC_LOGS 2
> LTXHWM 40
> LTXEHWM 55>
> # Read Ahead Variables
> RA_PAGES 20 # Number of pages to attempt to read> ahead
> RA_THRESHOLD 8 # Number of pages left before next group
>
> DBSPACETEMP> tempdbs1,tempdbs2,tempdbs3,tempdbs4,tempdbs5,tempdbs6,tempdbs7
>
> FILLFACTOR 90 # Fill factor for building indexes>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 0 # Maximum allowed pdqpriority> #DS_MAX_QUERIES # Maximum number of decision support
> queries
> #DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN THIS
> OFF AFTER THE IMPORT
> DS_TOTAL_MEMORY # Decision support memory (Kbytes) TURN> THIS OFF AFTER THE IMPORT
> DS_MAX_SCANS 1048576 # Maximum number of decision support> scans
> DATASKIP off
> OPTCOMPIND 2 # To hint the optimizer
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or
> OFF (0)
> ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 =
> ABORT, 2 = WAIT> OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
> # HETERO_COMMIT (Gateway participation in distributed transactions)
> # 1 => Heterogeneous Commit is enabled
> # 0 (or any other value) => Heterogeneous Commit is disabled
> HETERO_COMMIT 0
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /home/informix/9.40/etc/evidence.sh # System Alarm> program path
> # Optimization goal: -1 = ALL_ROWS(Default), 0 = FIRST_ROWS
> OPT_GOAL -1
> ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or> anything but 1)
> BAR_BSALIB_PATH /opt/omni/lib/libob2informix_64bit.sl
> DS_MAX_QUERIES 6 # Maximum number of decision support> queries
>
> ONSTAT -P
>
> IBM Informix Dynamic Server Version 9.40.FC4 -- On-Line -- Up 4 days
> 14:29:2
> 2 -- 2196484 Kbytes>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 535710112 1308089992 17065711597 96.86 31296277 73506490 243924199
> 87.17
>
> isamtot open start read write rewrite delete commit
> rollbk
> 12889143879 61483810 410801398 10058850470 60258603 10476107 6562628
> 9953760 3
> 732
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 0 0 0 0 0 0 0
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 157714.53 101146.03 1047 2882
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
> 34018215 3531 16248413925 10 0 2150 3447796
> 2746919
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 137