Ask a Question related to Informix, Design and Development.
-
Hari Gupta #1
High lngspins - IDS 9.30 UC2
Hi All,
We have recently upgraded IDS 9.21UC3 to IDS 9.30 UC3 on RHL 7.3
(Kernel - 2.4.18-27.7.xbigmem). Platform - Dell PE6600 - Quard Xeon,
dual channel, 8GB RAM - HT. Channel-A has 8 72 GB mirror & stripped
and Channel-B has got 8 36 GB mirror & stripped.
I have been keeping an eye on the database performance and constantly
observing that lngspins are keeps on growing. Within 2 days of
running,
lngspins gone upto more than 21000. Also notice high seqscans.
So far as seqscans are concern, probably they have been there with
IDS 9.21 UC3 as well.
Could some one pl. advise ? Ofcourse - I am sure gurus like Art, Mark
D,
Bill, Obnoxio, J Leffler, J Parker, Tsutomu and manu more will respond
to it.
Details of following onstats are as below:
1. onstat -g glo
2. onstat -p
3. onstat -P
4. onstat -d
5. onstat -c
6. onstat -g iov
7. onstat -D
8. onstat -R
9. onstat -F
10. onstat -g seg
[Live:auth->authprog] onstat -g glo
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
18:00:33 -- 1366176 Kbytes
MT global info:
sessions threads vps lngspins
374 560 31 21430
sched calls thread switches yield 0 yield n yield
forever
total: 3927615459 560654618 3584329234 1861444
24375989
per sec: 12 12 0 0 6
Virtual processor summary:
class vps usercpu syscpu total
cpu 3 41233.15 1459.49 42692.64
aio 22 519.91 1952.60 2472.51
lio 1 8.67 44.62 53.29
pio 1 0.60 4.44 5.04
adm 1 4.75 37.75 42.50
soc 2 201.84 1638.10 1839.94
msc 1 68.18 21.72 89.90
total 31 42037.10 5158.72 47195.82
Individual virtual processors:
vp pid class usercpu syscpu total
1 29700 cpu 13548.51 626.85 14175.36
2 29701 adm 4.75 37.75 42.50
3 29702 cpu 15078.50 525.08 15603.58
4 29703 cpu 12606.14 307.56 12913.70
5 29704 lio 8.67 44.62 53.29
6 29705 pio 0.60 4.44 5.04
7 29706 aio 39.97 260.47 300.44
8 29707 msc 68.18 21.72 89.90
9 29708 aio 34.73 130.95 165.68
10 29709 aio 31.28 120.36 151.64
11 29710 aio 29.22 111.09 140.31
12 29711 aio 27.27 105.32 132.59
13 29712 aio 26.18 100.10 126.28
14 29713 aio 24.68 89.16 113.84
15 29714 aio 24.03 87.30 111.33
16 29715 aio 22.70 79.68 102.38
17 29716 aio 22.51 77.28 99.79
18 29717 aio 21.54 75.55 97.09
21 29718 aio 20.47 70.15 90.62
19 29719 aio 21.73 72.90 94.63
23 29720 aio 20.04 66.33 86.37
22 29721 aio 19.92 68.04 87.96
25 29722 aio 19.13 64.25 83.38
20 29723 aio 21.04 71.05 92.09
27 29724 aio 18.07 59.51 77.58
24 29725 aio 19.70 64.01 83.71
29 29726 aio 18.55 58.39 76.94
26 29727 aio 18.79 61.72 80.51
28 29728 aio 18.37 59.00 77.37
30 29729 soc 87.05 702.88 789.93
31 29730 soc 114.82 935.60 1050.42
tot 42040.38 5159.23 47199.61
-----------------------------------------------------------
[Live:auth->authprog] onstat -p
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
17:59:01 -- 1366176 Kbytes
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
43056847 125882631 3355831614 98.72 2009883 11470076 12282452 83.64
isamtot open start read write rewrite delete commit
rollbk
2526616592 27179056 150978314 1927954589 3255094 191668 189745
651309 34
gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
4278 1252 14560 740 0 0 17
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 42021.58 5157.48 246 770
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress
seqscans
1809524 1 2554621970 0 0 271 546021
1042972
ixda-RA idx-RA da-RA RA-pgsused lchwaits
6932524 1128570 24853036 32904007 3401049
------------------------------------------------------------
[Live:auth->authprog] onstat -P | tail -5
Percentages:
Data 83.06
Btree 15.87
Other 1.07
------------------------------------------------------------
[Live:auth->authprog] onstat -d
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
18:04:47 -- 1366176 Kbytes
Dbspaces
address number flags fchunk nchunks flags owner name
788a07d8 1 0x1001 1 1 N informix
rootdbs
7986a018 2 0x1 2 1 N informix
plogdbs
7986a168 3 0x1 3 1 N informix
llogdbs
7986a2b8 4 0x1 4 1 N informix
tmpndbs
7986a408 5 0x2001 5 1 N T informix
tmptdbs
7986a558 6 0x1 6 16 N informix
maindbs
7986a6a8 7 0x8001 22 1 N S informix
sndqdbs
7 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
788a0928 1 1 0 256000 198196 PO-
/IFMXDATA/authlive/rootdbs
798430a0 2 2 0 256000 5947 PO-
/IFMXDATA/authlive/plogdbs
79843210 3 3 0 512000 69579 PO-
/IFMXDATA/authlive/llogdbs
79843380 4 4 0 1024000 1023947 PO-
/IFMXDATA/authlive/tmpndbs
798434f0 5 5 0 1024000 1015460 PO-
/IFMXDATA/authlive/tmptdbs
79843660 6 6 0 1024000 7 PO-
/IFMXDATA/authlive/maindbs01
798437d0 7 6 0 1024000 0 PO-
/IFMXDATA/authlive/maindbs02
79843940 8 6 0 1024000 45 PO-
/IFMXDATA/authlive/maindbs03
79843ab0 9 6 0 1024000 17 PO-
/IFMXDATA/authlive/maindbs04
79843c20 10 6 0 1024000 4 PO-
/IFMXDATA/authlive/maindbs05
79843d90 11 6 0 1024000 2 PO-
/IFMXDATA/authlive/maindbs06
79869018 12 6 0 1024000 8 PO-
/IFMXDATA/authlive/maindbs07
79869188 13 6 0 1024000 12 PO-
/IFMXDATA/authlive/maindbs08
798692f8 14 6 0 1024000 99537 PO-
/IFMXDATA/authlive/maindbs09
79869468 15 6 0 1024000 540241 PO-
/IFMXDATA/authlive/maindbs10
798695d8 16 6 0 1024000 1023997 PO-
/IFMXDATA/authlive/maindbs11
79869748 17 6 0 1024000 1023997 PO-
/IFMXDATA/authlive/maindbs12
798698b8 18 6 0 1024000 1023997 PO-
/IFMXDATA/authlive/maindbs13
79869a28 19 6 0 1024000 1023997 PO-
/IFMXDATA/authlive/maindbs14
79869b98 20 6 0 1024000 1023997 PO-
/IFMXDATA/authlive/maindbs15
79869d08 21 6 0 1024000 1023997 PO-
/IFMXDATA/authlive/maindbs16
79869e78 22 7 0 1048575 979092 979093 POS
/IFMXDATA/authlive/sndqdbs
Metadata 69429 52508 69429
22 active, 2047 maximum
---------------------------------------------------------------------------------------------
[Live:auth->authprog] onstat -c
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
18:05:45 -- 1366176 Kbytes
Configuration File: /usr/informix/etc/onconfig.authlive
#************************************************* *************************
#
# INFORMIX SOFTWARE, INC.
#
# Title: onconfig.authlive.normalrunning
# Description: Informix Dynamic Server Configuration Parameters
# Use this as the base configuration file for a quad
# hyper-threaded P4 server with 2 gig or more of ram
#
#************************************************* *************************
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTPATH /IFMXDATA/authlive/rootdbs
# Path for device containing root
dbspace
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)
ROOTSIZE 512000 # Size of root dbspace (Kbytes)
# Disk Mirroring Configuration Parameters
MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored
root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
# Physical Log Configuration
PHYSDBS plogdbs # Location (dbspace) of physical log
PHYSFILE 500000 # Physical log file size (Kbytes)
# Logical Log Configuration
LOGFILES 60 # Number of logical log files
LOGSIZE 16384 # Logical log size (Kbytes)
# Diagnostics
MSGPATH /var/log/informix/authlive.log # System message log
file path
CONSOLE /dev/console # System console message path
ALARMPROGRAM /usr/informix/etc/no_log.sh # Alarm program path
TBLSPACE_STATS 1 # Maintain tblspace statistics
# System Archive Tape Device
#TAPEDEV /dev/null # Tape device path
TAPEDEV /dev/st0 # Tape device path
TAPEBLK 736 # Tape block size (Kbytes)
TAPESIZE 102400000 # Maximum amount of data to put on
tape (Kbytes)
# Log Archive Tape Device
#LTAPEDEV /dev/null # Log tape device path
LTAPEDEV /dev/st0 # Log tape device path
LTAPEBLK 512 # Log tape block size (Kbytes)
LTAPESIZE 20971520 # Max amount of data to put on log
tape (Kbytes)
#LTAPESIZE 10240000 # Max amount of data to put on log
tape (Kbytes)
# Optical
STAGEBLOB # Informix Dynamic Server staging area
# System Configuration
SERVERNUM 5 # Unique id corresponding to a OnLine
instance
DBSERVERNAME authlive # Name of default database server
DBSERVERALIASES authlive_shm # List of alternate dbservernames
NETTYPE soctcp,2,150,NET # Configure poll thread(s) for
nettype
NETTYPE ipcshm,2,300,CPU # Configure poll thread(s) for
nettype
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in
distributed env.
RESIDENT -1 # Forced residency flag (Yes = 1, No =
0)
MULTIPROCESSOR 1 # 0 for single-processor, 1 for
multi-processor
NUMCPUVPS 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 100000 # Maximum number of locks
BUFFERS 400000 # Maximum number of shared buffers
NUMAIOVPS 22 # Number of IO vps
PHYSBUFF 256 # Physical log buffer size (Kbytes)
LOGBUFF 256 # Logical log buffer size (Kbytes)
CLEANERS 128 # Number of buffer cleaner processes
SHMBASE 0x44000000L # Shared memory base address
SHMVIRTSIZE 500000 # initial virtual shared memory
segment size
SHMADD 100000 # Size of new shared memory segments
(Kbytes)
### SHMVIRTSIZE 1000000 # initial virtual shared memory
segment size
### SHMADD 200000 # Size of new shared memory
segments (Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 900 # Check point interval (in sec)
LRUS 128 # Number of LRU queues
LRU_MAX_DIRTY 3 # LRU percent dirty begin cleaning
limit
LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 32 # Stack size (Kbytes)
DD_HASHSIZE 501 # No. of slots in dictionary (should
be prime number)
DD_HASHMAX 4 # Max number of tables in slot
# Dynamic Logging
# DYNAMIC_LOGS:
# 2 : server automatically add a new logical log when necessary.
(ON)
# 1 : notify DBA to add new logical logs when necessary. (ON)
# 0 : cannot add logical log on the fly. (OFF)
#
# When dynamic logging is on, we can have higher values for
LTXHWM/LTXEHWM,
# because the server can add new logical logs during long transaction
rollback.
# However, to limit the number of new logical logs being added,
LTXHWM/LTXEHWM
# can be set to smaller values.
#
# If dynamic logging is off, LTXHWM/LTXEHWM NEED to be set to smaller
values
# to avoid long transaction rollback hanging the server due to lack of
logical
# log space, i.e. 50/60 or lower.
DYNAMIC_LOGS 1
LTXHWM 70
LTXEHWM 80
# 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
DRINTERVAL 30 # DR max time between DR buffer
flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /usr/informix/etc/dr.lostfound # DR lost+found file
path
# CDR Variables
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 (Kbytes)
CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0
none, 9 max)
CDR_SERIAL 0,0 # Serial Column Sequence
CDR_DBSPACE # dbspace for syscdr database
CDR_QHDR_DBSPACE # CDR queue dbspace (default same as
catalog)
CDR_QDATA_SBSPACE sndqdbs # CDR queue smart blob space
CDR_QDATA_SBFLAGS 0 # Log/no-log (default no log)
# Backup/Restore variables
BAR_ACT_LOG /usr/informix/bar_act.log # ON-Bar Log file - not in
/tmp please
BAR_DEBUG_LOG /usr/informix/bar_dbug.log # ON-Bar Debug Log - not in
/tmp please
BAR_MAX_BACKUP 0
BAR_RETRY 1
BAR_NB_XPORT_COUNT 10
BAR_XFER_BUF_SIZE 31
RESTARTABLE_RESTORE on
BAR_PROGRESS_FREQ 0
# Informix Storage Manager variables
ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs
# Read Ahead Variables
RA_PAGES 128 # Number of pages to attempt to read
ahead
RA_THRESHOLD 100 # Number of pages left before next
group
# DBSPACETEMP:
# OnLine equivalent of DBTEMP for SE. This is the list of dbspaces
# that the OnLine SQL Engine will use to create temp tables etc.
# If specified it must be a colon separated list of dbspaces that
exist
# when the OnLine system is brought online. If not specified, or if
# all dbspaces specified are invalid, various ad hoc queries will
create
# temporary files in /tmp instead.
#DBSPACETEMP tmptdbs,tmpndbs # Default temp dbspaces
DBSPACETEMP tmptdbs # Default temp dbspaces
# DUMP*:
# The following parameters control the type of diagnostics information
which
# is preserved when an unanticipated error condition (assertion
failure) occurs
# during OnLine operations.
# For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
DUMPDIR /tmp # Preserve diagnostics in this
directory
DUMPSHMEM 0 # Dump a copy of shared memory
DUMPGCORE 0 # Dump a core image using 'gcore'
DUMPCORE 0 # Dump a core image (Warning:this
aborts OnLine)
DUMPCNT 1 # Number of shared memory or gcore
dumps for
# a single user's session
FILLFACTOR 90 # Fill factor for building indexes
# method for OnLine to use when determining current time
USEOSTIME 0 # 0: use internal time(fast), 1: get
time from OS(slow)
# Parallel Database Queries (pdq)
MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
DS_MAX_QUERIES 8 # Maximum number of decision support
queries
DS_TOTAL_MEMORY # Decision support memory (Kbytes)
DS_MAX_SCANS 1048576 # Maximum number of decision support
scans
DATASKIP off
# OPTCOMPIND
# 0 => Nested loop joins will be preferred (where
# possible) over sortmerge joins and hash joins.
# 1 => If the transaction isolation mode is not
# "repeatable read", optimizer behaves as in (2)
# below. Otherwise it behaves as in (0) above.
# 2 => Use costs regardless of the transaction isolation
# mode. Nested loop joins are not necessarily
# preferred. Optimizer bases its decision purely
# on costs.
OPTCOMPIND 2 # To hint the optimizer
DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default)
or OFF (0)
ONDBSPACEDOWN 1 # 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
SBSPACENAME # Default smartblob space name - this
is where blobs
# go if no sbspace is specified when
the smartblob is
# created. It is also used by some
datablades as
# the location to put their
smartblobs.
SYSSBSPACENAME # Default smartblob space for use by
the Informix
# Server. This is used primarily for
Informix Server
# system statistics collection.
BLOCKTIMEOUT 3600 # Default timeout for system block
SYSALARMPROGRAM /usr/informix/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)
#
# The following are default settings for enabling Java in the
database.
# Replace all occurrences of /usr/informix with the value of
$INFORMIXDIR.
#VPCLASS jvp,num=1 # Number of JVPs to start with
JVPJAVAHOME /usr/informix/extend/krakatoa/jre
# JRE installation root directory
JVPHOME /usr/informix/extend/krakatoa # Krakatoa installation
directory
JVPPROPFILE /usr/informix/extend/krakatoa/.jvpprops # JVP property
file
JVPLOGFILE /usr/informix/jvp.log # JVP log file.
JDKVERSION 1.3 # JDK version supported by this server
# The path to the JRE libraries relative to JVPJAVAHOME
JVPJAVALIB /lib/i386/
# The JRE libraries to use for the Java VM
JVPJAVAVM hpi:server:verify:java:net:zip:jpeg
# use JVPARGS to change Java VM configuration
#To display jni call
#JVPARGS -verbose:jni
# Classpath to use upon Java VM start-up (use _g version for
debugging)
#JVPCLASSPATH /usr/informix/extend/krakatoa/krakatoa_g.jar:/usr/informix/extend/krakatoa/jdbc_g.jar
JVPCLASSPATH /usr/informix/extend/krakatoa/krakatoa.jar:/usr/informix/extend/krakatoa/jdbc.jar
CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled
by default
-----------------------------------------------------------------------------------
[Live:informix->authprog] onstat -g iov
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
19:50:03 -- 1366176 Kbytes
AIO I/O vps:
class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup
errors
msc 0 i 1.4 347262 0 0 0 346688 1.0
0
aio 0 i 7.2 1749873 1634575 115226 0 1332868 1.3
0
aio 1 i 5.4 1318507 1186567 131903 0 1000567 1.3
0
aio 2 i 4.6 1134304 1012006 122284 0 829997 1.4
0
aio 3 i 4.1 1011716 903505 108182 0 741856 1.4
0
aio 4 i 3.8 924162 827913 96237 0 675519 1.4
0
aio 5 i 3.5 865230 771413 93811 0 625331 1.4
0
aio 6 i 3.3 800947 733517 67421 0 577325 1.4
0
aio 7 i 3.1 765666 703406 62255 0 556504 1.4
0
aio 8 i 3.0 730576 674421 56151 0 525623 1.4
0
aio 9 i 2.9 710943 661197 49742 0 509801 1.4
0
aio 10 i 2.8 689305 643398 45905 0 492531 1.4
0
aio 11 i 2.8 672836 632485 40349 0 484161 1.4
0
aio 12 i 2.7 658817 619871 38945 0 473549 1.4
0
aio 13 i 2.6 647042 610192 36848 0 462078 1.4
0
aio 14 i 2.6 635615 601538 34076 0 452923 1.4
0
aio 15 i 2.6 627224 594983 32240 0 446175 1.4
0
aio 16 i 2.5 618576 588385 30190 0 432865 1.4
0
aio 17 i 2.5 610439 582952 27484 0 430871 1.4
0
aio 18 i 2.5 599733 576237 23494 0 415918 1.4
0
aio 19 i 2.4 595984 575264 20718 0 404772 1.5
0
aio 20 i 2.4 594684 574669 20015 0 393904 1.5
0
aio 21 i 2.5 609208 589876 19330 0 378451 1.6
0
pio 0 i 0.0 2226 0 2226 0 2227 1.0
0
lio 0 i 2.8 682701 0 682701 0 682701 1.0
0
--------------------------------------------------------------------------------
[Live:informix->authprog] onstat -D
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
19:51:24 -- 1366176 Kbytes
Dbspaces
address number flags fchunk nchunks flags owner name
788a07d8 1 0x1001 1 1 N informix
rootdbs
7986a018 2 0x1 2 1 N informix
plogdbs
7986a168 3 0x1 3 1 N informix
llogdbs
7986a2b8 4 0x1 4 1 N informix
tmpndbs
7986a408 5 0x2001 5 1 N T informix
tmptdbs
7986a558 6 0x1 6 16 N informix
maindbs
7986a6a8 7 0x8001 22 1 N S informix
sndqdbs
7 active, 2047 maximum
Chunks
address chk/dbs offset page Rd page Wr pathname
788a0928 1 1 0 134807 148882 /IFMXDATA/authlive/rootdbs
798430a0 2 2 0 55 248302 /IFMXDATA/authlive/plogdbs
79843210 3 3 0 961325 872408 /IFMXDATA/authlive/llogdbs
79843380 4 4 0 56 0 /IFMXDATA/authlive/tmpndbs
798434f0 5 5 0 11282158 11816759 /IFMXDATA/authlive/tmptdbs
79843660 6 6 0 2029121 1506
/IFMXDATA/authlive/maindbs01
798437d0 7 6 0 2125406 3654
/IFMXDATA/authlive/maindbs02
79843940 8 6 0 6499803 290748
/IFMXDATA/authlive/maindbs03
79843ab0 9 6 0 9130493 15972
/IFMXDATA/authlive/maindbs04
79843c20 10 6 0 25400099 12700
/IFMXDATA/authlive/maindbs05
79843d90 11 6 0 28955662 14632
/IFMXDATA/authlive/maindbs06
79869018 12 6 0 30918131 5226
/IFMXDATA/authlive/maindbs07
79869188 13 6 0 3187465 47184
/IFMXDATA/authlive/maindbs08
798692f8 14 6 0 4510528 50880
/IFMXDATA/authlive/maindbs09
79869468 15 6 0 3871812 0
/IFMXDATA/authlive/maindbs10
798695d8 16 6 0 8 0
/IFMXDATA/authlive/maindbs11
79869748 17 6 0 8 0
/IFMXDATA/authlive/maindbs12
798698b8 18 6 0 8 0
/IFMXDATA/authlive/maindbs13
79869a28 19 6 0 8 0
/IFMXDATA/authlive/maindbs14
79869b98 20 6 0 8 0
/IFMXDATA/authlive/maindbs15
79869d08 21 6 0 8 0
/IFMXDATA/authlive/maindbs16
79869e78 22 7 0 2327 2176 /IFMXDATA/authlive/sndqdbs
22 active, 2047 maximum
-------------------------------------------------------------------------------
[Live:informix->authprog] onstat -R
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
19:51:49 -- 1366176 Kbytes
128 buffer LRU queue pairs priority levels
# f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
0 f 3122 99.8% 3116 0 2858 243 15
1 m 0.2% 6 0 6 0 0
2 f 3115 99.7% 3105 0 2848 242 15
3 m 0.3% 10 0 10 0 0
4 f 3128 99.5% 3113 0 2860 244 9
5 m 0.5% 15 0 15 0 0
6 f 3119 99.6% 3108 0 2852 240 16
7 m 0.4% 11 0 11 0 0
8 f 3127 99.9% 3123 0 2859 252 12
9 m 0.1% 4 0 4 0 0
10 f 3124 99.7% 3116 0 2839 266 11
11 m 0.3% 8 0 8 0 0
12 f 3117 99.8% 3112 0 2860 242 10
13 m 0.2% 5 0 5 0 0
14 f 3127 99.8% 3122 0 2861 245 16
15 m 0.2% 5 0 5 0 0
16 f 3122 99.7% 3114 0 2860 244 10
17 m 0.3% 8 0 8 0 0
18 f 3109 99.7% 3101 0 2865 229 7
19 m 0.3% 8 0 8 0 0
20 f 3128 99.6% 3116 0 2864 244 8
21 m 0.4% 12 0 12 0 0
22 f 3126 99.6% 3115 0 2830 266 19
23 m 0.4% 11 0 11 0 0
24 f 3113 99.6% 3101 0 2807 282 12
25 m 0.4% 12 0 12 0 0
26 f 3121 99.7% 3111 0 2860 242 9
27 m 0.3% 10 0 10 0 0
28 f 3127 99.7% 3117 0 2864 246 7
29 m 0.3% 10 0 10 0 0
30 f 3118 99.7% 3108 0 2843 255 10
31 m 0.3% 10 0 10 0 0
32 f 3116 99.7% 3106 0 2814 278 14
33 m 0.3% 10 0 10 0 0
34 f 3117 99.7% 3107 0 2859 243 5
35 m 0.3% 10 0 10 0 0
36 f 3128 99.7% 3120 0 2880 227 13
37 m 0.3% 8 0 8 0 0
38 f 3115 99.6% 3101 0 2832 255 14
39 m 0.4% 14 0 14 0 0
40 f 3114 99.4% 3095 0 2803 275 17
41 m 0.6% 19 0 19 0 0
42 f 3139 99.7% 3131 0 2835 282 14
43 m 0.3% 8 0 8 0 0
44 f 3124 99.5% 3109 0 2835 261 13
45 m 0.5% 15 0 15 0 0
46 f 3126 99.7% 3117 0 2820 280 17
47 m 0.3% 9 0 9 0 0
48 f 3109 99.7% 3099 0 2830 256 13
49 m 0.3% 10 0 10 0 0
50 f 3127 99.8% 3121 0 2873 240 8
51 m 0.2% 6 0 6 0 0
52 f 3125 99.7% 3117 0 2851 255 11
53 m 0.3% 8 0 8 0 0
54 f 3122 99.7% 3112 0 2848 258 6
55 m 0.3% 10 0 10 0 0
56 f 3121 99.7% 3113 0 2839 264 10
57 m 0.3% 8 0 8 0 0
58 f 3116 99.6% 3103 0 2824 264 15
59 m 0.4% 13 0 13 0 0
60 f 3118 99.6% 3107 0 2854 236 17
61 m 0.4% 11 0 11 0 0
62 f 3134 99.6% 3123 0 2853 258 12
63 m 0.4% 11 0 11 0 0
64 f 3122 99.8% 3116 0 2840 260 16
65 m 0.2% 6 0 6 0 0
66 f 3106 99.7% 3097 0 2820 268 9
67 m 0.3% 9 0 9 0 0
68 f 3118 99.6% 3106 0 2819 271 16
69 m 0.4% 12 0 12 0 0
70 f 3128 99.7% 3120 0 2845 260 15
71 m 0.3% 8 0 8 0 0
72 f 3125 99.7% 3115 0 2855 250 10
73 m 0.3% 10 0 10 0 0
74 f 3126 99.5% 3111 0 2834 259 18
75 m 0.5% 15 0 15 0 0
76 f 3113 99.5% 3097 0 2832 253 12
77 m 0.5% 16 0 16 0 0
78 f 3121 99.6% 3110 0 2847 250 13
79 m 0.4% 11 0 11 0 0
80 f 3126 99.5% 3111 0 2820 278 13
81 m 0.5% 15 0 15 0 0
82 f 3368 99.7% 3357 0 3086 260 11
83 m 0.3% 11 0 11 0 0
84 f 3109 99.8% 3103 0 2869 225 9
85 m 0.2% 6 0 6 0 0
86 f 3124 99.7% 3116 0 2828 276 12
87 m 0.3% 8 0 8 0 0
88 f 3124 99.7% 3114 0 2840 266 8
89 m 0.3% 10 0 10 0 0
90 f 3119 99.6% 3105 0 2840 252 13
91 m 0.4% 14 0 14 0 0
92 f 3109 99.8% 3102 0 2825 270 7
93 m 0.2% 7 0 7 0 0
94 f 3137 99.7% 3128 0 2889 225 14
95 m 0.3% 9 0 9 0 0
96 f 3128 99.8% 3122 0 2881 230 11
97 m 0.2% 6 0 6 0 0
98 f 3114 99.6% 3101 0 2815 277 9
99 m 0.4% 13 0 13 0 0
100 f 3111 99.8% 3105 0 2865 233 7
101 m 0.2% 6 0 6 0 0
102 f 3139 99.7% 3131 0 2884 234 13
103 m 0.3% 8 0 8 0 0
104 f 3120 99.7% 3111 0 2859 236 16
105 m 0.3% 9 0 9 0 0
106 f 3120 99.8% 3113 0 2867 235 11
107 m 0.2% 7 0 7 0 0
108 f 3126 99.5% 3111 0 2868 232 11
109 m 0.5% 15 0 15 0 0
110 f 3136 99.5% 3120 0 2855 250 15
111 m 0.5% 16 0 16 0 0
112 f 3103 99.5% 3088 0 2837 240 11
113 m 0.5% 15 0 15 0 0
114 f 3132 99.6% 3120 0 2856 256 8
115 m 0.4% 12 0 12 0 0
116 F 3094 99.5% 3080 0 2832 232 16
117 m 0.5% 14 0 14 0 0
118 f 3131 99.6% 3119 0 2850 259 10
119 m 0.4% 12 0 12 0 0
120 f 3137 99.6% 3124 0 2856 260 8
121 m 0.4% 13 0 13 0 0
122 f 3120 99.5% 3105 0 2828 270 7
123 m 0.5% 15 0 15 0 0
124 f 3130 99.7% 3121 0 2846 260 15
125 m 0.3% 9 0 9 0 0
126 f 3119 99.5% 3104 0 2816 272 16
127 m 0.5% 15 0 15 0 0
128 f 3120 99.7% 3110 0 2830 271 9
129 m 0.3% 10 0 10 0 0
130 f 3096 99.4% 3077 0 2826 245 6
131 m 0.6% 19 0 19 0 0
132 f 3137 99.7% 3128 0 2869 245 14
133 m 0.3% 9 0 9 0 0
134 f 3134 99.6% 3121 0 2856 256 9
135 m 0.4% 13 0 13 0 0
136 f 3124 99.5% 3107 0 2845 243 19
137 m 0.5% 17 0 17 0 0
138 f 3112 99.6% 3098 0 2833 253 12
139 m 0.4% 14 0 14 0 0
140 f 3129 99.6% 3117 0 2826 272 19
141 m 0.4% 12 0 12 0 0
142 f 3114 99.5% 3099 0 2845 247 7
143 m 0.5% 15 0 15 0 0
144 f 3113 99.8% 3107 0 2832 264 11
145 m 0.2% 6 0 6 0 0
146 f 3131 99.6% 3119 0 2863 241 15
147 m 0.4% 12 0 12 0 0
148 f 3122 99.6% 3110 0 2846 253 11
149 m 0.4% 12 0 12 0 0
150 f 3131 99.6% 3118 0 2857 250 11
151 m 0.4% 13 0 13 0 0
152 f 3134 99.4% 3115 0 2851 248 16
153 m 0.6% 19 0 19 0 0
154 f 3115 99.4% 3097 0 2838 251 8
155 m 0.6% 18 0 18 0 0
156 f 3129 99.3% 3108 0 2857 247 4
157 m 0.7% 21 0 21 0 0
158 f 3116 99.3% 3095 0 2834 249 12
159 m 0.7% 23 0 23 0 0
160 f 3130 99.6% 3117 0 2859 250 8
161 m 0.4% 13 0 13 0 0
162 f 3115 99.7% 3106 0 2828 259 19
163 m 0.3% 9 0 9 0 0
164 f 3124 99.6% 3113 0 2839 260 14
165 m 0.4% 11 0 11 0 0
166 f 3116 99.7% 3108 0 2840 256 12
167 m 0.3% 8 0 8 0 0
168 f 3128 99.5% 3113 0 2858 239 16
169 m 0.5% 15 0 15 0 0
170 f 3124 99.5% 3108 0 2834 261 13
171 m 0.5% 16 0 16 0 0
172 f 3113 99.3% 3091 0 2830 251 10
173 m 0.7% 22 0 22 0 0
174 f 3114 99.6% 3101 0 2821 269 11
175 m 0.4% 13 0 13 0 0
176 f 3136 99.6% 3125 0 2836 280 9
177 m 0.4% 11 0 11 0 0
178 f 3120 99.4% 3101 0 2842 251 8
179 m 0.6% 19 0 19 0 0
180 f 3125 99.6% 3111 0 2838 254 19
181 m 0.4% 14 0 14 0 0
182 f 3122 99.6% 3109 0 2863 235 11
183 m 0.4% 13 0 13 0 0
184 f 3123 99.6% 3110 0 2850 253 7
185 m 0.4% 13 0 13 0 0
186 f 3119 99.4% 3101 0 2835 252 14
187 m 0.6% 18 0 18 0 0
188 f 3117 99.1% 3090 0 2822 258 10
189 m 0.9% 27 0 27 0 0
190 f 3108 99.5% 3094 0 2822 257 15
191 m 0.5% 14 0 14 0 0
192 f 3139 99.6% 3128 0 2871 244 13
193 m 0.4% 11 0 11 0 0
194 f 3119 99.5% 3103 0 2828 269 6
195 m 0.5% 16 0 16 0 0
196 f 3121 99.6% 3108 0 2839 257 12
197 m 0.4% 13 0 13 0 0
198 f 3112 99.6% 3100 0 2825 264 11
199 m 0.4% 12 0 12 0 0
200 f 3122 99.6% 3109 0 2844 255 10
201 m 0.4% 13 0 13 0 0
202 f 3133 99.7% 3124 0 2844 258 22
203 m 0.3% 9 0 9 0 0
204 f 3112 99.8% 3105 0 2851 237 17
205 m 0.2% 7 0 7 0 0
206 f 3127 99.6% 3115 0 2845 261 9
207 m 0.4% 12 0 12 0 0
208 f 3111 99.5% 3096 0 2823 263 10
209 m 0.5% 15 0 15 0 0
210 f 3121 99.7% 3113 0 2858 241 14
211 m 0.3% 8 0 8 0 0
212 f 3111 99.5% 3097 0 2809 283 5
213 m 0.5% 14 0 14 0 0
214 f 3127 99.4% 3109 0 2831 267 11
215 m 0.6% 18 0 18 0 0
216 f 3133 99.6% 3119 0 2882 225 12
217 m 0.4% 14 0 14 0 0
218 f 3112 99.7% 3102 0 2838 257 7
219 m 0.3% 10 0 10 0 0
220 f 3124 99.5% 3108 0 2842 256 10
221 m 0.5% 16 0 16 0 0
222 f 3127 99.5% 3110 0 2850 247 13
223 m 0.5% 17 0 17 0 0
224 f 3115 99.5% 3100 0 2852 238 10
225 m 0.5% 15 0 15 0 0
226 f 3125 99.5% 3108 0 2835 260 13
227 m 0.5% 17 0 17 0 0
228 f 3127 99.5% 3112 0 2859 238 15
229 m 0.5% 15 0 15 0 0
230 f 3118 99.5% 3101 0 2823 262 16
231 m 0.5% 17 0 17 0 0
232 f 3110 99.7% 3100 0 2829 257 14
233 m 0.3% 10 0 10 0 0
234 f 3129 99.8% 3123 0 2861 242 20
235 m 0.2% 6 0 6 0 0
236 f 3117 99.5% 3102 0 2830 256 16
237 m 0.5% 15 0 15 0 0
238 f 3116 99.6% 3104 0 2843 248 13
239 m 0.4% 12 0 12 0 0
240 f 3130 99.5% 3114 0 2849 253 12
241 m 0.5% 16 0 16 0 0
242 f 3105 99.2% 3079 0 2809 256 14
243 m 0.8% 26 0 26 0 0
244 f 3122 99.6% 3109 0 2865 236 8
245 m 0.4% 13 0 13 0 0
246 f 3139 99.7% 3130 0 2875 248 7
247 m 0.3% 9 0 9 0 0
248 f 3122 99.4% 3103 0 2872 226 5
249 m 0.6% 19 0 19 0 0
250 f 3112 99.5% 3096 0 2840 248 8
251 m 0.5% 16 0 16 0 0
252 f 3124 99.6% 3111 0 2847 251 13
253 m 0.4% 13 0 13 0 0
254 f 3126 99.6% 3115 0 2862 244 9
255 m 0.4% 11 0 11 0 0
1806 dirty, 399755 queued, 400000 total, 524288 hash buckets, 2048
buffer size
start clean at 3% (of pair total) dirty, or 93 buffs dirty, stop at 1%
0 priority downgrades, 0 priority upgrades
---------------------------------------------------------------------------
[Live:informix->authprog] onstat -F | more
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
19:54:39 -- 1366176 Kbytes
Fg Writes LRU Writes Chunk Writes
0 269733 354873
address flusher state data
7898c618 0 I 0 = 0X0
7898cc18 1 I 0 = 0X0
7898d218 2 I 0 = 0X0
7898d818 3 I 0 = 0X0
7898de18 4 I 0 = 0X0
7898e418 5 I 0 = 0X0
7898ea18 6 I 0 = 0X0
7898f018 7 I 0 = 0X0
7898f618 8 I 0 = 0X0
7898fc18 9 I 0 = 0X0
78990218 10 I 0 = 0X0
78990818 11 I 0 = 0X0
78990e18 12 I 0 = 0X0
78991418 13 I 0 = 0X0
78991a18 14 I 0 = 0X0
78992018 15 I 0 = 0X0
78992618 16 I 0 = 0X0
78992c18 17 I 0 = 0X0
78993218 18 I 0 = 0X0
78993818 19 I 0 = 0X0
78993e18 20 I 0 = 0X0
78994418 21 I 0 = 0X0
78994a18 22 I 0 = 0X0
78995018 23 I 0 = 0X0
78995618 24 I 0 = 0X0
78995c18 25 I 0 = 0X0
78996218 26 I 0 = 0X0
78996818 27 I 0 = 0X0
78996e18 28 I 0 = 0X0
78997418 29 I 0 = 0X0
78997a18 30 I 0 = 0X0
78998018 31 I 0 = 0X0
78998618 32 I 0 = 0X0
......
......
......
states: Exit Idle Chunk Lru
--------------------------------------------------------------------------------------------
[Live:informix->authprog] onstat -g seg
Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
20:12:48 -- 1366176 Kbytes
Segment Summary:
id key addr size ovhd class blkused
blkfree
19890179 1381713921 44000000 880369664 241652 R* 214910 24
19922948 1381713922 78796000 512000000 16232 V* 75688 49312
19955717 1381713923 96fde000 3297280 704 M 776 29
19988486 1381713924 97303000 3297280 704 M 774 31
Total: - - 1398964224 - - 292148 49396
(* segment locked in memory)
*********
Hari Gupta Guest
-
???High Table
???High Table ?????????????????? -
Cfcharting from high to low?
Thi has been giving me a lot of trouble lately -- and i'm wondering if it's even possible. I have a system where users are ranked (from 1 - 6) 1... -
high latency
Hi, I have 4 FreeBSD Servers connected to a Cisco 2950 all doing inter-VLAN routing. Everything is working right, but one server is getting... -
High run queue, high idle cpu percentage
Hey - I have a werid situation: vmstat shows high r (always r>0, sometimes r>10), but id > 90%. The rest of the values are nominal. Any... -
high en0
hi, i have a very high en0 value 1500 in topas. i wanted to find out the processes, what stuff is transmitting. but is nto sure which command ... -
Simmons, Keith #2 RE: High lngspins - IDS 9.30 UC2
update statistics
-> -----Original Message-----
-> From: [email]hariog@yahoo.com[/email] [mailto:hariog@yahoo.com]
-> Sent: Thursday, October 16, 2003 8:52 AM
-> To: [email]informix-list@iiug.org[/email]
-> Subject: High lngspins - IDS 9.30 UC2
->
->
-> Hi All,
->
-> We have recently upgraded IDS 9.21UC3 to IDS 9.30 UC3 on RHL 7.3
-> (Kernel - 2.4.18-27.7.xbigmem). Platform - Dell PE6600 - Quard Xeon,
-> dual channel, 8GB RAM - HT. Channel-A has 8 72 GB mirror & stripped
-> and Channel-B has got 8 36 GB mirror & stripped.
->
-> I have been keeping an eye on the database performance and
-> constantly
-> observing that lngspins are keeps on growing. Within 2 days of
-> running,
-> lngspins gone upto more than 21000. Also notice high seqscans.
->
-> So far as seqscans are concern, probably they have been there with
-> IDS 9.21 UC3 as well.
->
-> Could some one pl. advise ? Ofcourse - I am sure gurus like Art, Mark
-> D,
-> Bill, Obnoxio, J Leffler, J Parker, Tsutomu and manu more
-> will respond
-> to it.
->
<SNIPPED>
->
************************************************** ********************************
This message is sent in strict confidence for the addressee only. It may
contain legally privileged information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised recipients are requested
to preserve this confidentiality and to advise the sender immediately of any
error in transmission.
This footnote also confirms that this email message has been swept for the
presence of computer viruses, however we cannot guarantee that this message
is free from such problems.
************************************************** ********************************
sending to informix-list
Simmons, Keith Guest
-
Obnoxio The Clown #3 Re: High lngspins - IDS 9.30 UC2
Hari Gupta wrote:
On the same machine?> We have recently upgraded IDS 9.21UC3 to IDS 9.30 UC3 on RHL 7.3
> (Kernel - 2.4.18-27.7.xbigmem). Platform - Dell PE6600 - Quard Xeon,
> dual channel, 8GB RAM - HT. Channel-A has 8 72 GB mirror & stripped
> and Channel-B has got 8 36 GB mirror & stripped.
Often, this is associated with an underconfiguration of the NETTYPE, but I> I have been keeping an eye on the database performance and constantly
> observing that lngspins are keeps on growing. Within 2 days of
> running,
> lngspins gone upto more than 21000. Also notice high seqscans.
can't really see a problem unless your engine is very busy?
UPDATE STATISTICS? Or missing indexes?> So far as seqscans are concern, probably they have been there with
> IDS 9.21 UC3 as well.
---------------------------------------------------------------------------------------------> [Live:auth->authprog] onstat -g glo
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:00:33 -- 1366176 Kbytes
>
> MT global info:
> sessions threads vps lngspins
> 374 560 31 21430
>
> sched calls thread switches yield 0 yield n yield
> forever
> total: 3927615459 560654618 3584329234 1861444
> 24375989
> per sec: 12 12 0 0 6
>
> [Live:auth->authprog] onstat -p
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 17:59:01 -- 1366176 Kbytes
>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 43056847 125882631 3355831614 98.72 2009883 11470076 12282452 83.64
>
> isamtot open start read write rewrite delete commit
> rollbk
> 2526616592 27179056 150978314 1927954589 3255094 191668 189745
> 651309 34
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 4278 1252 14560 740 0 0 17
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 42021.58 5157.48 246 770
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress
> seqscans
> 1809524 1 2554621970 0 0 271 546021
> 1042972
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 6932524 1128570 24853036 32904007 3401049
>
> ------------------------------------------------------------
>
> [Live:auth->authprog] onstat -P | tail -5
> Percentages:
> Data 83.06
> Btree 15.87
> Other 1.07
>
>
> ------------------------------------------------------------
>#************************************************* *************************>
> [Live:auth->authprog] onstat -c
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:05:45 -- 1366176 Kbytes
>
> Configuration File: /usr/informix/etc/onconfig.authlive
>#************************************************* *************************> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: onconfig.authlive.normalrunning
> # Description: Informix Dynamic Server Configuration Parameters
> # Use this as the base configuration file for a quad
> # hyper-threaded P4 server with 2 gig or more of ram
> #
>#/usr/informix/extend/krakatoa/krakatoa_g.jar:/usr/informix/extend/krakatoa/jdbc_g.jar>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name
> ROOTPATH /IFMXDATA/authlive/rootdbs
> # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 512000 # Size of root dbspace (Kbytes)
>
> # Disk Mirroring Configuration Parameters
>
> MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
> MIRRORPATH # Path for device containing mirrored
> root
> MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
>
> # Physical Log Configuration
>
> PHYSDBS plogdbs # Location (dbspace) of physical log
> PHYSFILE 500000 # Physical log file size (Kbytes)
>
> # Logical Log Configuration
>
> LOGFILES 60 # Number of logical log files
> LOGSIZE 16384 # Logical log size (Kbytes)
>
> # Diagnostics
>
> MSGPATH /var/log/informix/authlive.log # System message log
> file path
> CONSOLE /dev/console # System console message path
> ALARMPROGRAM /usr/informix/etc/no_log.sh # Alarm program path
> TBLSPACE_STATS 1 # Maintain tblspace statistics
>
> # System Archive Tape Device
>
> #TAPEDEV /dev/null # Tape device path
> TAPEDEV /dev/st0 # Tape device path
> TAPEBLK 736 # Tape block size (Kbytes)
> TAPESIZE 102400000 # Maximum amount of data to put on
> tape (Kbytes)
>
> # Log Archive Tape Device
>
> #LTAPEDEV /dev/null # Log tape device path
> LTAPEDEV /dev/st0 # Log tape device path
> LTAPEBLK 512 # Log tape block size (Kbytes)
> LTAPESIZE 20971520 # Max amount of data to put on log
> tape (Kbytes)
> #LTAPESIZE 10240000 # Max amount of data to put on log
> tape (Kbytes)
>
> # Optical
>
> STAGEBLOB # Informix Dynamic Server staging area
>
> # System Configuration
>
> SERVERNUM 5 # Unique id corresponding to a OnLine
> instance
> DBSERVERNAME authlive # Name of default database server
> DBSERVERALIASES authlive_shm # List of alternate dbservernames
> NETTYPE soctcp,2,150,NET # Configure poll thread(s) for
> nettype
> NETTYPE ipcshm,2,300,CPU # Configure poll thread(s) for
> nettype
> DEADLOCK_TIMEOUT 60 # Max time to wait of lock in
> distributed env.
> RESIDENT -1 # Forced residency flag (Yes = 1, No =
> 0)
>
> MULTIPROCESSOR 1 # 0 for single-processor, 1 for
> multi-processor
> NUMCPUVPS 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 100000 # Maximum number of locks
> BUFFERS 400000 # Maximum number of shared buffers
> NUMAIOVPS 22 # Number of IO vps
> PHYSBUFF 256 # Physical log buffer size (Kbytes)
> LOGBUFF 256 # Logical log buffer size (Kbytes)
> CLEANERS 128 # Number of buffer cleaner processes
> SHMBASE 0x44000000L # Shared memory base address
> SHMVIRTSIZE 500000 # initial virtual shared memory
> segment size
> SHMADD 100000 # Size of new shared memory segments
> (Kbytes)
> ### SHMVIRTSIZE 1000000 # initial virtual shared memory
> segment size
> ### SHMADD 200000 # Size of new shared memory
> segments (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
> CKPTINTVL 900 # Check point interval (in sec)
> LRUS 128 # Number of LRU queues
> LRU_MAX_DIRTY 3 # LRU percent dirty begin cleaning
> limit
> LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 32 # Stack size (Kbytes)
> DD_HASHSIZE 501 # No. of slots in dictionary (should
> be prime number)
> DD_HASHMAX 4 # Max number of tables in slot
>
> # Dynamic Logging
> # DYNAMIC_LOGS:
> # 2 : server automatically add a new logical log when necessary.
> (ON)
> # 1 : notify DBA to add new logical logs when necessary. (ON)
> # 0 : cannot add logical log on the fly. (OFF)
> #
> # When dynamic logging is on, we can have higher values for
> LTXHWM/LTXEHWM,
> # because the server can add new logical logs during long transaction
> rollback.
> # However, to limit the number of new logical logs being added,
> LTXHWM/LTXEHWM
> # can be set to smaller values.
> #
> # If dynamic logging is off, LTXHWM/LTXEHWM NEED to be set to smaller
> values
> # to avoid long transaction rollback hanging the server due to lack of
> logical
> # log space, i.e. 50/60 or lower.
>
> DYNAMIC_LOGS 1
> LTXHWM 70
> LTXEHWM 80
>
> # 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
> DRINTERVAL 30 # DR max time between DR buffer
> flushes (in sec)
> DRTIMEOUT 30 # DR network timeout (in sec)
> DRLOSTFOUND /usr/informix/etc/dr.lostfound # DR lost+found file
> path
>
> # CDR Variables
> 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 (Kbytes)
> CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0
> none, 9 max)
> CDR_SERIAL 0,0 # Serial Column Sequence
> CDR_DBSPACE # dbspace for syscdr database
> CDR_QHDR_DBSPACE # CDR queue dbspace (default same as
> catalog)
> CDR_QDATA_SBSPACE sndqdbs # CDR queue smart blob space
> CDR_QDATA_SBFLAGS 0 # Log/no-log (default no log)
>
>
> # Backup/Restore variables
> BAR_ACT_LOG /usr/informix/bar_act.log # ON-Bar Log file - not in
> /tmp please
> BAR_DEBUG_LOG /usr/informix/bar_dbug.log # ON-Bar Debug Log - not in
> /tmp please
> BAR_MAX_BACKUP 0
> BAR_RETRY 1
> BAR_NB_XPORT_COUNT 10
> BAR_XFER_BUF_SIZE 31
> RESTARTABLE_RESTORE on
> BAR_PROGRESS_FREQ 0
>
> # Informix Storage Manager variables
> ISM_DATA_POOL ISMData
> ISM_LOG_POOL ISMLogs
>
> # Read Ahead Variables
> RA_PAGES 128 # Number of pages to attempt to read
> ahead
> RA_THRESHOLD 100 # Number of pages left before next
> group
>
> # DBSPACETEMP:
> # OnLine equivalent of DBTEMP for SE. This is the list of dbspaces
> # that the OnLine SQL Engine will use to create temp tables etc.
> # If specified it must be a colon separated list of dbspaces that
> exist
> # when the OnLine system is brought online. If not specified, or if
> # all dbspaces specified are invalid, various ad hoc queries will
> create
> # temporary files in /tmp instead.
>
> #DBSPACETEMP tmptdbs,tmpndbs # Default temp dbspaces
> DBSPACETEMP tmptdbs # Default temp dbspaces
>
> # DUMP*:
> # The following parameters control the type of diagnostics information
> which
> # is preserved when an unanticipated error condition (assertion
> failure) occurs
> # during OnLine operations.
> # For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
>
> DUMPDIR /tmp # Preserve diagnostics in this
> directory
> DUMPSHMEM 0 # Dump a copy of shared memory
> DUMPGCORE 0 # Dump a core image using 'gcore'
> DUMPCORE 0 # Dump a core image (Warning:this
> aborts OnLine)
> DUMPCNT 1 # Number of shared memory or gcore
> dumps for
> # a single user's session
>
> FILLFACTOR 90 # Fill factor for building indexes
>
> # method for OnLine to use when determining current time
> USEOSTIME 0 # 0: use internal time(fast), 1: get
> time from OS(slow)
>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
> DS_MAX_QUERIES 8 # Maximum number of decision support
> queries
> DS_TOTAL_MEMORY # Decision support memory (Kbytes)
> DS_MAX_SCANS 1048576 # Maximum number of decision support
> scans
> DATASKIP off
> # OPTCOMPIND
> # 0 => Nested loop joins will be preferred (where
> # possible) over sortmerge joins and hash joins.
> # 1 => If the transaction isolation mode is not
> # "repeatable read", optimizer behaves as in (2)
> # below. Otherwise it behaves as in (0) above.
> # 2 => Use costs regardless of the transaction isolation
> # mode. Nested loop joins are not necessarily
> # preferred. Optimizer bases its decision purely
> # on costs.
> OPTCOMPIND 2 # To hint the optimizer
>
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default)
> or OFF (0)
>
> ONDBSPACEDOWN 1 # 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
>
> SBSPACENAME # Default smartblob space name - this
> is where blobs
> # go if no sbspace is specified when
> the smartblob is
> # created. It is also used by some
> datablades as
> # the location to put their
> smartblobs.
> SYSSBSPACENAME # Default smartblob space for use by
> the Informix
> # Server. This is used primarily for
> Informix Server
> # system statistics collection.
>
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /usr/informix/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)
>
> #
> # The following are default settings for enabling Java in the
> database.
>
> # Replace all occurrences of /usr/informix with the value of
> $INFORMIXDIR.
>
> #VPCLASS jvp,num=1 # Number of JVPs to start with
>
> JVPJAVAHOME /usr/informix/extend/krakatoa/jre
> # JRE installation root directory
> JVPHOME /usr/informix/extend/krakatoa # Krakatoa installation
> directory
>
> JVPPROPFILE /usr/informix/extend/krakatoa/.jvpprops # JVP property
> file
> JVPLOGFILE /usr/informix/jvp.log # JVP log file.
>
> JDKVERSION 1.3 # JDK version supported by this server
>
> # The path to the JRE libraries relative to JVPJAVAHOME
> JVPJAVALIB /lib/i386/
>
> # The JRE libraries to use for the Java VM
>
> JVPJAVAVM hpi:server:verify:java:net:zip:jpeg
>
> # use JVPARGS to change Java VM configuration
> #To display jni call
> #JVPARGS -verbose:jni
>
> # Classpath to use upon Java VM start-up (use _g version for
> debugging)
>
> #JVPCLASSPATH
>/usr/informix/extend/krakatoa/krakatoa.jar:/usr/informix/extend/krakatoa/jdbc.jar> JVPCLASSPATH
>----------------------------------------------------------------------------------->
> CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled
> by default
>
>
--
Ciao,
The Obnoxious One
"Ogni uomo mi guarda come se fossi una testa di cazzo"
Obnoxio The Clown Guest
-
Mark Denham #4 Re: High lngspins - IDS 9.30 UC2
Hmm, well my first inclination would be to recommend that you update
statistics, if you have not done so already.
You may well be right that the sequential scans were an issue before the
upgrade, but I would not rule out that the optimizer is making different
[not always good] choices.
If update stats does not reduce your scans I would concentrate on figuring
out which sql's are at the heart of the issue. Chances are that you are
going to need to review your indexes. The good news is that you will
probably find only a handful of problem queries.
As for the long spins, take a look at the output of onstat -g spi. This will
tell you more about the source of the long spins. I would suggest you sort
the output based on num loops. If memory serves right, the ones with the
high counts are going to be generating the long spins.
This can be cross referenced to onstat -g wmx. The list of mutexes that the
system is waiting on. Assuming the problem is happening at the time of
investigation that is.
Mark
----- Original Message -----
From: "Hari Gupta" <hariog@yahoo.com>
To: <informix-list@iiug.org>
Sent: Thursday, October 16, 2003 03:52
Subject: High lngspins - IDS 9.30 UC2
-------------------> Hi All,
>
> We have recently upgraded IDS 9.21UC3 to IDS 9.30 UC3 on RHL 7.3
> (Kernel - 2.4.18-27.7.xbigmem). Platform - Dell PE6600 - Quard Xeon,
> dual channel, 8GB RAM - HT. Channel-A has 8 72 GB mirror & stripped
> and Channel-B has got 8 36 GB mirror & stripped.
>
> I have been keeping an eye on the database performance and constantly
> observing that lngspins are keeps on growing. Within 2 days of
> running,
> lngspins gone upto more than 21000. Also notice high seqscans.
>
> So far as seqscans are concern, probably they have been there with
> IDS 9.21 UC3 as well.
>
> Could some one pl. advise ? Ofcourse - I am sure gurus like Art, Mark
> D,
> Bill, Obnoxio, J Leffler, J Parker, Tsutomu and manu more will respond
> to it.
>
> Details of following onstats are as below:
>
> 1. onstat -g glo
> 2. onstat -p
> 3. onstat -P
> 4. onstat -d
> 5. onstat -c
> 6. onstat -g iov
> 7. onstat -D
> 8. onstat -R
> 9. onstat -F
> 10. onstat -g seg
>
>
> [Live:auth->authprog] onstat -g glo
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:00:33 -- 1366176 Kbytes
>
> MT global info:
> sessions threads vps lngspins
> 374 560 31 21430
>
> sched calls thread switches yield 0 yield n yield
> forever
> total: 3927615459 560654618 3584329234 1861444
> 24375989
> per sec: 12 12 0 0 6
>
> Virtual processor summary:
> class vps usercpu syscpu total
> cpu 3 41233.15 1459.49 42692.64
> aio 22 519.91 1952.60 2472.51
> lio 1 8.67 44.62 53.29
> pio 1 0.60 4.44 5.04
> adm 1 4.75 37.75 42.50
> soc 2 201.84 1638.10 1839.94
> msc 1 68.18 21.72 89.90
> total 31 42037.10 5158.72 47195.82
>
> Individual virtual processors:
> vp pid class usercpu syscpu total
> 1 29700 cpu 13548.51 626.85 14175.36
> 2 29701 adm 4.75 37.75 42.50
> 3 29702 cpu 15078.50 525.08 15603.58
> 4 29703 cpu 12606.14 307.56 12913.70
> 5 29704 lio 8.67 44.62 53.29
> 6 29705 pio 0.60 4.44 5.04
> 7 29706 aio 39.97 260.47 300.44
> 8 29707 msc 68.18 21.72 89.90
> 9 29708 aio 34.73 130.95 165.68
> 10 29709 aio 31.28 120.36 151.64
> 11 29710 aio 29.22 111.09 140.31
> 12 29711 aio 27.27 105.32 132.59
> 13 29712 aio 26.18 100.10 126.28
> 14 29713 aio 24.68 89.16 113.84
> 15 29714 aio 24.03 87.30 111.33
> 16 29715 aio 22.70 79.68 102.38
> 17 29716 aio 22.51 77.28 99.79
> 18 29717 aio 21.54 75.55 97.09
> 21 29718 aio 20.47 70.15 90.62
> 19 29719 aio 21.73 72.90 94.63
> 23 29720 aio 20.04 66.33 86.37
> 22 29721 aio 19.92 68.04 87.96
> 25 29722 aio 19.13 64.25 83.38
> 20 29723 aio 21.04 71.05 92.09
> 27 29724 aio 18.07 59.51 77.58
> 24 29725 aio 19.70 64.01 83.71
> 29 29726 aio 18.55 58.39 76.94
> 26 29727 aio 18.79 61.72 80.51
> 28 29728 aio 18.37 59.00 77.37
> 30 29729 soc 87.05 702.88 789.93
> 31 29730 soc 114.82 935.60 1050.42
> tot 42040.38 5159.23 47199.61
> -----------------------------------------------------------
>
> [Live:auth->authprog] onstat -p
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 17:59:01 -- 1366176 Kbytes
>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 43056847 125882631 3355831614 98.72 2009883 11470076 12282452 83.64
>
> isamtot open start read write rewrite delete commit
> rollbk
> 2526616592 27179056 150978314 1927954589 3255094 191668 189745
> 651309 34
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 4278 1252 14560 740 0 0 17
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 42021.58 5157.48 246 770
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress
> seqscans
> 1809524 1 2554621970 0 0 271 546021
> 1042972
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 6932524 1128570 24853036 32904007 3401049
>
> ------------------------------------------------------------
>
> [Live:auth->authprog] onstat -P | tail -5
> Percentages:
> Data 83.06
> Btree 15.87
> Other 1.07
>
>
> ------------------------------------------------------------
>
> [Live:auth->authprog] onstat -d
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:04:47 -- 1366176 Kbytes
>
> Dbspaces
> address number flags fchunk nchunks flags owner name
> 788a07d8 1 0x1001 1 1 N informix
> rootdbs
> 7986a018 2 0x1 2 1 N informix
> plogdbs
> 7986a168 3 0x1 3 1 N informix
> llogdbs
> 7986a2b8 4 0x1 4 1 N informix
> tmpndbs
> 7986a408 5 0x2001 5 1 N T informix
> tmptdbs
> 7986a558 6 0x1 6 16 N informix
> maindbs
> 7986a6a8 7 0x8001 22 1 N S informix
> sndqdbs
> 7 active, 2047 maximum
>
> Chunks
> address chk/dbs offset size free bpages flags pathname
> 788a0928 1 1 0 256000 198196 PO-
> /IFMXDATA/authlive/rootdbs
> 798430a0 2 2 0 256000 5947 PO-
> /IFMXDATA/authlive/plogdbs
> 79843210 3 3 0 512000 69579 PO-
> /IFMXDATA/authlive/llogdbs
> 79843380 4 4 0 1024000 1023947 PO-
> /IFMXDATA/authlive/tmpndbs
> 798434f0 5 5 0 1024000 1015460 PO-
> /IFMXDATA/authlive/tmptdbs
> 79843660 6 6 0 1024000 7 PO-
> /IFMXDATA/authlive/maindbs01
> 798437d0 7 6 0 1024000 0 PO-
> /IFMXDATA/authlive/maindbs02
> 79843940 8 6 0 1024000 45 PO-
> /IFMXDATA/authlive/maindbs03
> 79843ab0 9 6 0 1024000 17 PO-
> /IFMXDATA/authlive/maindbs04
> 79843c20 10 6 0 1024000 4 PO-
> /IFMXDATA/authlive/maindbs05
> 79843d90 11 6 0 1024000 2 PO-
> /IFMXDATA/authlive/maindbs06
> 79869018 12 6 0 1024000 8 PO-
> /IFMXDATA/authlive/maindbs07
> 79869188 13 6 0 1024000 12 PO-
> /IFMXDATA/authlive/maindbs08
> 798692f8 14 6 0 1024000 99537 PO-
> /IFMXDATA/authlive/maindbs09
> 79869468 15 6 0 1024000 540241 PO-
> /IFMXDATA/authlive/maindbs10
> 798695d8 16 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs11
> 79869748 17 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs12
> 798698b8 18 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs13
> 79869a28 19 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs14
> 79869b98 20 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs15
> 79869d08 21 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs16
> 79869e78 22 7 0 1048575 979092 979093 POS
> /IFMXDATA/authlive/sndqdbs
> Metadata 69429 52508 69429
> 22 active, 2047 maximum
>
> --------------------------------------------------------------------------#************************************************* *************************>
> [Live:auth->authprog] onstat -c
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:05:45 -- 1366176 Kbytes
>
> Configuration File: /usr/informix/etc/onconfig.authlive
>#************************************************* *************************> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: onconfig.authlive.normalrunning
> # Description: Informix Dynamic Server Configuration Parameters
> # Use this as the base configuration file for a quad
> # hyper-threaded P4 server with 2 gig or more of ram
> #
>/usr/informix/extend/krakatoa/krakatoa_g.jar:/usr/informix/extend/krakatoa/j>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name
> ROOTPATH /IFMXDATA/authlive/rootdbs
> # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 512000 # Size of root dbspace (Kbytes)
>
> # Disk Mirroring Configuration Parameters
>
> MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
> MIRRORPATH # Path for device containing mirrored
> root
> MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
>
> # Physical Log Configuration
>
> PHYSDBS plogdbs # Location (dbspace) of physical log
> PHYSFILE 500000 # Physical log file size (Kbytes)
>
> # Logical Log Configuration
>
> LOGFILES 60 # Number of logical log files
> LOGSIZE 16384 # Logical log size (Kbytes)
>
> # Diagnostics
>
> MSGPATH /var/log/informix/authlive.log # System message log
> file path
> CONSOLE /dev/console # System console message path
> ALARMPROGRAM /usr/informix/etc/no_log.sh # Alarm program path
> TBLSPACE_STATS 1 # Maintain tblspace statistics
>
> # System Archive Tape Device
>
> #TAPEDEV /dev/null # Tape device path
> TAPEDEV /dev/st0 # Tape device path
> TAPEBLK 736 # Tape block size (Kbytes)
> TAPESIZE 102400000 # Maximum amount of data to put on
> tape (Kbytes)
>
> # Log Archive Tape Device
>
> #LTAPEDEV /dev/null # Log tape device path
> LTAPEDEV /dev/st0 # Log tape device path
> LTAPEBLK 512 # Log tape block size (Kbytes)
> LTAPESIZE 20971520 # Max amount of data to put on log
> tape (Kbytes)
> #LTAPESIZE 10240000 # Max amount of data to put on log
> tape (Kbytes)
>
> # Optical
>
> STAGEBLOB # Informix Dynamic Server staging area
>
> # System Configuration
>
> SERVERNUM 5 # Unique id corresponding to a OnLine
> instance
> DBSERVERNAME authlive # Name of default database server
> DBSERVERALIASES authlive_shm # List of alternate dbservernames
> NETTYPE soctcp,2,150,NET # Configure poll thread(s) for
> nettype
> NETTYPE ipcshm,2,300,CPU # Configure poll thread(s) for
> nettype
> DEADLOCK_TIMEOUT 60 # Max time to wait of lock in
> distributed env.
> RESIDENT -1 # Forced residency flag (Yes = 1, No =
> 0)
>
> MULTIPROCESSOR 1 # 0 for single-processor, 1 for
> multi-processor
> NUMCPUVPS 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 100000 # Maximum number of locks
> BUFFERS 400000 # Maximum number of shared buffers
> NUMAIOVPS 22 # Number of IO vps
> PHYSBUFF 256 # Physical log buffer size (Kbytes)
> LOGBUFF 256 # Logical log buffer size (Kbytes)
> CLEANERS 128 # Number of buffer cleaner processes
> SHMBASE 0x44000000L # Shared memory base address
> SHMVIRTSIZE 500000 # initial virtual shared memory
> segment size
> SHMADD 100000 # Size of new shared memory segments
> (Kbytes)
> ### SHMVIRTSIZE 1000000 # initial virtual shared memory
> segment size
> ### SHMADD 200000 # Size of new shared memory
> segments (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
> CKPTINTVL 900 # Check point interval (in sec)
> LRUS 128 # Number of LRU queues
> LRU_MAX_DIRTY 3 # LRU percent dirty begin cleaning
> limit
> LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 32 # Stack size (Kbytes)
> DD_HASHSIZE 501 # No. of slots in dictionary (should
> be prime number)
> DD_HASHMAX 4 # Max number of tables in slot
>
> # Dynamic Logging
> # DYNAMIC_LOGS:
> # 2 : server automatically add a new logical log when necessary.
> (ON)
> # 1 : notify DBA to add new logical logs when necessary. (ON)
> # 0 : cannot add logical log on the fly. (OFF)
> #
> # When dynamic logging is on, we can have higher values for
> LTXHWM/LTXEHWM,
> # because the server can add new logical logs during long transaction
> rollback.
> # However, to limit the number of new logical logs being added,
> LTXHWM/LTXEHWM
> # can be set to smaller values.
> #
> # If dynamic logging is off, LTXHWM/LTXEHWM NEED to be set to smaller
> values
> # to avoid long transaction rollback hanging the server due to lack of
> logical
> # log space, i.e. 50/60 or lower.
>
> DYNAMIC_LOGS 1
> LTXHWM 70
> LTXEHWM 80
>
> # 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
> DRINTERVAL 30 # DR max time between DR buffer
> flushes (in sec)
> DRTIMEOUT 30 # DR network timeout (in sec)
> DRLOSTFOUND /usr/informix/etc/dr.lostfound # DR lost+found file
> path
>
> # CDR Variables
> 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 (Kbytes)
> CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0
> none, 9 max)
> CDR_SERIAL 0,0 # Serial Column Sequence
> CDR_DBSPACE # dbspace for syscdr database
> CDR_QHDR_DBSPACE # CDR queue dbspace (default same as
> catalog)
> CDR_QDATA_SBSPACE sndqdbs # CDR queue smart blob space
> CDR_QDATA_SBFLAGS 0 # Log/no-log (default no log)
>
>
> # Backup/Restore variables
> BAR_ACT_LOG /usr/informix/bar_act.log # ON-Bar Log file - not in
> /tmp please
> BAR_DEBUG_LOG /usr/informix/bar_dbug.log # ON-Bar Debug Log - not in
> /tmp please
> BAR_MAX_BACKUP 0
> BAR_RETRY 1
> BAR_NB_XPORT_COUNT 10
> BAR_XFER_BUF_SIZE 31
> RESTARTABLE_RESTORE on
> BAR_PROGRESS_FREQ 0
>
> # Informix Storage Manager variables
> ISM_DATA_POOL ISMData
> ISM_LOG_POOL ISMLogs
>
> # Read Ahead Variables
> RA_PAGES 128 # Number of pages to attempt to read
> ahead
> RA_THRESHOLD 100 # Number of pages left before next
> group
>
> # DBSPACETEMP:
> # OnLine equivalent of DBTEMP for SE. This is the list of dbspaces
> # that the OnLine SQL Engine will use to create temp tables etc.
> # If specified it must be a colon separated list of dbspaces that
> exist
> # when the OnLine system is brought online. If not specified, or if
> # all dbspaces specified are invalid, various ad hoc queries will
> create
> # temporary files in /tmp instead.
>
> #DBSPACETEMP tmptdbs,tmpndbs # Default temp dbspaces
> DBSPACETEMP tmptdbs # Default temp dbspaces
>
> # DUMP*:
> # The following parameters control the type of diagnostics information
> which
> # is preserved when an unanticipated error condition (assertion
> failure) occurs
> # during OnLine operations.
> # For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
>
> DUMPDIR /tmp # Preserve diagnostics in this
> directory
> DUMPSHMEM 0 # Dump a copy of shared memory
> DUMPGCORE 0 # Dump a core image using 'gcore'
> DUMPCORE 0 # Dump a core image (Warning:this
> aborts OnLine)
> DUMPCNT 1 # Number of shared memory or gcore
> dumps for
> # a single user's session
>
> FILLFACTOR 90 # Fill factor for building indexes
>
> # method for OnLine to use when determining current time
> USEOSTIME 0 # 0: use internal time(fast), 1: get
> time from OS(slow)
>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
> DS_MAX_QUERIES 8 # Maximum number of decision support
> queries
> DS_TOTAL_MEMORY # Decision support memory (Kbytes)
> DS_MAX_SCANS 1048576 # Maximum number of decision support
> scans
> DATASKIP off
> # OPTCOMPIND
> # 0 => Nested loop joins will be preferred (where
> # possible) over sortmerge joins and hash joins.
> # 1 => If the transaction isolation mode is not
> # "repeatable read", optimizer behaves as in (2)
> # below. Otherwise it behaves as in (0) above.
> # 2 => Use costs regardless of the transaction isolation
> # mode. Nested loop joins are not necessarily
> # preferred. Optimizer bases its decision purely
> # on costs.
> OPTCOMPIND 2 # To hint the optimizer
>
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default)
> or OFF (0)
>
> ONDBSPACEDOWN 1 # 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
>
> SBSPACENAME # Default smartblob space name - this
> is where blobs
> # go if no sbspace is specified when
> the smartblob is
> # created. It is also used by some
> datablades as
> # the location to put their
> smartblobs.
> SYSSBSPACENAME # Default smartblob space for use by
> the Informix
> # Server. This is used primarily for
> Informix Server
> # system statistics collection.
>
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /usr/informix/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)
>
> #
> # The following are default settings for enabling Java in the
> database.
>
> # Replace all occurrences of /usr/informix with the value of
> $INFORMIXDIR.
>
> #VPCLASS jvp,num=1 # Number of JVPs to start with
>
> JVPJAVAHOME /usr/informix/extend/krakatoa/jre
> # JRE installation root directory
> JVPHOME /usr/informix/extend/krakatoa # Krakatoa installation
> directory
>
> JVPPROPFILE /usr/informix/extend/krakatoa/.jvpprops # JVP property
> file
> JVPLOGFILE /usr/informix/jvp.log # JVP log file.
>
> JDKVERSION 1.3 # JDK version supported by this server
>
> # The path to the JRE libraries relative to JVPJAVAHOME
> JVPJAVALIB /lib/i386/
>
> # The JRE libraries to use for the Java VM
>
> JVPJAVAVM hpi:server:verify:java:net:zip:jpeg
>
> # use JVPARGS to change Java VM configuration
> #To display jni call
> #JVPARGS -verbose:jni
>
> # Classpath to use upon Java VM start-up (use _g version for
> debugging)
>
> #JVPCLASSPATH
dbc_g.jar/usr/informix/extend/krakatoa/krakatoa.jar:/usr/informix/extend/krakatoa/jdb> JVPCLASSPATH
c.jar--------->
> CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled
> by default
>
> -------------------------------------------------------------------------------->
>
> [Live:informix->authprog] onstat -g iov
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:50:03 -- 1366176 Kbytes
>
> AIO I/O vps:
> class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup
> errors
> msc 0 i 1.4 347262 0 0 0 346688 1.0
> 0
> aio 0 i 7.2 1749873 1634575 115226 0 1332868 1.3
> 0
> aio 1 i 5.4 1318507 1186567 131903 0 1000567 1.3
> 0
> aio 2 i 4.6 1134304 1012006 122284 0 829997 1.4
> 0
> aio 3 i 4.1 1011716 903505 108182 0 741856 1.4
> 0
> aio 4 i 3.8 924162 827913 96237 0 675519 1.4
> 0
> aio 5 i 3.5 865230 771413 93811 0 625331 1.4
> 0
> aio 6 i 3.3 800947 733517 67421 0 577325 1.4
> 0
> aio 7 i 3.1 765666 703406 62255 0 556504 1.4
> 0
> aio 8 i 3.0 730576 674421 56151 0 525623 1.4
> 0
> aio 9 i 2.9 710943 661197 49742 0 509801 1.4
> 0
> aio 10 i 2.8 689305 643398 45905 0 492531 1.4
> 0
> aio 11 i 2.8 672836 632485 40349 0 484161 1.4
> 0
> aio 12 i 2.7 658817 619871 38945 0 473549 1.4
> 0
> aio 13 i 2.6 647042 610192 36848 0 462078 1.4
> 0
> aio 14 i 2.6 635615 601538 34076 0 452923 1.4
> 0
> aio 15 i 2.6 627224 594983 32240 0 446175 1.4
> 0
> aio 16 i 2.5 618576 588385 30190 0 432865 1.4
> 0
> aio 17 i 2.5 610439 582952 27484 0 430871 1.4
> 0
> aio 18 i 2.5 599733 576237 23494 0 415918 1.4
> 0
> aio 19 i 2.4 595984 575264 20718 0 404772 1.5
> 0
> aio 20 i 2.4 594684 574669 20015 0 393904 1.5
> 0
> aio 21 i 2.5 609208 589876 19330 0 378451 1.6
> 0
> pio 0 i 0.0 2226 0 2226 0 2227 1.0
> 0
> lio 0 i 2.8 682701 0 682701 0 682701 1.0
> 0
>
>
> ------------------------------------------------------------------------------->
> [Live:informix->authprog] onstat -D
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:51:24 -- 1366176 Kbytes
>
> Dbspaces
> address number flags fchunk nchunks flags owner name
> 788a07d8 1 0x1001 1 1 N informix
> rootdbs
> 7986a018 2 0x1 2 1 N informix
> plogdbs
> 7986a168 3 0x1 3 1 N informix
> llogdbs
> 7986a2b8 4 0x1 4 1 N informix
> tmpndbs
> 7986a408 5 0x2001 5 1 N T informix
> tmptdbs
> 7986a558 6 0x1 6 16 N informix
> maindbs
> 7986a6a8 7 0x8001 22 1 N S informix
> sndqdbs
> 7 active, 2047 maximum
>
> Chunks
> address chk/dbs offset page Rd page Wr pathname
> 788a0928 1 1 0 134807 148882 /IFMXDATA/authlive/rootdbs
> 798430a0 2 2 0 55 248302 /IFMXDATA/authlive/plogdbs
> 79843210 3 3 0 961325 872408 /IFMXDATA/authlive/llogdbs
> 79843380 4 4 0 56 0 /IFMXDATA/authlive/tmpndbs
> 798434f0 5 5 0 11282158 11816759 /IFMXDATA/authlive/tmptdbs
> 79843660 6 6 0 2029121 1506
> /IFMXDATA/authlive/maindbs01
> 798437d0 7 6 0 2125406 3654
> /IFMXDATA/authlive/maindbs02
> 79843940 8 6 0 6499803 290748
> /IFMXDATA/authlive/maindbs03
> 79843ab0 9 6 0 9130493 15972
> /IFMXDATA/authlive/maindbs04
> 79843c20 10 6 0 25400099 12700
> /IFMXDATA/authlive/maindbs05
> 79843d90 11 6 0 28955662 14632
> /IFMXDATA/authlive/maindbs06
> 79869018 12 6 0 30918131 5226
> /IFMXDATA/authlive/maindbs07
> 79869188 13 6 0 3187465 47184
> /IFMXDATA/authlive/maindbs08
> 798692f8 14 6 0 4510528 50880
> /IFMXDATA/authlive/maindbs09
> 79869468 15 6 0 3871812 0
> /IFMXDATA/authlive/maindbs10
> 798695d8 16 6 0 8 0
> /IFMXDATA/authlive/maindbs11
> 79869748 17 6 0 8 0
> /IFMXDATA/authlive/maindbs12
> 798698b8 18 6 0 8 0
> /IFMXDATA/authlive/maindbs13
> 79869a28 19 6 0 8 0
> /IFMXDATA/authlive/maindbs14
> 79869b98 20 6 0 8 0
> /IFMXDATA/authlive/maindbs15
> 79869d08 21 6 0 8 0
> /IFMXDATA/authlive/maindbs16
> 79869e78 22 7 0 2327 2176 /IFMXDATA/authlive/sndqdbs
> 22 active, 2047 maximum
>
>
> --------------------------------------------------------------------------->
>
> [Live:informix->authprog] onstat -R
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:51:49 -- 1366176 Kbytes
>
> 128 buffer LRU queue pairs priority levels
> # f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
> 0 f 3122 99.8% 3116 0 2858 243 15
> 1 m 0.2% 6 0 6 0 0
> 2 f 3115 99.7% 3105 0 2848 242 15
> 3 m 0.3% 10 0 10 0 0
> 4 f 3128 99.5% 3113 0 2860 244 9
> 5 m 0.5% 15 0 15 0 0
> 6 f 3119 99.6% 3108 0 2852 240 16
> 7 m 0.4% 11 0 11 0 0
> 8 f 3127 99.9% 3123 0 2859 252 12
> 9 m 0.1% 4 0 4 0 0
> 10 f 3124 99.7% 3116 0 2839 266 11
> 11 m 0.3% 8 0 8 0 0
> 12 f 3117 99.8% 3112 0 2860 242 10
> 13 m 0.2% 5 0 5 0 0
> 14 f 3127 99.8% 3122 0 2861 245 16
> 15 m 0.2% 5 0 5 0 0
> 16 f 3122 99.7% 3114 0 2860 244 10
> 17 m 0.3% 8 0 8 0 0
> 18 f 3109 99.7% 3101 0 2865 229 7
> 19 m 0.3% 8 0 8 0 0
> 20 f 3128 99.6% 3116 0 2864 244 8
> 21 m 0.4% 12 0 12 0 0
> 22 f 3126 99.6% 3115 0 2830 266 19
> 23 m 0.4% 11 0 11 0 0
> 24 f 3113 99.6% 3101 0 2807 282 12
> 25 m 0.4% 12 0 12 0 0
> 26 f 3121 99.7% 3111 0 2860 242 9
> 27 m 0.3% 10 0 10 0 0
> 28 f 3127 99.7% 3117 0 2864 246 7
> 29 m 0.3% 10 0 10 0 0
> 30 f 3118 99.7% 3108 0 2843 255 10
> 31 m 0.3% 10 0 10 0 0
> 32 f 3116 99.7% 3106 0 2814 278 14
> 33 m 0.3% 10 0 10 0 0
> 34 f 3117 99.7% 3107 0 2859 243 5
> 35 m 0.3% 10 0 10 0 0
> 36 f 3128 99.7% 3120 0 2880 227 13
> 37 m 0.3% 8 0 8 0 0
> 38 f 3115 99.6% 3101 0 2832 255 14
> 39 m 0.4% 14 0 14 0 0
> 40 f 3114 99.4% 3095 0 2803 275 17
> 41 m 0.6% 19 0 19 0 0
> 42 f 3139 99.7% 3131 0 2835 282 14
> 43 m 0.3% 8 0 8 0 0
> 44 f 3124 99.5% 3109 0 2835 261 13
> 45 m 0.5% 15 0 15 0 0
> 46 f 3126 99.7% 3117 0 2820 280 17
> 47 m 0.3% 9 0 9 0 0
> 48 f 3109 99.7% 3099 0 2830 256 13
> 49 m 0.3% 10 0 10 0 0
> 50 f 3127 99.8% 3121 0 2873 240 8
> 51 m 0.2% 6 0 6 0 0
> 52 f 3125 99.7% 3117 0 2851 255 11
> 53 m 0.3% 8 0 8 0 0
> 54 f 3122 99.7% 3112 0 2848 258 6
> 55 m 0.3% 10 0 10 0 0
> 56 f 3121 99.7% 3113 0 2839 264 10
> 57 m 0.3% 8 0 8 0 0
> 58 f 3116 99.6% 3103 0 2824 264 15
> 59 m 0.4% 13 0 13 0 0
> 60 f 3118 99.6% 3107 0 2854 236 17
> 61 m 0.4% 11 0 11 0 0
> 62 f 3134 99.6% 3123 0 2853 258 12
> 63 m 0.4% 11 0 11 0 0
> 64 f 3122 99.8% 3116 0 2840 260 16
> 65 m 0.2% 6 0 6 0 0
> 66 f 3106 99.7% 3097 0 2820 268 9
> 67 m 0.3% 9 0 9 0 0
> 68 f 3118 99.6% 3106 0 2819 271 16
> 69 m 0.4% 12 0 12 0 0
> 70 f 3128 99.7% 3120 0 2845 260 15
> 71 m 0.3% 8 0 8 0 0
> 72 f 3125 99.7% 3115 0 2855 250 10
> 73 m 0.3% 10 0 10 0 0
> 74 f 3126 99.5% 3111 0 2834 259 18
> 75 m 0.5% 15 0 15 0 0
> 76 f 3113 99.5% 3097 0 2832 253 12
> 77 m 0.5% 16 0 16 0 0
> 78 f 3121 99.6% 3110 0 2847 250 13
> 79 m 0.4% 11 0 11 0 0
> 80 f 3126 99.5% 3111 0 2820 278 13
> 81 m 0.5% 15 0 15 0 0
> 82 f 3368 99.7% 3357 0 3086 260 11
> 83 m 0.3% 11 0 11 0 0
> 84 f 3109 99.8% 3103 0 2869 225 9
> 85 m 0.2% 6 0 6 0 0
> 86 f 3124 99.7% 3116 0 2828 276 12
> 87 m 0.3% 8 0 8 0 0
> 88 f 3124 99.7% 3114 0 2840 266 8
> 89 m 0.3% 10 0 10 0 0
> 90 f 3119 99.6% 3105 0 2840 252 13
> 91 m 0.4% 14 0 14 0 0
> 92 f 3109 99.8% 3102 0 2825 270 7
> 93 m 0.2% 7 0 7 0 0
> 94 f 3137 99.7% 3128 0 2889 225 14
> 95 m 0.3% 9 0 9 0 0
> 96 f 3128 99.8% 3122 0 2881 230 11
> 97 m 0.2% 6 0 6 0 0
> 98 f 3114 99.6% 3101 0 2815 277 9
> 99 m 0.4% 13 0 13 0 0
> 100 f 3111 99.8% 3105 0 2865 233 7
> 101 m 0.2% 6 0 6 0 0
> 102 f 3139 99.7% 3131 0 2884 234 13
> 103 m 0.3% 8 0 8 0 0
> 104 f 3120 99.7% 3111 0 2859 236 16
> 105 m 0.3% 9 0 9 0 0
> 106 f 3120 99.8% 3113 0 2867 235 11
> 107 m 0.2% 7 0 7 0 0
> 108 f 3126 99.5% 3111 0 2868 232 11
> 109 m 0.5% 15 0 15 0 0
> 110 f 3136 99.5% 3120 0 2855 250 15
> 111 m 0.5% 16 0 16 0 0
> 112 f 3103 99.5% 3088 0 2837 240 11
> 113 m 0.5% 15 0 15 0 0
> 114 f 3132 99.6% 3120 0 2856 256 8
> 115 m 0.4% 12 0 12 0 0
> 116 F 3094 99.5% 3080 0 2832 232 16
> 117 m 0.5% 14 0 14 0 0
> 118 f 3131 99.6% 3119 0 2850 259 10
> 119 m 0.4% 12 0 12 0 0
> 120 f 3137 99.6% 3124 0 2856 260 8
> 121 m 0.4% 13 0 13 0 0
> 122 f 3120 99.5% 3105 0 2828 270 7
> 123 m 0.5% 15 0 15 0 0
> 124 f 3130 99.7% 3121 0 2846 260 15
> 125 m 0.3% 9 0 9 0 0
> 126 f 3119 99.5% 3104 0 2816 272 16
> 127 m 0.5% 15 0 15 0 0
> 128 f 3120 99.7% 3110 0 2830 271 9
> 129 m 0.3% 10 0 10 0 0
> 130 f 3096 99.4% 3077 0 2826 245 6
> 131 m 0.6% 19 0 19 0 0
> 132 f 3137 99.7% 3128 0 2869 245 14
> 133 m 0.3% 9 0 9 0 0
> 134 f 3134 99.6% 3121 0 2856 256 9
> 135 m 0.4% 13 0 13 0 0
> 136 f 3124 99.5% 3107 0 2845 243 19
> 137 m 0.5% 17 0 17 0 0
> 138 f 3112 99.6% 3098 0 2833 253 12
> 139 m 0.4% 14 0 14 0 0
> 140 f 3129 99.6% 3117 0 2826 272 19
> 141 m 0.4% 12 0 12 0 0
> 142 f 3114 99.5% 3099 0 2845 247 7
> 143 m 0.5% 15 0 15 0 0
> 144 f 3113 99.8% 3107 0 2832 264 11
> 145 m 0.2% 6 0 6 0 0
> 146 f 3131 99.6% 3119 0 2863 241 15
> 147 m 0.4% 12 0 12 0 0
> 148 f 3122 99.6% 3110 0 2846 253 11
> 149 m 0.4% 12 0 12 0 0
> 150 f 3131 99.6% 3118 0 2857 250 11
> 151 m 0.4% 13 0 13 0 0
> 152 f 3134 99.4% 3115 0 2851 248 16
> 153 m 0.6% 19 0 19 0 0
> 154 f 3115 99.4% 3097 0 2838 251 8
> 155 m 0.6% 18 0 18 0 0
> 156 f 3129 99.3% 3108 0 2857 247 4
> 157 m 0.7% 21 0 21 0 0
> 158 f 3116 99.3% 3095 0 2834 249 12
> 159 m 0.7% 23 0 23 0 0
> 160 f 3130 99.6% 3117 0 2859 250 8
> 161 m 0.4% 13 0 13 0 0
> 162 f 3115 99.7% 3106 0 2828 259 19
> 163 m 0.3% 9 0 9 0 0
> 164 f 3124 99.6% 3113 0 2839 260 14
> 165 m 0.4% 11 0 11 0 0
> 166 f 3116 99.7% 3108 0 2840 256 12
> 167 m 0.3% 8 0 8 0 0
> 168 f 3128 99.5% 3113 0 2858 239 16
> 169 m 0.5% 15 0 15 0 0
> 170 f 3124 99.5% 3108 0 2834 261 13
> 171 m 0.5% 16 0 16 0 0
> 172 f 3113 99.3% 3091 0 2830 251 10
> 173 m 0.7% 22 0 22 0 0
> 174 f 3114 99.6% 3101 0 2821 269 11
> 175 m 0.4% 13 0 13 0 0
> 176 f 3136 99.6% 3125 0 2836 280 9
> 177 m 0.4% 11 0 11 0 0
> 178 f 3120 99.4% 3101 0 2842 251 8
> 179 m 0.6% 19 0 19 0 0
> 180 f 3125 99.6% 3111 0 2838 254 19
> 181 m 0.4% 14 0 14 0 0
> 182 f 3122 99.6% 3109 0 2863 235 11
> 183 m 0.4% 13 0 13 0 0
> 184 f 3123 99.6% 3110 0 2850 253 7
> 185 m 0.4% 13 0 13 0 0
> 186 f 3119 99.4% 3101 0 2835 252 14
> 187 m 0.6% 18 0 18 0 0
> 188 f 3117 99.1% 3090 0 2822 258 10
> 189 m 0.9% 27 0 27 0 0
> 190 f 3108 99.5% 3094 0 2822 257 15
> 191 m 0.5% 14 0 14 0 0
> 192 f 3139 99.6% 3128 0 2871 244 13
> 193 m 0.4% 11 0 11 0 0
> 194 f 3119 99.5% 3103 0 2828 269 6
> 195 m 0.5% 16 0 16 0 0
> 196 f 3121 99.6% 3108 0 2839 257 12
> 197 m 0.4% 13 0 13 0 0
> 198 f 3112 99.6% 3100 0 2825 264 11
> 199 m 0.4% 12 0 12 0 0
> 200 f 3122 99.6% 3109 0 2844 255 10
> 201 m 0.4% 13 0 13 0 0
> 202 f 3133 99.7% 3124 0 2844 258 22
> 203 m 0.3% 9 0 9 0 0
> 204 f 3112 99.8% 3105 0 2851 237 17
> 205 m 0.2% 7 0 7 0 0
> 206 f 3127 99.6% 3115 0 2845 261 9
> 207 m 0.4% 12 0 12 0 0
> 208 f 3111 99.5% 3096 0 2823 263 10
> 209 m 0.5% 15 0 15 0 0
> 210 f 3121 99.7% 3113 0 2858 241 14
> 211 m 0.3% 8 0 8 0 0
> 212 f 3111 99.5% 3097 0 2809 283 5
> 213 m 0.5% 14 0 14 0 0
> 214 f 3127 99.4% 3109 0 2831 267 11
> 215 m 0.6% 18 0 18 0 0
> 216 f 3133 99.6% 3119 0 2882 225 12
> 217 m 0.4% 14 0 14 0 0
> 218 f 3112 99.7% 3102 0 2838 257 7
> 219 m 0.3% 10 0 10 0 0
> 220 f 3124 99.5% 3108 0 2842 256 10
> 221 m 0.5% 16 0 16 0 0
> 222 f 3127 99.5% 3110 0 2850 247 13
> 223 m 0.5% 17 0 17 0 0
> 224 f 3115 99.5% 3100 0 2852 238 10
> 225 m 0.5% 15 0 15 0 0
> 226 f 3125 99.5% 3108 0 2835 260 13
> 227 m 0.5% 17 0 17 0 0
> 228 f 3127 99.5% 3112 0 2859 238 15
> 229 m 0.5% 15 0 15 0 0
> 230 f 3118 99.5% 3101 0 2823 262 16
> 231 m 0.5% 17 0 17 0 0
> 232 f 3110 99.7% 3100 0 2829 257 14
> 233 m 0.3% 10 0 10 0 0
> 234 f 3129 99.8% 3123 0 2861 242 20
> 235 m 0.2% 6 0 6 0 0
> 236 f 3117 99.5% 3102 0 2830 256 16
> 237 m 0.5% 15 0 15 0 0
> 238 f 3116 99.6% 3104 0 2843 248 13
> 239 m 0.4% 12 0 12 0 0
> 240 f 3130 99.5% 3114 0 2849 253 12
> 241 m 0.5% 16 0 16 0 0
> 242 f 3105 99.2% 3079 0 2809 256 14
> 243 m 0.8% 26 0 26 0 0
> 244 f 3122 99.6% 3109 0 2865 236 8
> 245 m 0.4% 13 0 13 0 0
> 246 f 3139 99.7% 3130 0 2875 248 7
> 247 m 0.3% 9 0 9 0 0
> 248 f 3122 99.4% 3103 0 2872 226 5
> 249 m 0.6% 19 0 19 0 0
> 250 f 3112 99.5% 3096 0 2840 248 8
> 251 m 0.5% 16 0 16 0 0
> 252 f 3124 99.6% 3111 0 2847 251 13
> 253 m 0.4% 13 0 13 0 0
> 254 f 3126 99.6% 3115 0 2862 244 9
> 255 m 0.4% 11 0 11 0 0
> 1806 dirty, 399755 queued, 400000 total, 524288 hash buckets, 2048
> buffer size
> start clean at 3% (of pair total) dirty, or 93 buffs dirty, stop at 1%
> 0 priority downgrades, 0 priority upgrades
>
> -------------------------------------------------------------------------------------------->
>
> [Live:informix->authprog] onstat -F | more
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:54:39 -- 1366176 Kbytes
>
>
> Fg Writes LRU Writes Chunk Writes
> 0 269733 354873
>
> address flusher state data
> 7898c618 0 I 0 = 0X0
> 7898cc18 1 I 0 = 0X0
> 7898d218 2 I 0 = 0X0
> 7898d818 3 I 0 = 0X0
> 7898de18 4 I 0 = 0X0
> 7898e418 5 I 0 = 0X0
> 7898ea18 6 I 0 = 0X0
> 7898f018 7 I 0 = 0X0
> 7898f618 8 I 0 = 0X0
> 7898fc18 9 I 0 = 0X0
> 78990218 10 I 0 = 0X0
> 78990818 11 I 0 = 0X0
> 78990e18 12 I 0 = 0X0
> 78991418 13 I 0 = 0X0
> 78991a18 14 I 0 = 0X0
> 78992018 15 I 0 = 0X0
> 78992618 16 I 0 = 0X0
> 78992c18 17 I 0 = 0X0
> 78993218 18 I 0 = 0X0
> 78993818 19 I 0 = 0X0
> 78993e18 20 I 0 = 0X0
> 78994418 21 I 0 = 0X0
> 78994a18 22 I 0 = 0X0
> 78995018 23 I 0 = 0X0
> 78995618 24 I 0 = 0X0
> 78995c18 25 I 0 = 0X0
> 78996218 26 I 0 = 0X0
> 78996818 27 I 0 = 0X0
> 78996e18 28 I 0 = 0X0
> 78997418 29 I 0 = 0X0
> 78997a18 30 I 0 = 0X0
> 78998018 31 I 0 = 0X0
> 78998618 32 I 0 = 0X0
> .....
> .....
> .....
>
> states: Exit Idle Chunk Lru
>
> --------------------------------------------------------------------------sending to informix-list>
> [Live:informix->authprog] onstat -g seg
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 20:12:48 -- 1366176 Kbytes
>
> Segment Summary:
> id key addr size ovhd class blkused
> blkfree
> 19890179 1381713921 44000000 880369664 241652 R* 214910 24
> 19922948 1381713922 78796000 512000000 16232 V* 75688 49312
> 19955717 1381713923 96fde000 3297280 704 M 776 29
> 19988486 1381713924 97303000 3297280 704 M 774 31
> Total: - - 1398964224 - - 292148 49396
>
> (* segment locked in memory)
>
>
>
> *********
Mark Denham Guest
-
Hari Gupta #5 Re: High lngspins - IDS 9.30 UC2
Thanks to Simmons, Mark and Obnoxio.
We are running UPD STATS every night by a cron job. So I don't think UPD
STATS would be a potential issue. I will be posting onstat -g spi and other
onstat soon as advised by Obnoxio.
Hari
"Hari Gupta" <hariog@yahoo.com> wrote in message
news:1a1cd35b.0310152352.63f3121c@posting.google.c om...-------------------> Hi All,
>
> We have recently upgraded IDS 9.21UC3 to IDS 9.30 UC3 on RHL 7.3
> (Kernel - 2.4.18-27.7.xbigmem). Platform - Dell PE6600 - Quard Xeon,
> dual channel, 8GB RAM - HT. Channel-A has 8 72 GB mirror & stripped
> and Channel-B has got 8 36 GB mirror & stripped.
>
> I have been keeping an eye on the database performance and constantly
> observing that lngspins are keeps on growing. Within 2 days of
> running,
> lngspins gone upto more than 21000. Also notice high seqscans.
>
> So far as seqscans are concern, probably they have been there with
> IDS 9.21 UC3 as well.
>
> Could some one pl. advise ? Ofcourse - I am sure gurus like Art, Mark
> D,
> Bill, Obnoxio, J Leffler, J Parker, Tsutomu and manu more will respond
> to it.
>
> Details of following onstats are as below:
>
> 1. onstat -g glo
> 2. onstat -p
> 3. onstat -P
> 4. onstat -d
> 5. onstat -c
> 6. onstat -g iov
> 7. onstat -D
> 8. onstat -R
> 9. onstat -F
> 10. onstat -g seg
>
>
> [Live:auth->authprog] onstat -g glo
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:00:33 -- 1366176 Kbytes
>
> MT global info:
> sessions threads vps lngspins
> 374 560 31 21430
>
> sched calls thread switches yield 0 yield n yield
> forever
> total: 3927615459 560654618 3584329234 1861444
> 24375989
> per sec: 12 12 0 0 6
>
> Virtual processor summary:
> class vps usercpu syscpu total
> cpu 3 41233.15 1459.49 42692.64
> aio 22 519.91 1952.60 2472.51
> lio 1 8.67 44.62 53.29
> pio 1 0.60 4.44 5.04
> adm 1 4.75 37.75 42.50
> soc 2 201.84 1638.10 1839.94
> msc 1 68.18 21.72 89.90
> total 31 42037.10 5158.72 47195.82
>
> Individual virtual processors:
> vp pid class usercpu syscpu total
> 1 29700 cpu 13548.51 626.85 14175.36
> 2 29701 adm 4.75 37.75 42.50
> 3 29702 cpu 15078.50 525.08 15603.58
> 4 29703 cpu 12606.14 307.56 12913.70
> 5 29704 lio 8.67 44.62 53.29
> 6 29705 pio 0.60 4.44 5.04
> 7 29706 aio 39.97 260.47 300.44
> 8 29707 msc 68.18 21.72 89.90
> 9 29708 aio 34.73 130.95 165.68
> 10 29709 aio 31.28 120.36 151.64
> 11 29710 aio 29.22 111.09 140.31
> 12 29711 aio 27.27 105.32 132.59
> 13 29712 aio 26.18 100.10 126.28
> 14 29713 aio 24.68 89.16 113.84
> 15 29714 aio 24.03 87.30 111.33
> 16 29715 aio 22.70 79.68 102.38
> 17 29716 aio 22.51 77.28 99.79
> 18 29717 aio 21.54 75.55 97.09
> 21 29718 aio 20.47 70.15 90.62
> 19 29719 aio 21.73 72.90 94.63
> 23 29720 aio 20.04 66.33 86.37
> 22 29721 aio 19.92 68.04 87.96
> 25 29722 aio 19.13 64.25 83.38
> 20 29723 aio 21.04 71.05 92.09
> 27 29724 aio 18.07 59.51 77.58
> 24 29725 aio 19.70 64.01 83.71
> 29 29726 aio 18.55 58.39 76.94
> 26 29727 aio 18.79 61.72 80.51
> 28 29728 aio 18.37 59.00 77.37
> 30 29729 soc 87.05 702.88 789.93
> 31 29730 soc 114.82 935.60 1050.42
> tot 42040.38 5159.23 47199.61
> -----------------------------------------------------------
>
> [Live:auth->authprog] onstat -p
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 17:59:01 -- 1366176 Kbytes
>
> Profile
> dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
> 43056847 125882631 3355831614 98.72 2009883 11470076 12282452 83.64
>
> isamtot open start read write rewrite delete commit
> rollbk
> 2526616592 27179056 150978314 1927954589 3255094 191668 189745
> 651309 34
>
> gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
> 4278 1252 14560 740 0 0 17
>
> ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
> 0 0 0 42021.58 5157.48 246 770
>
> bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress
> seqscans
> 1809524 1 2554621970 0 0 271 546021
> 1042972
>
> ixda-RA idx-RA da-RA RA-pgsused lchwaits
> 6932524 1128570 24853036 32904007 3401049
>
> ------------------------------------------------------------
>
> [Live:auth->authprog] onstat -P | tail -5
> Percentages:
> Data 83.06
> Btree 15.87
> Other 1.07
>
>
> ------------------------------------------------------------
>
> [Live:auth->authprog] onstat -d
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:04:47 -- 1366176 Kbytes
>
> Dbspaces
> address number flags fchunk nchunks flags owner name
> 788a07d8 1 0x1001 1 1 N informix
> rootdbs
> 7986a018 2 0x1 2 1 N informix
> plogdbs
> 7986a168 3 0x1 3 1 N informix
> llogdbs
> 7986a2b8 4 0x1 4 1 N informix
> tmpndbs
> 7986a408 5 0x2001 5 1 N T informix
> tmptdbs
> 7986a558 6 0x1 6 16 N informix
> maindbs
> 7986a6a8 7 0x8001 22 1 N S informix
> sndqdbs
> 7 active, 2047 maximum
>
> Chunks
> address chk/dbs offset size free bpages flags pathname
> 788a0928 1 1 0 256000 198196 PO-
> /IFMXDATA/authlive/rootdbs
> 798430a0 2 2 0 256000 5947 PO-
> /IFMXDATA/authlive/plogdbs
> 79843210 3 3 0 512000 69579 PO-
> /IFMXDATA/authlive/llogdbs
> 79843380 4 4 0 1024000 1023947 PO-
> /IFMXDATA/authlive/tmpndbs
> 798434f0 5 5 0 1024000 1015460 PO-
> /IFMXDATA/authlive/tmptdbs
> 79843660 6 6 0 1024000 7 PO-
> /IFMXDATA/authlive/maindbs01
> 798437d0 7 6 0 1024000 0 PO-
> /IFMXDATA/authlive/maindbs02
> 79843940 8 6 0 1024000 45 PO-
> /IFMXDATA/authlive/maindbs03
> 79843ab0 9 6 0 1024000 17 PO-
> /IFMXDATA/authlive/maindbs04
> 79843c20 10 6 0 1024000 4 PO-
> /IFMXDATA/authlive/maindbs05
> 79843d90 11 6 0 1024000 2 PO-
> /IFMXDATA/authlive/maindbs06
> 79869018 12 6 0 1024000 8 PO-
> /IFMXDATA/authlive/maindbs07
> 79869188 13 6 0 1024000 12 PO-
> /IFMXDATA/authlive/maindbs08
> 798692f8 14 6 0 1024000 99537 PO-
> /IFMXDATA/authlive/maindbs09
> 79869468 15 6 0 1024000 540241 PO-
> /IFMXDATA/authlive/maindbs10
> 798695d8 16 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs11
> 79869748 17 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs12
> 798698b8 18 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs13
> 79869a28 19 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs14
> 79869b98 20 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs15
> 79869d08 21 6 0 1024000 1023997 PO-
> /IFMXDATA/authlive/maindbs16
> 79869e78 22 7 0 1048575 979092 979093 POS
> /IFMXDATA/authlive/sndqdbs
> Metadata 69429 52508 69429
> 22 active, 2047 maximum
>
> --------------------------------------------------------------------------#************************************************* *************************>
> [Live:auth->authprog] onstat -c
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 18:05:45 -- 1366176 Kbytes
>
> Configuration File: /usr/informix/etc/onconfig.authlive
>#************************************************* *************************> #
> # INFORMIX SOFTWARE, INC.
> #
> # Title: onconfig.authlive.normalrunning
> # Description: Informix Dynamic Server Configuration Parameters
> # Use this as the base configuration file for a quad
> # hyper-threaded P4 server with 2 gig or more of ram
> #
>/usr/informix/extend/krakatoa/krakatoa_g.jar:/usr/informix/extend/krakatoa/j>
> # Root Dbspace Configuration
>
> ROOTNAME rootdbs # Root dbspace name
> ROOTPATH /IFMXDATA/authlive/rootdbs
> # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 512000 # Size of root dbspace (Kbytes)
>
> # Disk Mirroring Configuration Parameters
>
> MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
> MIRRORPATH # Path for device containing mirrored
> root
> MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
>
> # Physical Log Configuration
>
> PHYSDBS plogdbs # Location (dbspace) of physical log
> PHYSFILE 500000 # Physical log file size (Kbytes)
>
> # Logical Log Configuration
>
> LOGFILES 60 # Number of logical log files
> LOGSIZE 16384 # Logical log size (Kbytes)
>
> # Diagnostics
>
> MSGPATH /var/log/informix/authlive.log # System message log
> file path
> CONSOLE /dev/console # System console message path
> ALARMPROGRAM /usr/informix/etc/no_log.sh # Alarm program path
> TBLSPACE_STATS 1 # Maintain tblspace statistics
>
> # System Archive Tape Device
>
> #TAPEDEV /dev/null # Tape device path
> TAPEDEV /dev/st0 # Tape device path
> TAPEBLK 736 # Tape block size (Kbytes)
> TAPESIZE 102400000 # Maximum amount of data to put on
> tape (Kbytes)
>
> # Log Archive Tape Device
>
> #LTAPEDEV /dev/null # Log tape device path
> LTAPEDEV /dev/st0 # Log tape device path
> LTAPEBLK 512 # Log tape block size (Kbytes)
> LTAPESIZE 20971520 # Max amount of data to put on log
> tape (Kbytes)
> #LTAPESIZE 10240000 # Max amount of data to put on log
> tape (Kbytes)
>
> # Optical
>
> STAGEBLOB # Informix Dynamic Server staging area
>
> # System Configuration
>
> SERVERNUM 5 # Unique id corresponding to a OnLine
> instance
> DBSERVERNAME authlive # Name of default database server
> DBSERVERALIASES authlive_shm # List of alternate dbservernames
> NETTYPE soctcp,2,150,NET # Configure poll thread(s) for
> nettype
> NETTYPE ipcshm,2,300,CPU # Configure poll thread(s) for
> nettype
> DEADLOCK_TIMEOUT 60 # Max time to wait of lock in
> distributed env.
> RESIDENT -1 # Forced residency flag (Yes = 1, No =
> 0)
>
> MULTIPROCESSOR 1 # 0 for single-processor, 1 for
> multi-processor
> NUMCPUVPS 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 100000 # Maximum number of locks
> BUFFERS 400000 # Maximum number of shared buffers
> NUMAIOVPS 22 # Number of IO vps
> PHYSBUFF 256 # Physical log buffer size (Kbytes)
> LOGBUFF 256 # Logical log buffer size (Kbytes)
> CLEANERS 128 # Number of buffer cleaner processes
> SHMBASE 0x44000000L # Shared memory base address
> SHMVIRTSIZE 500000 # initial virtual shared memory
> segment size
> SHMADD 100000 # Size of new shared memory segments
> (Kbytes)
> ### SHMVIRTSIZE 1000000 # initial virtual shared memory
> segment size
> ### SHMADD 200000 # Size of new shared memory
> segments (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
> CKPTINTVL 900 # Check point interval (in sec)
> LRUS 128 # Number of LRU queues
> LRU_MAX_DIRTY 3 # LRU percent dirty begin cleaning
> limit
> LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit
> TXTIMEOUT 0x12c # Transaction timeout (in sec)
> STACKSIZE 32 # Stack size (Kbytes)
> DD_HASHSIZE 501 # No. of slots in dictionary (should
> be prime number)
> DD_HASHMAX 4 # Max number of tables in slot
>
> # Dynamic Logging
> # DYNAMIC_LOGS:
> # 2 : server automatically add a new logical log when necessary.
> (ON)
> # 1 : notify DBA to add new logical logs when necessary. (ON)
> # 0 : cannot add logical log on the fly. (OFF)
> #
> # When dynamic logging is on, we can have higher values for
> LTXHWM/LTXEHWM,
> # because the server can add new logical logs during long transaction
> rollback.
> # However, to limit the number of new logical logs being added,
> LTXHWM/LTXEHWM
> # can be set to smaller values.
> #
> # If dynamic logging is off, LTXHWM/LTXEHWM NEED to be set to smaller
> values
> # to avoid long transaction rollback hanging the server due to lack of
> logical
> # log space, i.e. 50/60 or lower.
>
> DYNAMIC_LOGS 1
> LTXHWM 70
> LTXEHWM 80
>
> # 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
> DRINTERVAL 30 # DR max time between DR buffer
> flushes (in sec)
> DRTIMEOUT 30 # DR network timeout (in sec)
> DRLOSTFOUND /usr/informix/etc/dr.lostfound # DR lost+found file
> path
>
> # CDR Variables
> 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 (Kbytes)
> CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0
> none, 9 max)
> CDR_SERIAL 0,0 # Serial Column Sequence
> CDR_DBSPACE # dbspace for syscdr database
> CDR_QHDR_DBSPACE # CDR queue dbspace (default same as
> catalog)
> CDR_QDATA_SBSPACE sndqdbs # CDR queue smart blob space
> CDR_QDATA_SBFLAGS 0 # Log/no-log (default no log)
>
>
> # Backup/Restore variables
> BAR_ACT_LOG /usr/informix/bar_act.log # ON-Bar Log file - not in
> /tmp please
> BAR_DEBUG_LOG /usr/informix/bar_dbug.log # ON-Bar Debug Log - not in
> /tmp please
> BAR_MAX_BACKUP 0
> BAR_RETRY 1
> BAR_NB_XPORT_COUNT 10
> BAR_XFER_BUF_SIZE 31
> RESTARTABLE_RESTORE on
> BAR_PROGRESS_FREQ 0
>
> # Informix Storage Manager variables
> ISM_DATA_POOL ISMData
> ISM_LOG_POOL ISMLogs
>
> # Read Ahead Variables
> RA_PAGES 128 # Number of pages to attempt to read
> ahead
> RA_THRESHOLD 100 # Number of pages left before next
> group
>
> # DBSPACETEMP:
> # OnLine equivalent of DBTEMP for SE. This is the list of dbspaces
> # that the OnLine SQL Engine will use to create temp tables etc.
> # If specified it must be a colon separated list of dbspaces that
> exist
> # when the OnLine system is brought online. If not specified, or if
> # all dbspaces specified are invalid, various ad hoc queries will
> create
> # temporary files in /tmp instead.
>
> #DBSPACETEMP tmptdbs,tmpndbs # Default temp dbspaces
> DBSPACETEMP tmptdbs # Default temp dbspaces
>
> # DUMP*:
> # The following parameters control the type of diagnostics information
> which
> # is preserved when an unanticipated error condition (assertion
> failure) occurs
> # during OnLine operations.
> # For DUMPSHMEM, DUMPGCORE and DUMPCORE 1 means Yes, 0 means No.
>
> DUMPDIR /tmp # Preserve diagnostics in this
> directory
> DUMPSHMEM 0 # Dump a copy of shared memory
> DUMPGCORE 0 # Dump a core image using 'gcore'
> DUMPCORE 0 # Dump a core image (Warning:this
> aborts OnLine)
> DUMPCNT 1 # Number of shared memory or gcore
> dumps for
> # a single user's session
>
> FILLFACTOR 90 # Fill factor for building indexes
>
> # method for OnLine to use when determining current time
> USEOSTIME 0 # 0: use internal time(fast), 1: get
> time from OS(slow)
>
> # Parallel Database Queries (pdq)
> MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
> DS_MAX_QUERIES 8 # Maximum number of decision support
> queries
> DS_TOTAL_MEMORY # Decision support memory (Kbytes)
> DS_MAX_SCANS 1048576 # Maximum number of decision support
> scans
> DATASKIP off
> # OPTCOMPIND
> # 0 => Nested loop joins will be preferred (where
> # possible) over sortmerge joins and hash joins.
> # 1 => If the transaction isolation mode is not
> # "repeatable read", optimizer behaves as in (2)
> # below. Otherwise it behaves as in (0) above.
> # 2 => Use costs regardless of the transaction isolation
> # mode. Nested loop joins are not necessarily
> # preferred. Optimizer bases its decision purely
> # on costs.
> OPTCOMPIND 2 # To hint the optimizer
>
> DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default)
> or OFF (0)
>
> ONDBSPACEDOWN 1 # 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
>
> SBSPACENAME # Default smartblob space name - this
> is where blobs
> # go if no sbspace is specified when
> the smartblob is
> # created. It is also used by some
> datablades as
> # the location to put their
> smartblobs.
> SYSSBSPACENAME # Default smartblob space for use by
> the Informix
> # Server. This is used primarily for
> Informix Server
> # system statistics collection.
>
> BLOCKTIMEOUT 3600 # Default timeout for system block
> SYSALARMPROGRAM /usr/informix/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)
>
> #
> # The following are default settings for enabling Java in the
> database.
>
> # Replace all occurrences of /usr/informix with the value of
> $INFORMIXDIR.
>
> #VPCLASS jvp,num=1 # Number of JVPs to start with
>
> JVPJAVAHOME /usr/informix/extend/krakatoa/jre
> # JRE installation root directory
> JVPHOME /usr/informix/extend/krakatoa # Krakatoa installation
> directory
>
> JVPPROPFILE /usr/informix/extend/krakatoa/.jvpprops # JVP property
> file
> JVPLOGFILE /usr/informix/jvp.log # JVP log file.
>
> JDKVERSION 1.3 # JDK version supported by this server
>
> # The path to the JRE libraries relative to JVPJAVAHOME
> JVPJAVALIB /lib/i386/
>
> # The JRE libraries to use for the Java VM
>
> JVPJAVAVM hpi:server:verify:java:net:zip:jpeg
>
> # use JVPARGS to change Java VM configuration
> #To display jni call
> #JVPARGS -verbose:jni
>
> # Classpath to use upon Java VM start-up (use _g version for
> debugging)
>
> #JVPCLASSPATH
dbc_g.jar/usr/informix/extend/krakatoa/krakatoa.jar:/usr/informix/extend/krakatoa/jdb> JVPCLASSPATH
c.jar--------->
> CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled
> by default
>
> -------------------------------------------------------------------------------->
>
> [Live:informix->authprog] onstat -g iov
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:50:03 -- 1366176 Kbytes
>
> AIO I/O vps:
> class/vp s io/s totalops dskread dskwrite dskcopy wakeups io/wup
> errors
> msc 0 i 1.4 347262 0 0 0 346688 1.0
> 0
> aio 0 i 7.2 1749873 1634575 115226 0 1332868 1.3
> 0
> aio 1 i 5.4 1318507 1186567 131903 0 1000567 1.3
> 0
> aio 2 i 4.6 1134304 1012006 122284 0 829997 1.4
> 0
> aio 3 i 4.1 1011716 903505 108182 0 741856 1.4
> 0
> aio 4 i 3.8 924162 827913 96237 0 675519 1.4
> 0
> aio 5 i 3.5 865230 771413 93811 0 625331 1.4
> 0
> aio 6 i 3.3 800947 733517 67421 0 577325 1.4
> 0
> aio 7 i 3.1 765666 703406 62255 0 556504 1.4
> 0
> aio 8 i 3.0 730576 674421 56151 0 525623 1.4
> 0
> aio 9 i 2.9 710943 661197 49742 0 509801 1.4
> 0
> aio 10 i 2.8 689305 643398 45905 0 492531 1.4
> 0
> aio 11 i 2.8 672836 632485 40349 0 484161 1.4
> 0
> aio 12 i 2.7 658817 619871 38945 0 473549 1.4
> 0
> aio 13 i 2.6 647042 610192 36848 0 462078 1.4
> 0
> aio 14 i 2.6 635615 601538 34076 0 452923 1.4
> 0
> aio 15 i 2.6 627224 594983 32240 0 446175 1.4
> 0
> aio 16 i 2.5 618576 588385 30190 0 432865 1.4
> 0
> aio 17 i 2.5 610439 582952 27484 0 430871 1.4
> 0
> aio 18 i 2.5 599733 576237 23494 0 415918 1.4
> 0
> aio 19 i 2.4 595984 575264 20718 0 404772 1.5
> 0
> aio 20 i 2.4 594684 574669 20015 0 393904 1.5
> 0
> aio 21 i 2.5 609208 589876 19330 0 378451 1.6
> 0
> pio 0 i 0.0 2226 0 2226 0 2227 1.0
> 0
> lio 0 i 2.8 682701 0 682701 0 682701 1.0
> 0
>
>
> ------------------------------------------------------------------------------->
> [Live:informix->authprog] onstat -D
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:51:24 -- 1366176 Kbytes
>
> Dbspaces
> address number flags fchunk nchunks flags owner name
> 788a07d8 1 0x1001 1 1 N informix
> rootdbs
> 7986a018 2 0x1 2 1 N informix
> plogdbs
> 7986a168 3 0x1 3 1 N informix
> llogdbs
> 7986a2b8 4 0x1 4 1 N informix
> tmpndbs
> 7986a408 5 0x2001 5 1 N T informix
> tmptdbs
> 7986a558 6 0x1 6 16 N informix
> maindbs
> 7986a6a8 7 0x8001 22 1 N S informix
> sndqdbs
> 7 active, 2047 maximum
>
> Chunks
> address chk/dbs offset page Rd page Wr pathname
> 788a0928 1 1 0 134807 148882 /IFMXDATA/authlive/rootdbs
> 798430a0 2 2 0 55 248302 /IFMXDATA/authlive/plogdbs
> 79843210 3 3 0 961325 872408 /IFMXDATA/authlive/llogdbs
> 79843380 4 4 0 56 0 /IFMXDATA/authlive/tmpndbs
> 798434f0 5 5 0 11282158 11816759 /IFMXDATA/authlive/tmptdbs
> 79843660 6 6 0 2029121 1506
> /IFMXDATA/authlive/maindbs01
> 798437d0 7 6 0 2125406 3654
> /IFMXDATA/authlive/maindbs02
> 79843940 8 6 0 6499803 290748
> /IFMXDATA/authlive/maindbs03
> 79843ab0 9 6 0 9130493 15972
> /IFMXDATA/authlive/maindbs04
> 79843c20 10 6 0 25400099 12700
> /IFMXDATA/authlive/maindbs05
> 79843d90 11 6 0 28955662 14632
> /IFMXDATA/authlive/maindbs06
> 79869018 12 6 0 30918131 5226
> /IFMXDATA/authlive/maindbs07
> 79869188 13 6 0 3187465 47184
> /IFMXDATA/authlive/maindbs08
> 798692f8 14 6 0 4510528 50880
> /IFMXDATA/authlive/maindbs09
> 79869468 15 6 0 3871812 0
> /IFMXDATA/authlive/maindbs10
> 798695d8 16 6 0 8 0
> /IFMXDATA/authlive/maindbs11
> 79869748 17 6 0 8 0
> /IFMXDATA/authlive/maindbs12
> 798698b8 18 6 0 8 0
> /IFMXDATA/authlive/maindbs13
> 79869a28 19 6 0 8 0
> /IFMXDATA/authlive/maindbs14
> 79869b98 20 6 0 8 0
> /IFMXDATA/authlive/maindbs15
> 79869d08 21 6 0 8 0
> /IFMXDATA/authlive/maindbs16
> 79869e78 22 7 0 2327 2176 /IFMXDATA/authlive/sndqdbs
> 22 active, 2047 maximum
>
>
> --------------------------------------------------------------------------->
>
> [Live:informix->authprog] onstat -R
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:51:49 -- 1366176 Kbytes
>
> 128 buffer LRU queue pairs priority levels
> # f/m pair total % of length LOW MED_LOW MED_HIGH HIGH
> 0 f 3122 99.8% 3116 0 2858 243 15
> 1 m 0.2% 6 0 6 0 0
> 2 f 3115 99.7% 3105 0 2848 242 15
> 3 m 0.3% 10 0 10 0 0
> 4 f 3128 99.5% 3113 0 2860 244 9
> 5 m 0.5% 15 0 15 0 0
> 6 f 3119 99.6% 3108 0 2852 240 16
> 7 m 0.4% 11 0 11 0 0
> 8 f 3127 99.9% 3123 0 2859 252 12
> 9 m 0.1% 4 0 4 0 0
> 10 f 3124 99.7% 3116 0 2839 266 11
> 11 m 0.3% 8 0 8 0 0
> 12 f 3117 99.8% 3112 0 2860 242 10
> 13 m 0.2% 5 0 5 0 0
> 14 f 3127 99.8% 3122 0 2861 245 16
> 15 m 0.2% 5 0 5 0 0
> 16 f 3122 99.7% 3114 0 2860 244 10
> 17 m 0.3% 8 0 8 0 0
> 18 f 3109 99.7% 3101 0 2865 229 7
> 19 m 0.3% 8 0 8 0 0
> 20 f 3128 99.6% 3116 0 2864 244 8
> 21 m 0.4% 12 0 12 0 0
> 22 f 3126 99.6% 3115 0 2830 266 19
> 23 m 0.4% 11 0 11 0 0
> 24 f 3113 99.6% 3101 0 2807 282 12
> 25 m 0.4% 12 0 12 0 0
> 26 f 3121 99.7% 3111 0 2860 242 9
> 27 m 0.3% 10 0 10 0 0
> 28 f 3127 99.7% 3117 0 2864 246 7
> 29 m 0.3% 10 0 10 0 0
> 30 f 3118 99.7% 3108 0 2843 255 10
> 31 m 0.3% 10 0 10 0 0
> 32 f 3116 99.7% 3106 0 2814 278 14
> 33 m 0.3% 10 0 10 0 0
> 34 f 3117 99.7% 3107 0 2859 243 5
> 35 m 0.3% 10 0 10 0 0
> 36 f 3128 99.7% 3120 0 2880 227 13
> 37 m 0.3% 8 0 8 0 0
> 38 f 3115 99.6% 3101 0 2832 255 14
> 39 m 0.4% 14 0 14 0 0
> 40 f 3114 99.4% 3095 0 2803 275 17
> 41 m 0.6% 19 0 19 0 0
> 42 f 3139 99.7% 3131 0 2835 282 14
> 43 m 0.3% 8 0 8 0 0
> 44 f 3124 99.5% 3109 0 2835 261 13
> 45 m 0.5% 15 0 15 0 0
> 46 f 3126 99.7% 3117 0 2820 280 17
> 47 m 0.3% 9 0 9 0 0
> 48 f 3109 99.7% 3099 0 2830 256 13
> 49 m 0.3% 10 0 10 0 0
> 50 f 3127 99.8% 3121 0 2873 240 8
> 51 m 0.2% 6 0 6 0 0
> 52 f 3125 99.7% 3117 0 2851 255 11
> 53 m 0.3% 8 0 8 0 0
> 54 f 3122 99.7% 3112 0 2848 258 6
> 55 m 0.3% 10 0 10 0 0
> 56 f 3121 99.7% 3113 0 2839 264 10
> 57 m 0.3% 8 0 8 0 0
> 58 f 3116 99.6% 3103 0 2824 264 15
> 59 m 0.4% 13 0 13 0 0
> 60 f 3118 99.6% 3107 0 2854 236 17
> 61 m 0.4% 11 0 11 0 0
> 62 f 3134 99.6% 3123 0 2853 258 12
> 63 m 0.4% 11 0 11 0 0
> 64 f 3122 99.8% 3116 0 2840 260 16
> 65 m 0.2% 6 0 6 0 0
> 66 f 3106 99.7% 3097 0 2820 268 9
> 67 m 0.3% 9 0 9 0 0
> 68 f 3118 99.6% 3106 0 2819 271 16
> 69 m 0.4% 12 0 12 0 0
> 70 f 3128 99.7% 3120 0 2845 260 15
> 71 m 0.3% 8 0 8 0 0
> 72 f 3125 99.7% 3115 0 2855 250 10
> 73 m 0.3% 10 0 10 0 0
> 74 f 3126 99.5% 3111 0 2834 259 18
> 75 m 0.5% 15 0 15 0 0
> 76 f 3113 99.5% 3097 0 2832 253 12
> 77 m 0.5% 16 0 16 0 0
> 78 f 3121 99.6% 3110 0 2847 250 13
> 79 m 0.4% 11 0 11 0 0
> 80 f 3126 99.5% 3111 0 2820 278 13
> 81 m 0.5% 15 0 15 0 0
> 82 f 3368 99.7% 3357 0 3086 260 11
> 83 m 0.3% 11 0 11 0 0
> 84 f 3109 99.8% 3103 0 2869 225 9
> 85 m 0.2% 6 0 6 0 0
> 86 f 3124 99.7% 3116 0 2828 276 12
> 87 m 0.3% 8 0 8 0 0
> 88 f 3124 99.7% 3114 0 2840 266 8
> 89 m 0.3% 10 0 10 0 0
> 90 f 3119 99.6% 3105 0 2840 252 13
> 91 m 0.4% 14 0 14 0 0
> 92 f 3109 99.8% 3102 0 2825 270 7
> 93 m 0.2% 7 0 7 0 0
> 94 f 3137 99.7% 3128 0 2889 225 14
> 95 m 0.3% 9 0 9 0 0
> 96 f 3128 99.8% 3122 0 2881 230 11
> 97 m 0.2% 6 0 6 0 0
> 98 f 3114 99.6% 3101 0 2815 277 9
> 99 m 0.4% 13 0 13 0 0
> 100 f 3111 99.8% 3105 0 2865 233 7
> 101 m 0.2% 6 0 6 0 0
> 102 f 3139 99.7% 3131 0 2884 234 13
> 103 m 0.3% 8 0 8 0 0
> 104 f 3120 99.7% 3111 0 2859 236 16
> 105 m 0.3% 9 0 9 0 0
> 106 f 3120 99.8% 3113 0 2867 235 11
> 107 m 0.2% 7 0 7 0 0
> 108 f 3126 99.5% 3111 0 2868 232 11
> 109 m 0.5% 15 0 15 0 0
> 110 f 3136 99.5% 3120 0 2855 250 15
> 111 m 0.5% 16 0 16 0 0
> 112 f 3103 99.5% 3088 0 2837 240 11
> 113 m 0.5% 15 0 15 0 0
> 114 f 3132 99.6% 3120 0 2856 256 8
> 115 m 0.4% 12 0 12 0 0
> 116 F 3094 99.5% 3080 0 2832 232 16
> 117 m 0.5% 14 0 14 0 0
> 118 f 3131 99.6% 3119 0 2850 259 10
> 119 m 0.4% 12 0 12 0 0
> 120 f 3137 99.6% 3124 0 2856 260 8
> 121 m 0.4% 13 0 13 0 0
> 122 f 3120 99.5% 3105 0 2828 270 7
> 123 m 0.5% 15 0 15 0 0
> 124 f 3130 99.7% 3121 0 2846 260 15
> 125 m 0.3% 9 0 9 0 0
> 126 f 3119 99.5% 3104 0 2816 272 16
> 127 m 0.5% 15 0 15 0 0
> 128 f 3120 99.7% 3110 0 2830 271 9
> 129 m 0.3% 10 0 10 0 0
> 130 f 3096 99.4% 3077 0 2826 245 6
> 131 m 0.6% 19 0 19 0 0
> 132 f 3137 99.7% 3128 0 2869 245 14
> 133 m 0.3% 9 0 9 0 0
> 134 f 3134 99.6% 3121 0 2856 256 9
> 135 m 0.4% 13 0 13 0 0
> 136 f 3124 99.5% 3107 0 2845 243 19
> 137 m 0.5% 17 0 17 0 0
> 138 f 3112 99.6% 3098 0 2833 253 12
> 139 m 0.4% 14 0 14 0 0
> 140 f 3129 99.6% 3117 0 2826 272 19
> 141 m 0.4% 12 0 12 0 0
> 142 f 3114 99.5% 3099 0 2845 247 7
> 143 m 0.5% 15 0 15 0 0
> 144 f 3113 99.8% 3107 0 2832 264 11
> 145 m 0.2% 6 0 6 0 0
> 146 f 3131 99.6% 3119 0 2863 241 15
> 147 m 0.4% 12 0 12 0 0
> 148 f 3122 99.6% 3110 0 2846 253 11
> 149 m 0.4% 12 0 12 0 0
> 150 f 3131 99.6% 3118 0 2857 250 11
> 151 m 0.4% 13 0 13 0 0
> 152 f 3134 99.4% 3115 0 2851 248 16
> 153 m 0.6% 19 0 19 0 0
> 154 f 3115 99.4% 3097 0 2838 251 8
> 155 m 0.6% 18 0 18 0 0
> 156 f 3129 99.3% 3108 0 2857 247 4
> 157 m 0.7% 21 0 21 0 0
> 158 f 3116 99.3% 3095 0 2834 249 12
> 159 m 0.7% 23 0 23 0 0
> 160 f 3130 99.6% 3117 0 2859 250 8
> 161 m 0.4% 13 0 13 0 0
> 162 f 3115 99.7% 3106 0 2828 259 19
> 163 m 0.3% 9 0 9 0 0
> 164 f 3124 99.6% 3113 0 2839 260 14
> 165 m 0.4% 11 0 11 0 0
> 166 f 3116 99.7% 3108 0 2840 256 12
> 167 m 0.3% 8 0 8 0 0
> 168 f 3128 99.5% 3113 0 2858 239 16
> 169 m 0.5% 15 0 15 0 0
> 170 f 3124 99.5% 3108 0 2834 261 13
> 171 m 0.5% 16 0 16 0 0
> 172 f 3113 99.3% 3091 0 2830 251 10
> 173 m 0.7% 22 0 22 0 0
> 174 f 3114 99.6% 3101 0 2821 269 11
> 175 m 0.4% 13 0 13 0 0
> 176 f 3136 99.6% 3125 0 2836 280 9
> 177 m 0.4% 11 0 11 0 0
> 178 f 3120 99.4% 3101 0 2842 251 8
> 179 m 0.6% 19 0 19 0 0
> 180 f 3125 99.6% 3111 0 2838 254 19
> 181 m 0.4% 14 0 14 0 0
> 182 f 3122 99.6% 3109 0 2863 235 11
> 183 m 0.4% 13 0 13 0 0
> 184 f 3123 99.6% 3110 0 2850 253 7
> 185 m 0.4% 13 0 13 0 0
> 186 f 3119 99.4% 3101 0 2835 252 14
> 187 m 0.6% 18 0 18 0 0
> 188 f 3117 99.1% 3090 0 2822 258 10
> 189 m 0.9% 27 0 27 0 0
> 190 f 3108 99.5% 3094 0 2822 257 15
> 191 m 0.5% 14 0 14 0 0
> 192 f 3139 99.6% 3128 0 2871 244 13
> 193 m 0.4% 11 0 11 0 0
> 194 f 3119 99.5% 3103 0 2828 269 6
> 195 m 0.5% 16 0 16 0 0
> 196 f 3121 99.6% 3108 0 2839 257 12
> 197 m 0.4% 13 0 13 0 0
> 198 f 3112 99.6% 3100 0 2825 264 11
> 199 m 0.4% 12 0 12 0 0
> 200 f 3122 99.6% 3109 0 2844 255 10
> 201 m 0.4% 13 0 13 0 0
> 202 f 3133 99.7% 3124 0 2844 258 22
> 203 m 0.3% 9 0 9 0 0
> 204 f 3112 99.8% 3105 0 2851 237 17
> 205 m 0.2% 7 0 7 0 0
> 206 f 3127 99.6% 3115 0 2845 261 9
> 207 m 0.4% 12 0 12 0 0
> 208 f 3111 99.5% 3096 0 2823 263 10
> 209 m 0.5% 15 0 15 0 0
> 210 f 3121 99.7% 3113 0 2858 241 14
> 211 m 0.3% 8 0 8 0 0
> 212 f 3111 99.5% 3097 0 2809 283 5
> 213 m 0.5% 14 0 14 0 0
> 214 f 3127 99.4% 3109 0 2831 267 11
> 215 m 0.6% 18 0 18 0 0
> 216 f 3133 99.6% 3119 0 2882 225 12
> 217 m 0.4% 14 0 14 0 0
> 218 f 3112 99.7% 3102 0 2838 257 7
> 219 m 0.3% 10 0 10 0 0
> 220 f 3124 99.5% 3108 0 2842 256 10
> 221 m 0.5% 16 0 16 0 0
> 222 f 3127 99.5% 3110 0 2850 247 13
> 223 m 0.5% 17 0 17 0 0
> 224 f 3115 99.5% 3100 0 2852 238 10
> 225 m 0.5% 15 0 15 0 0
> 226 f 3125 99.5% 3108 0 2835 260 13
> 227 m 0.5% 17 0 17 0 0
> 228 f 3127 99.5% 3112 0 2859 238 15
> 229 m 0.5% 15 0 15 0 0
> 230 f 3118 99.5% 3101 0 2823 262 16
> 231 m 0.5% 17 0 17 0 0
> 232 f 3110 99.7% 3100 0 2829 257 14
> 233 m 0.3% 10 0 10 0 0
> 234 f 3129 99.8% 3123 0 2861 242 20
> 235 m 0.2% 6 0 6 0 0
> 236 f 3117 99.5% 3102 0 2830 256 16
> 237 m 0.5% 15 0 15 0 0
> 238 f 3116 99.6% 3104 0 2843 248 13
> 239 m 0.4% 12 0 12 0 0
> 240 f 3130 99.5% 3114 0 2849 253 12
> 241 m 0.5% 16 0 16 0 0
> 242 f 3105 99.2% 3079 0 2809 256 14
> 243 m 0.8% 26 0 26 0 0
> 244 f 3122 99.6% 3109 0 2865 236 8
> 245 m 0.4% 13 0 13 0 0
> 246 f 3139 99.7% 3130 0 2875 248 7
> 247 m 0.3% 9 0 9 0 0
> 248 f 3122 99.4% 3103 0 2872 226 5
> 249 m 0.6% 19 0 19 0 0
> 250 f 3112 99.5% 3096 0 2840 248 8
> 251 m 0.5% 16 0 16 0 0
> 252 f 3124 99.6% 3111 0 2847 251 13
> 253 m 0.4% 13 0 13 0 0
> 254 f 3126 99.6% 3115 0 2862 244 9
> 255 m 0.4% 11 0 11 0 0
> 1806 dirty, 399755 queued, 400000 total, 524288 hash buckets, 2048
> buffer size
> start clean at 3% (of pair total) dirty, or 93 buffs dirty, stop at 1%
> 0 priority downgrades, 0 priority upgrades
>
> -------------------------------------------------------------------------------------------->
>
> [Live:informix->authprog] onstat -F | more
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 19:54:39 -- 1366176 Kbytes
>
>
> Fg Writes LRU Writes Chunk Writes
> 0 269733 354873
>
> address flusher state data
> 7898c618 0 I 0 = 0X0
> 7898cc18 1 I 0 = 0X0
> 7898d218 2 I 0 = 0X0
> 7898d818 3 I 0 = 0X0
> 7898de18 4 I 0 = 0X0
> 7898e418 5 I 0 = 0X0
> 7898ea18 6 I 0 = 0X0
> 7898f018 7 I 0 = 0X0
> 7898f618 8 I 0 = 0X0
> 7898fc18 9 I 0 = 0X0
> 78990218 10 I 0 = 0X0
> 78990818 11 I 0 = 0X0
> 78990e18 12 I 0 = 0X0
> 78991418 13 I 0 = 0X0
> 78991a18 14 I 0 = 0X0
> 78992018 15 I 0 = 0X0
> 78992618 16 I 0 = 0X0
> 78992c18 17 I 0 = 0X0
> 78993218 18 I 0 = 0X0
> 78993818 19 I 0 = 0X0
> 78993e18 20 I 0 = 0X0
> 78994418 21 I 0 = 0X0
> 78994a18 22 I 0 = 0X0
> 78995018 23 I 0 = 0X0
> 78995618 24 I 0 = 0X0
> 78995c18 25 I 0 = 0X0
> 78996218 26 I 0 = 0X0
> 78996818 27 I 0 = 0X0
> 78996e18 28 I 0 = 0X0
> 78997418 29 I 0 = 0X0
> 78997a18 30 I 0 = 0X0
> 78998018 31 I 0 = 0X0
> 78998618 32 I 0 = 0X0
> .....
> .....
> .....
>
> states: Exit Idle Chunk Lru
>
> -------------------------------------------------------------------------->
> [Live:informix->authprog] onstat -g seg
>
> Informix Dynamic Server Version 9.30.UC3 -- On-Line -- Up 2 days
> 20:12:48 -- 1366176 Kbytes
>
> Segment Summary:
> id key addr size ovhd class blkused
> blkfree
> 19890179 1381713921 44000000 880369664 241652 R* 214910 24
> 19922948 1381713922 78796000 512000000 16232 V* 75688 49312
> 19955717 1381713923 96fde000 3297280 704 M 776 29
> 19988486 1381713924 97303000 3297280 704 M 774 31
> Total: - - 1398964224 - - 292148 49396
>
> (* segment locked in memory)
>
>
>
> *********
Hari Gupta Guest
-
Mark D. Stock #6 Re: High lngspins - IDS 9.30 UC2
Hari Gupta wrote:
This is not necessarily a bad thing. Do you have a performance problem?> Hi All,
>
> We have recently upgraded IDS 9.21UC3 to IDS 9.30 UC3 on RHL 7.3
> (Kernel - 2.4.18-27.7.xbigmem). Platform - Dell PE6600 - Quard Xeon,
> dual channel, 8GB RAM - HT. Channel-A has 8 72 GB mirror & stripped
> and Channel-B has got 8 36 GB mirror & stripped.
>
> I have been keeping an eye on the database performance and constantly
> observing that lngspins are keeps on growing. Within 2 days of
> running,
> lngspins gone upto more than 21000. Also notice high seqscans.
It's difficult to evaluate a system from a few snapshots, but I would guess> So far as seqscans are concern, probably they have been there with
> IDS 9.21 UC3 as well.
that a lot of the sequential scans come from temporary table usage. You
only have one temp dbspace and it is being hammered.
Also, it looks like you have placed all your data in one dbspace, so that
will be another hot spot, albeit in 3 chunks during the snapshot.
Cheers,
--
Mark.
+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /|
| Mydas Solutions Ltd [url]http://MydasSolutions.com[/url] |///// / //|
| +-----------------------------------+//// / ///|
| |We value your comments, which have |/// / ////|
| |been recorded and automatically |// / /////|
| |emailed back to us for our records.|/ ////////|
+----------------------+-----------------------------------+-----------+
sending to informix-list
Mark D. Stock Guest
-
Hari Gupta #7 Re: High lngspins - IDS 9.30 UC2
Thanks Mark. I love your comments and sharp observation. Performance
is an issue but not crirical. Regd. tempdbs, if I create another temp
dbspace, you reckon, it will help in hammering down.
Hari
"Mark D. Stock" <mdstock@mydassolutions.com> wrote in message news:<bmn8ls$s8m$1@terabinaries.xmission.com>...> Hari Gupta wrote:
>>> > Hi All,
> >
> > We have recently upgraded IDS 9.21UC3 to IDS 9.30 UC3 on RHL 7.3
> > (Kernel - 2.4.18-27.7.xbigmem). Platform - Dell PE6600 - Quard Xeon,
> > dual channel, 8GB RAM - HT. Channel-A has 8 72 GB mirror & stripped
> > and Channel-B has got 8 36 GB mirror & stripped.
> >
> > I have been keeping an eye on the database performance and constantly
> > observing that lngspins are keeps on growing. Within 2 days of
> > running,
> > lngspins gone upto more than 21000. Also notice high seqscans.
> This is not necessarily a bad thing. Do you have a performance problem?
>>> > So far as seqscans are concern, probably they have been there with
> > IDS 9.21 UC3 as well.
> It's difficult to evaluate a system from a few snapshots, but I would guess
> that a lot of the sequential scans come from temporary table usage. You
> only have one temp dbspace and it is being hammered.
>
> Also, it looks like you have placed all your data in one dbspace, so that
> will be another hot spot, albeit in 3 chunks during the snapshot.
>
> Cheers,
> --
> Mark.
>
> +----------------------------------------------------------+-----------+
> | Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /|
> | Mydas Solutions Ltd [url]http://MydasSolutions.com[/url] |///// / //|
> | +-----------------------------------+//// / ///|
> | |We value your comments, which have |/// / ////|
> | |been recorded and automatically |// / /////|
> | |emailed back to us for our records.|/ ////////|
> +----------------------+-----------------------------------+-----------+
>
> sending to informix-listHari Gupta Guest
-
Mark D. Stock #8 Re: High lngspins - IDS 9.30 UC2
Hari Gupta wrote:
Thanks. So YOU'RE the one. :-)> Thanks Mark. I love your comments and sharp observation.
Okay. So you were just fishing for improvements.> Performance is an issue but not crirical.
I would like to see at least three on any system, especially one making> Regd. tempdbs, if I create another temp
> dbspace, you reckon, it will help in hammering down.
heavy use of temp tables. Preferably on different disks. Although that may
be difficult with your striping.
Quite often you will read all records from a temp table, so sequential
scans in that instance are not bad. However, for more filtered queries from
large temp tables, you can also look at creating indexes on them. The
additional overhead may be far less than the sequential scan.
Cheers,
--
Mark.
+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /|
| Mydas Solutions Ltd [url]http://MydasSolutions.com[/url] |///// / //|
| +-----------------------------------+//// / ///|
| |We value your comments, which have |/// / ////|
| |been recorded and automatically |// / /////|
| |emailed back to us for our records.|/ ////////|
+----------------------+-----------------------------------+-----------+
sending to informix-list
Mark D. Stock Guest
-
Obnoxio The Clown #9 Re: High lngspins - IDS 9.30 UC2
Mark D. Stock wrote:
He's probably just confused you with Mark Townsend. :o)> Hari Gupta wrote:
>>>> Thanks Mark. I love your comments and sharp observation.
> Thanks. So YOU'RE the one. :-)
--
Ciao,
The Obnoxious One
"Ogni uomo mi guarda come se fossi una testa di cazzo"
Obnoxio The Clown Guest
-
Andrew Hamm #10 Re: High lngspins - IDS 9.30 UC2
Mark D. Stock wrote:
And anyway, striping is the enemy of performance on standard Intel systems>
> I would like to see at least three on any system, especially one
> making heavy use of temp tables. Preferably on different disks.
> Although that may be difficult with your striping.
in these days of multi-multi-GB disks. It overloads the disk with too many
active access threads, which reduces performance to the minimum the disk can
offer instead of the maximum it can offer. That's typically a factor of
about 4:1.
Andrew Hamm Guest
-
Art S. Kagel #11 Re: High lngspins - IDS 9.30 UC2
On Sun, 19 Oct 2003 19:18:16 -0400, Andrew Hamm wrote:
> Mark D. Stock wrote:>>>
>> I would like to see at least three on any system, especially one making heavy
>> use of temp tables. Preferably on different disks. Although that may be
>> difficult with your striping.
> And anyway, striping is the enemy of performance on standard Intel systems in
> these days of multi-multi-GB disks. It overloads the disk with too many active
> access threads, which reduces performance to the minimum the disk can offer
> instead of the maximum it can offer. That's typically a factor of about 4:1.
That requires further elucidation, Mark. Please!?!
Art S. Kagel
Art S. Kagel Guest
-
Mark D. Stock #12 Re: High lngspins - IDS 9.30 UC2
Art S. Kagel wrote:
Really? If I'm going to bother to fragment, then I like to do it with at>>>Mark D. Stock wrote:
>>>>>I would like to see at least three on any system, especially one making heavy
>>>use of temp tables. Preferably on different disks. Although that may be
>>>difficult with your striping.
> That requires further elucidation, Mark. Please!?!
least 3 fragments. I like to have more than 2 temp dbspaces to be able to
spread the load of temp tables. It just becomes redundant doing it with
fragmentation, when the underlying striping lights up all the disks for
every access anyway.
Cheers,
--
Mark.
+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mdstock@MydasSolutions.com |//////// /|
| Mydas Solutions Ltd [url]http://MydasSolutions.com[/url] |///// / //|
| +-----------------------------------+//// / ///|
| |We value your comments, which have |/// / ////|
| |been recorded and automatically |// / /////|
| |emailed back to us for our records.|/ ////////|
+----------------------+-----------------------------------+-----------+
sending to informix-list
Mark D. Stock Guest
-
Art S. Kagel #13 Re: High lngspins - IDS 9.30 UC2
On Mon, 20 Oct 2003 09:19:09 -0400, Art S. Kagel wrote:
Oops, should have addressed my question to Andrew, not Mark. Sorry.
Art S. Kagel
> On Sun, 19 Oct 2003 19:18:16 -0400, Andrew Hamm wrote:
>>>> Mark D. Stock wrote:>>>>>
>>> I would like to see at least three on any system, especially one making
>>> heavy use of temp tables. Preferably on different disks. Although that may
>>> be difficult with your striping.
>> And anyway, striping is the enemy of performance on standard Intel systems in
>> these days of multi-multi-GB disks. It overloads the disk with too many
>> active access threads, which reduces performance to the minimum the disk can
>> offer instead of the maximum it can offer. That's typically a factor of about
>> 4:1.
>
> That requires further elucidation, Mark. Please!?!
>
> Art S. KagelArt S. Kagel Guest
-
Richard Kofler #14 Re: High lngspins - IDS 9.30 UC2
Andrew Hamm wrote:
I now for a while testing on an Intel box with>
> Mark D. Stock wrote:>> >
> > I would like to see at least three on any system, especially one
> > making heavy use of temp tables. Preferably on different disks.
> > Although that may be difficult with your striping.
> And anyway, striping is the enemy of performance on standard Intel systems
> in these days of multi-multi-GB disks. It overloads the disk with too many
> active access threads, which reduces performance to the minimum the disk can
> offer instead of the maximum it can offer. That's typically a factor of
> about 4:1.
two 3-ware HW RAID controllers on 2 PCI busses 64bit/66MHz
1 RAID-5 with 4 parallel 160 GB IDE disks
1 RAID 10 with 4 parallel 160 GB IDE disks
Running 6 bonnie++ tests in parallel shows me better read perf from
RAID5.
Ratio RAID 10 : RAID 5 is like 2:3
(reads from 3 instead of 2 disks at any given time, so it makes sense)
Write performance of the RAID5 just suxx (20 MB/sec).
bonnie++ random write performance of the RAID10 is over 105MB/sec
HPL performance on this system beats the heavy $$$$ SANs by a
magnitude!
(if NOT loading onto the RAID5):
I can load 80.000 2 KB pages per sec reading from RAID5 loading into 8
chunks
which sit on the RAID10. (Version 9.40.UC2 on SuSE 8.2)
I con unload >120.000 pg/sec from the RAID5 and 81.000 from RAID10
Parallism of more than 8 HPL threads tends to increase the overall
loading duration, whereas 7 parallel HPL threads is not as fast as 8.
8-way parallel on this 4 disk RAID10 is the sweet spot for writes,
so it seems.
dic_k
--
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe
Richard Kofler Guest
-
Andrew Hamm #15 Re: High lngspins - IDS 9.30 UC2
Art S. Kagel wrote:
welllllll> Andrew Hamm wrote:>>>
>> And anyway, striping is the enemy of performance on standard Intel
>> systems in these days of multi-multi-GB disks. It overloads the disk
>> with too many active access threads, which reduces performance to
>> the minimum the disk can offer instead of the maximum it can offer.
>> That's typically a factor of about 4:1.
> That requires further elucidation, Mark^H^H^H^HAndrew. Please!?!
what follows, I have found does NOT apply to large funky highly-resourced
disk arrays like Clariions, however no "ordinary" hardware (ie using SCSI
and raid controllers) on Intel escapes the following principles. I know also
that typical HPs are affected. I think I tested a Sun box two years ago and
saw the same results. After that, I can't say, however I will make an
educated guess that any box directly interfacing to SCSI controllers, or
raid boxes based around SCSI controllers, will fit the following model. The
Clariion arrays escape because they have massive non-volatile cache which
completely hides the performance characteristics of the disks; for any
controller system to escape, it must also have smarts that are at least
equivalent to Clariion arrays.
on with the story...
Starting at the disk, you can make multiple requests on disks which are
queued and processed by the disks on-board processor. The multiple requests
can come from multiple processes which require service. IDS is a beautiful
example of this, because it literally has multiple processes using one file
handle per chunk to perform I/O. If you are using KAIO then you just have to
map through the indirection that KAIO offers, but it still applies...
Each file handle used by IDS - consider it one "thread" of access.
One thread of access might return performance of 400. Two threads 600, three
970, upto 1500 for 8 threads, then suddenly the performance drops to 800,
500, 400, 400, 400, ..... for 9, 10, 11,.... threads.
These numbers are from an actual measurement of an HP 3 years ago - the only
sample files I could find :-) The numbers measure the KB/second when
performing random transfers of 2K pages (somewhat like a busy IDS engine
running an OLTP system:-)
The numbers are similar proportionally but of course with higher throughput
when the activity is sequential accesses.
So, if you put too many ACTIVE threads on a disk, it will ultimately limit
performance to the baseline (ie 400 in this case) just as surely as having
too few ACTIVE threads.
Now, combine striping with IDS's 2GB/chunk limit (prior to 9.40) and a
multi-GB disk set, and you will overload the disks. For example, if you have
4 x 40Gb disks, and you allocate your chunks using striping:
2Gb striped over 4 way will mean that each disk will contribute 0.5G to each
chunk. That leaves 39.5Gb on each disk, so you'll probably allocate a few
more striped chunks. Allocate 8 striped chunks, and you will have consumed
4Gb only on each disk.
At this point, assuming each chunk is generally busy, you will have fully
loaded the disks with all the threads it can handle. Your performance might
be the 1500 times 4 due to the striping. Now add just two more striped
chunks and make them busy. Suddenly each disk is overloaded, their
performance slumps to 400, so total performance is only 400 x 4. In this
case, almost 4 times slower than maximum, and you still haven't consumed
more than 1/8th the available space.
Bad news.
Clariions manage to avoid this problem. I guess they use their massive cache
to absorb data as quickly as possible, and then the on-board processing
doles out the disk activity in a scientifically optimised manner to make the
best use of the disks. In other words, a Clariion must map take your N
threads to 8 threads per disk no matter what your N is. For any box to offer
this performance, it must be as smart. I have no measurements of SANs or
other manufacturers smart disk arrays, but it's very easy to test this for
yourself.
If you are using standard SCSI hardware (and this includes most commodity
boxes with Intel, HP, Sun, etc etc etc inside) then you can measure your
disk system and find out how lucky you are. Don't count on it.
So, although striping was phat news in the early and mid 90's when disks
were a few Gb if you were lucky, these days you simply can't afford to
stripe across a disk with dozens and dozens of Gb.
What might help you avoid this situation?
IDS 9.40 now supports >2Gb, correct? PHEW!!! Allocate chunks >2Gb which
directly cover your needs.
Decision to use striping depends on your application: I keep capitalising
ACTIVE chunks. If you have a data warehouse, then presumably you CAN profit
from striping. You just need to be absolutely sure about typical access
patterns. Just don't overload the disk.
One trick that can help with DW performance - fragment a large table onto
the same disk! consider your typical fragment elimination etc, and if you
can get upto 8 busy fragments from the same disk (and perhaps another 8 on
another disk, etc) then you can count on a maximum throughput of 1500 per
disk for a single-table scan. Jack Parker has pushed this trick in the past.
Very clever.
People running OLTP cannot afford the luxury of the fantasy that only one
thing will be happening at once. You need to spread your data evenly across
all available disks so that each disk keeps equally busy. Striping
multiplies the thread load on a disk, so it is now an enemy of performance
on todays standard multi-gig disks.
A busy OLTP system will be simultaneously perform random reads of indexes
and tables, sorts, scans, updates, LRU writes, Checkpoint writes. A lot of
people have issues with checkpoint durations; applying these principles can
cause your checkpoints to equally load all of your disks to the maximum of
their capability, and that can result in a startling performance benefit.
For example, if a system is badly setup so that mostly one chunk gets all
the new write activity, then it's checkpoint duration could be 20 seconds
(an example of an appalling checkpoint time which typically causes people to
get as much LRU writes as possible). Now, spread out the load to max on that
disk, and immediately your checkpoint might drop to 8 seconds. Finally,
spread the load also to 2, 3, 4 disks, and your checkpoint times will drop
to 4, 3, 2 seconds. That's a FANTASTIC improvement of checkpoint times.
Even if you believe that LRU writes are King, guess what? Spread the load
out properly, and you'll realise the same performance benefits for LRU
writes. You might even be able to ease off on the LRU percentages, which
means there's more performance available for queries, which is a handy bonus
on top of the fact that query performance will ALSO benefit equally from
spreading the load around.
Last few years, when setting up OLTP, I've had to try to get creative when
allocating spaces. You have to find quiet but large tables that can be put
into spaces that aren't busy, and therefore will not affect normal
performance. Other tricks might be to find tables that do partake in large
sequential scans, and spread them around. Even on an OLTP system, some of
the big ugly tables do tend to push the system towards a DW-style access
pattern for some periods of the day. However, if the system is busy doing
OLTP things, don't count on too much of a shift. If your house has an
overnight "batching" period, then you could profit from consideration of
this effect.
What else? I guess it all boils down to:
1) measuring your underlying disk system. See
[url]http://www.geocities.com/ahammau/informix/pfread.html[/url]
Please ignore the statements like "under construction" - it ain't been
edited for over 2 years :-)
2) Understand your application. Simple onstat commands (eg onstat -g iof)
can show your daily load averages per disk; applying thought can help you
understand your access patterns and whether the load will be constant or
bursty.
3) applying the black art (as opposed to the Kagel Art) of table
distribution. I have made scripts to measure activity on all disks and then
attempt to allocate tables round-robin to all allocated chunks, but it's a
problem with several variables so I don't think there's a perfect software
solution unless you've got a PhD in statistics. However my results have been
quite effective as a first step. Typical results of the scripts have been
about 3:1 load difference at worst between the busiest vs. quietest chunks,
and that's a good starting point. After that, I push a few tables around to
try to smooth out the bumps. If you are trying to tune an existing system
then you'll probably only be able to improve things incrementally anyway.
As Richard has noted on his reply, he's found maximum HPL load performance
comes with 8 HPL threads. Bewwwwdiful.
OTC has noted in the past the benefits of carefully allocating your chunks
by stepping from disk to disk as you build an engine. This means that each
file descriptor is allocated sequentially across the disks, round-robin
style. The benefit from this will come if you CANNOT avoid a large number of
chunks per disk. If you artifically limit your cleaners to 8 / disk, and if
the load is even, then LRU and checkpoint writes will be throttled back to
stay on the sweetspot which will ultimately improve your throughput.
Ideally, the chunks will each be flushed evenly, and the engine will move on
to flushing another chunk without ever overloading the disk.
However if you allocate 20 chunks per disk(set) (a likely outcome when you
stripe) before moving on to the next disk(set), then you will force the
engine to concentrate flushes onto a disk, and your LRU writes and
checkpoints will suffer accordingly.
Please 'scuse the rough and rambling treatment of the subject; I've been too
busy lately to sit sipping port and pontificating. *mutters dark words about
new management structures*
Andrew Hamm Guest
-
Art S. Kagel #16 Re: High lngspins - IDS 9.30 UC2
On Mon, 20 Oct 2003 20:59:24 -0400, Andrew Hamm wrote:
Thanks, Andrew. I have not noticed these problems in my own testing but this
is Clarion City so... Definitely something to investigate going forward.
Art S. Kagel
<Tons of great stuff SNIPPED>> Art S. Kagel wrote:>>> Andrew Hamm wrote:>>>>>
>>> And anyway, striping is the enemy of performance on standard Intel systems
>>> in these days of multi-multi-GB disks. It overloads the disk with too many
>>> active access threads, which reduces performance to the minimum the disk can
>>> offer instead of the maximum it can offer. That's typically a factor of
>>> about 4:1.
>> That requires further elucidation, Mark^H^H^H^HAndrew. Please!?!
> welllllll
>
> what follows, I have found does NOT apply to large funky highly-resourced disk
> arrays like Clariions, however no "ordinary" hardware (ie using SCSI and raid
> controllers) on Intel escapes the following principles. I know also that
Art S. Kagel Guest
-
Art S. Kagel #17 Re: High lngspins - IDS 9.30 UC2
On Mon, 20 Oct 2003 17:38:27 -0400, Richard Kofler wrote:
Just a brief note: I'd like to see a 6 disk (3pair) RAID10 versus the 4 drive
RAID5 for apples to apples read performance numbers. As Richard notes, one
cannot expect 2 RAID10 pairs to out perform the (effectively) 3-data-drive
RAID5 array.
Art S. Kagel
> Andrew Hamm wrote:>>>
>> Mark D. Stock wrote:>>>> >
>> > I would like to see at least three on any system, especially one making
>> > heavy use of temp tables. Preferably on different disks. Although that may
>> > be difficult with your striping.
>> And anyway, striping is the enemy of performance on standard Intel systems in
>> these days of multi-multi-GB disks. It overloads the disk with too many
>> active access threads, which reduces performance to the minimum the disk can
>> offer instead of the maximum it can offer. That's typically a factor of about
>> 4:1.
> I now for a while testing on an Intel box with two 3-ware HW RAID controllers
> on 2 PCI busses 64bit/66MHz 1 RAID-5 with 4 parallel 160 GB IDE disks 1 RAID
> 10 with 4 parallel 160 GB IDE disks
>
> Running 6 bonnie++ tests in parallel shows me better read perf from RAID5.
> Ratio RAID 10 : RAID 5 is like 2:3
> (reads from 3 instead of 2 disks at any given time, so it makes sense)
>
> Write performance of the RAID5 just suxx (20 MB/sec).
>
> bonnie++ random write performance of the RAID10 is over 105MB/sec
>
> HPL performance on this system beats the heavy $$$$ SANs by a magnitude! (if
> NOT loading onto the RAID5):
> I can load 80.000 2 KB pages per sec reading from RAID5 loading into 8 chunks
> which sit on the RAID10. (Version 9.40.UC2 on SuSE 8.2) I con unload >120.000
> pg/sec from the RAID5 and 81.000 from RAID10
>
> Parallism of more than 8 HPL threads tends to increase the overall loading
> duration, whereas 7 parallel HPL threads is not as fast as 8.
>
> 8-way parallel on this 4 disk RAID10 is the sweet spot for writes, so it
> seems.
>
> dic_kArt S. Kagel Guest
-
Andrew Hamm #18 Re: High lngspins - IDS 9.30 UC2
Art S. Kagel wrote:
In a Clariion world, I doubt you'll see any differences from thread>
> Thanks, Andrew. I have not noticed these problems in my own testing
> but this is Clarion City so... Definitely something to investigate
> going forward.
counting. I've driven the test program from 1 to 50 threads, and the
throughput remains a steady high value. Therefore a Clariion should not
suffer from having too many chunks, because it's on-board processor must
schedule the activity to the optimal values.
I don't know Clariion enough to know whether you can deliberately control
which chunks appear on which physical disk (or disk set in the case of RAID)
but if that is reasonable then you should still be able to ensure even
distribution of activity.
My theory about these high-end, optimised disk boxes is that they mask the
disk activity behind very smart caching, so their max throughput will be
throttled back only by the best performance the disks can offer to absorb
the transfers - ie when a queue gets full, it can only accept more requests
as quickly as the queue empties from the other end.
Just setting the underlying disk sets to a chosen RAID configuration will
offer the pure performance that such a configuration is capable of,
unaffected by external influences such as number of IDS chunks.
Andrew Hamm Guest
-
Art S. Kagel #19 Re: High lngspins - IDS 9.30 UC2
On Tue, 21 Oct 2003 20:07:23 -0400, Andrew Hamm wrote:
Yes, fast processor, huge internal cache, excellent algorithms, and very> Art S. Kagel wrote:>>>
>> Thanks, Andrew. I have not noticed these problems in my own testing but this
>> is Clarion City so... Definitely something to investigate going forward.
> In a Clariion world, I doubt you'll see any differences from thread counting.
> I've driven the test program from 1 to 50 threads, and the throughput remains
> a steady high value. Therefore a Clariion should not suffer from having too
> many chunks, because it's on-board processor must schedule the activity to the
> optimal values.
flexible array configuration add up to great sustainable performance. I like
the Clariions. (Hey EMC liked them enough to buy the company!) The Clariion
F4700 is capable of 50,000 cached IOs/sec with a sustainable 350MB/sec reading
through from disk. There are 2 storage processor boards with two processors and
two IO channels each and an array can be configured to distribute requests
across all 4 channels so the throughput, as you have seen, is awesome.
One thing we do to reduce/eliminate the possibility of the Clariion internal> I don't know Clariion enough to know whether you can deliberately control
> which chunks appear on which physical disk (or disk set in the case of RAID)
> but if that is reasonable then you should still be able to ensure even
> distribution of activity.
>
> My theory about these high-end, optimised disk boxes is that they mask the
> disk activity behind very smart caching, so their max throughput will be
> throttled back only by the best performance the disks can offer to absorb the
> transfers - ie when a queue gets full, it can only accept more requests as
> quickly as the queue empties from the other end.
>
> Just setting the underlying disk sets to a chosen RAID configuration will
> offer the pure performance that such a configuration is capable of, unaffected
> by external influences such as number of IDS chunks.
queues backing up is to maximize the number of spindles in use. IMM we
configure 60 drives which as 5 RAID10 arrays of 5 pairs and 10 hot spares.
Then we plaid the 5 stripe sets into one huge array bringing 50 spindles into
any read request and 25 spindle pairs into any write request.
Art
Art S. Kagel Guest
-
Richard Kofler #20 Re: High lngspins - IDS 9.30 UC2
"Art S. Kagel" wrote:
me too would love to test this, but:>
> On Mon, 20 Oct 2003 17:38:27 -0400, Richard Kofler wrote:
>
> Just a brief note: I'd like to see a 6 disk (3pair) RAID10 versus the 4 drive
> RAID5 for apples to apples read performance numbers. As Richard notes, one
> cannot expect 2 RAID10 pairs to out perform the (effectively) 3-data-drive
> RAID5 array.
>
> Art S. Kagel
>
this is an ordinary PC (although consisting of hand selected
parts in the context of a project) and there is only space
for 9 disks :(
4 disks build the RAID10
4+1 spare the 4 disk RAID5
Maybe with serial ATA I can add some sort of cabinet.
The 3 ware ESCALADE controllers actually can support
8 disks each, both types serail or parallel ATA 133.
The latter ones I have now sitting in there.
dic_k
--
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe
Richard Kofler Guest
Reply With QuoteSimilar Questions and Discussions
Posting Permissions
- You may not post new threads
- You may post replies
- You may not post attachments
- You may not edit your posts
