RE: ONCONFIG for 9.40 offered for comment
after we upgraded to 9.4, we also experienced slowness in few of the
queries, we had to modify the queries to speed it up, few of the changes
what we did are
1) after examining the explain plan, we found some queries were doing
sequential scan in 9.4, had to create few indexes to speed it up.
2) in some instances use_hash optimizer directives was slowing down the
query, had to just remove the hint from the query
3) A query that had a 11 table join has to be re-written.
but, overall we experienced some performance gain (may be around 5%)
-----Original Message-----
From: owner-informix-list@iiug.org
[mailto:owner-informix-list@iiug.org]On Behalf Of Neil Truby
Sent: Wednesday, June 16, 2004 4:13 PM
To: informix-list@iiug.org
Subject: Re: ONCONFIG for 9.40 offered for comment
Thanks. Chaning OPTCOMPIND on a live system would be a brave move I'd have
thought, in the sense that a decision to invite a professional liability
lawsuit is "brave"!
Not sure what TBLSPACE_STATS does, but Andrew Hamm also suggested it so I'll
RTFM ...
This is an oltp system - I should have said - so hopefully not a lot of call
for PDQ.
thanks for your interest - keep 'em coming. I mean, it couldn;t just be
that 9.40 is just slower, could it? I read in some marketing literature
that it's 15% faster ...
cheers
Neil
"Savio Pinto (s)" <spinto@cap.org> wrote in message
news:caq60t$qvm$1@news.xmission.com...
>
> what about....
> 1. setting OPTCOMPIND to 2 instead of 0
> 2. set TBLSPACE_STATS to 0
> 3. may need to increase DS_TOTAL_MEMORY, if you are using PDQ
> 4. fyi, LTXHWM & LTXEHWM need not be set if DYNAMIC_LOGS is set in the
> ONCONFIG
>
> -----Original Message-----
> From: owner-informix-list@iiug.org
> [mailto:owner-informix-list@iiug.org]On Behalf Of Neil Truby
> Sent: Wednesday, June 16, 2004 12:01 AM
> To: informix-list@iiug.org
> Subject: ONCONFIG for 9.40 offered for comment
>
>
> 9.40 FC3W2 on HP-UX 11.11
> The server has 6 cpus and 6G of RAM.
> 3 other, small, IDS 9.40 instances run on the server, and one small 7.31.
> kaio is enabled.
>
> Just put 9.40 live, and it's running about 5-10% more slowly on some key
> processes. This reflects what happened in testing. In particular we seem
to
> be having fun and games with the new BTscanners. I thought I'd post the
> ONCONFIG for comment - any and all gratefully received!
>
> thanks
> Neil
>
> P.S. We know we'll have to increase SHMVIRTSIZE, as full-throttle BT
> scanning breaks out more segments ...
>
>
#**************************************************************************
> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: Onconfig for instance 1
>
> # Description: INFORMIX-OnLine Configuration Parameters
> #
>
#**************************************************************************
>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name> ROOTPATH /opt/informixV7.13/dbspaces1/rootdbs
> # Note from Neil - before my time!!!!!
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 131072 # Size of root dbspace (Kbytes)>
> # Disk Mirroring Configuration Parameters
>
> MIRROROFFSET 0 # Offset into mirrored device (Kbytes)>
> # Physical Log Configuration
>
> PHYSDBS physlog # Location (dbspace) of physical log
> PHYSFILE 80000 # Physical log file size (Kbytes)>
> # Logical Log Configuration
>
> LOGFILES 50 # Number of logical log files
> LOGSIZE 10240 # Logical log size (Kbytes)>
> # Diagnostics
>
> MSGPATH /opt/informix/online_1.log # System message log file path
> CONSOLE /opt/informix/online_1.con # System console message path
> ALARMPROGRAM /opt/informix/9.40/etc/log_full.sh # Alarm program path
>
> # System Archive Tape Device
>
> TAPEDEV /opt/informixV7.13/dbspaces1/tapedev
> TAPEDEV /dev/null
> TAPEBLK 64 # Tape block size (Kbytes)
> TAPESIZE 40960000 # Maximum amount of data to put on tape
> (Kbytes)>
> # Log Archive Tape Device
>
> LTAPEDEV /opt/informixV7.13/dbspaces1/ltapedev # Log tape device
path
> LTAPEBLK 16 # Log tape block size (Kbytes)
> LTAPESIZE 8192000 # Max amount of data to put on log tape
> (Kbytes)>
> # Optical
>
> STAGEBLOB # INFORMIX-OnLine/Optical staging area
>
> # System Configuration
>
> SERVERNUM 1 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME lawson_live_shm # Name of default database server
> DBSERVERALIASES
> lawson_live,ifx_tcp_2,cats,bo_data,datastore,lawson,lawson_live_soc
> DEADLOCK_TIMEOUT 120 # 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 3 # Number of user (cpu) vps
> SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to> one
>
> NOAGE 1 # Process aging
> AFF_SPROC 0 # Affinity start processor
> AFF_NPROCS 0 # Affinity number of processors>
> # Shared Memory Parameters
>
> LOCKS 2000000 # Maximum number of locks
> BUFFERS 375000 # Maximum number of shared buffers
> NUMAIOVPS 3 # Number of IO vps> #NUMAIOVPS 127 # Changed with upgrade to 9.40 as usingn
> KAIO instead
> PHYSBUFF 256 # Physical log buffer size (Kbytes)
> LOGBUFF 128 # Logical log buffer size (Kbytes)> LOGSMAX 150 # Maximum number of logical log files
> CLEANERS 65 # Number of buffer cleaner processes
> SHMBASE 0x0 # Shared memory base address
> SHMVIRTSIZE 320768 # initial virtual shared memory segmentsize
> SHMADD 16384 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
> CKPTINTVL 900 # Check point interval (in sec)
> LRUS 65 # Number of LRU queues
> LRU_MAX_DIRTY 4 # LRU percent dirty begin cleaning limit
> LRU_MIN_DIRTY 2 # 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 128 # 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