Optimizing a BaaN installation
A DBA inherited a BaaN IV / Informix 9.21 system on NT4 (4 CPUs, 4 GB RAM, three RAID5 sets) where nearly all objects sat in one dbspace with ~50 chunks and tiny default extents, and performance was terrible; the local BaaN distributor claimed fragmenting or moving tables would break BaaN. Posters disputed that (BaaN has an inf_storage file for per-table storage), and suggested spreading data/indexes over multiple dbspaces, extra temp dbspaces, raising BUFFERS, CLEANERS, LRUS, RA_PAGES, RESIDENT/NOAGE, tuning DD_/DS_ cache parameters, fixing LTAPEDEV (no log backups), moving rootdbs off C:, and replacing RAID5 with RAID 1+0. No confirmed outcome is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi,
i'm just starting in an enterprise that has BaaN IV c with the
following specifications:
Server:
3 RAID5 (with 4 disks each one)
4 processors
4Gb Ram
OS: NT4
DataBase: Informix 9.2x (i don't remeber the exact number right now :)
The enterprise has a dbspace called baandbs and all the Informix
objects created in that dbspace, the size of the extents for all the
objects is default (16k) and about 50 chunks (the chunks are created
almost in a random fashion between 2 of the RAID's)
they have a dbspace rootdbs, one for physcal logs, one for logical
logs, and one temp...
they have about 11 tables in the range of 1 to 4 millions rows, and 28
table between 500000 and 999999 rows.
Total they has 12900 tables in use and the total instalation is about
119000 tables big
Obviously the performance is not just bad... it really sucks...
one of the things i tought of was create more dbspaces and ALTER
FRAGMENT some tables
to put some tables in one dbspaces some tables in other dbspace in
other RAID and FRAGMENT BY EXPRESSION (or ROUND ROBIN) some big
tables...
But from BaaN's distributor says that BaaN will scream if i do
something like that... they give to me a procedure to defragment the
databases but because of the size of the database here it seems very
impractical or at least a procedure that cannot be done once a month,
not even once every six months...
so, please give me some advices in how to optimize this monster....
regards,
Jaime Casanova
PS: here i provide my actual ONCONFIG.. i haven't touched it, yet... :)
# Root Dbspace Configuration
ROOTNAME rootdbs # Root dbspace name
ROOTPATH C:\\IFMXDATA\\ol_server\\rootdbs_dat.000 # Path for devicecontaining root dbspace
# Path for device containing root
dbspace
# Path for device containing root
dbspace
# Path for device containing root
dbspace
ROOTOFFSET 0 # Offset of root dbspace into device
(Kbytes)
ROOTSIZE 20480 # 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 baandb_plog # Location (dbspace) of physical log
PHYSFILE 409600 # Physical log file size (Kbytes)# Logical Log Configuration
LOGFILES 20 # Number of logical log files
LOGSIZE 102400 # Logical log size (Kbytes)# Diagnostics
MSGPATH C:\\Informix\\online.log # System message log file path
CONSOLE C:\\Informix\\console.log # System console message path
ALARMPROGRAM C:\\Informix\\etc\\log_full.bat # Alarm program path
#ALARMPROGRAM NUL # Alarm program path
TBLSPACE_STATS 1 # Maintain tblspace statistics ***
# System Archive Tape Device
#TAPEDEV NUL # Tape device path
TAPEDEV \\\\.\\TAPE0 # Tape device path
TAPEBLK 512 # Tape block size (Kbytes)
TAPESIZE 24000000 # Maximum amount of data to put on tape
(Kbytes)# Log Archive Tape Device
LTAPEDEV NUL # Log tape device path
LTAPEBLK 16 # Log tape block size (Kbytes)
LTAPESIZE 1363148 # Max amount of data to put on log tape
(Kbytes)
# OpticalSTAGEBLOB # INFORMIX-OnLine/Optical staging area
# System Configuration
SERVERNUM 0 # Unique id corresponding to a OnLineinstance
DBSERVERNAME ol_server # Name of default Dynamic Server
DBSERVERALIASES # List of alternate dbservernames#07sep03 NETTYPE soctcp,3,100,NET # Override sqlhosts nettype
parameters
NETTYPE soctcp,4,100,NET # Override sqlhosts nettype parameters
#07sep03
DEADLOCK_TIMEOUT 60 # Max time to wait of lock indistributed env.
RESIDENT 0 # Forced residency flag (Yes = 1, No =
0)
MULTIPROCESSOR 1 # 0 for single-processor, 1 formulti-processor
#07sep03 NUMCPUVPS 3 # Number of user (cpu) vps
NUMCPUVPS 4 # Number of user (cpu) vps #07sep03
#VPCLASS CPU,NUM=3 #Recom.Rob.Machare
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vpsto one
NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor#07sep03 AFF_NPROCS 3 # Affinity number of
processors
AFF_NPROCS 4 # Affinity number of processors
#07sep03# Shared Memory Parameters
LOCKS 600000 # Maximum number of locks#14sep03BUFFERS 52413 # Maximum number of shared
buffers
BUFFERS 90000 # Maximum number of shared buffers
#14sep03 Recom.F.Sliva#NUMAIOVPS 1 # Number of IO vps
#07sep03 NUMAIOVPS 20 #4X#DISCOS
#NUMAIOVPS 48 #4X#DISCOS #07sep03
NUMAIOVPS 4 #14sep03 Recom.F.Sliva
#VPCLASS AIO,NUM=20 #Recom.Rob.Machare#PHYSBUFF 256 # Physical log buffer size (Kbytes)
#14sep03PHYSBUFF 384 # Physical log buffer size
(Kbytes) #FSILVA08nov02
PHYSBUFF 512 # Physical log buffer size (Kbytes)
#14sep03 Recom.F.Sliva
LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 235 # Maximum number of logical log files
#CLEANERS 4 # Number of buffer cleaner processes
#CLEANERS 5 # NUMERO DE DISCOS EN EL RAID
#07sep03 CLEANERS 6 # NUMERO DE DISCOS EN EL RAID #CFAB17feb03
CLEANERS 12 # NUMERO DE DISCOS EN EL RAID #07sep03
SHMBASE 0xc000000 # Shared memory base address#SHMVIRTSIZE 327680 # initial virtual shared memory
segment size
SHMVIRTSIZE 655360 # initial virtual shared memory segmentsize (CFAB08abr02:para asignar inicialmente la memoria requerida en un
dia)
SHMADD 163840 # Size of new shared memory segments
(Kbytes) (CFAB08abr02:como antes de 20ago01)#SHMADD 327680 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LRUS 8 # Number of LRU queues
LRU_MAX_DIRTY 12 # LRU percent dirty begin cleaninglimit
LRU_MIN_DIRTY 8 # LRU percent dirty end cleaning limit#LTXHWM 50 # Long transaction high water mark
percentage
#LTXEHWM 60 # Long transaction high water mark
(exclusive)
LTXHWM 40 # Long transaction high water markpercentage
LTXEHWM 70 # Long transaction high water mark
(exclusive)
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 32 # Stack size (Kbytes)# System Page Size
# BUFFSIZE - OnLine no longer supports this configuration parameter.
# To dete
Jaime Casanova wrote:
> Hi,
>
> i'm just starting in an enterprise that has BaaN IV c with the
> following specifications:
>
> Server:
> 3 RAID5 (with 4 disks each one)
> 4 processors
> 4Gb Ram
>
> OS: NT4
>
> DataBase: Informix 9.2x (i don't remeber the exact number right now :)
>
> The enterprise has a dbspace called baandbs and all the Informix
> objects created in that dbspace, the size of the extents for all the
> objects is default (16k) and about 50 chunks (the chunks are created
> almost in a random fashion between 2 of the RAID's)
>
> they have a dbspace rootdbs, one for physcal logs, one for logical
> logs, and one temp...
>
One quick and innocent way to get SOME performance back would be to add
a couple more temporary dbspaces.
> they have about 11 tables in the range of 1 to 4 millions rows, and 28
> table between 500000 and 999999 rows.
>
> Total they has 12900 tables in use and the total instalation is about
> 119000 tables big
>
> Obviously the performance is not just bad... it really sucks...
>
> one of the things i tought of was create more dbspaces and ALTER
> FRAGMENT some tables
> to put some tables in one dbspaces some tables in other dbspace in
> other RAID and FRAGMENT BY EXPRESSION (or ROUND ROBIN) some big
> tables...
>
> But from BaaN's distributor says that BaaN will scream if i do
> something like that... they give to me a procedure to defragment the
> databases but because of the size of the database here it seems very
> impractical or at least a procedure that cannot be done once a month,
> not even once every six months...
>
>
Can you do a table or two each weekend?
> so, please give me some advices in how to optimize this monster....
>
> regards,
> Jaime Casanova
>
>
> PS: here i provide my actual ONCONFIG.. i haven't touched it, yet... :)
>
>
> # Root Dbspace Configuration
> ROOTNAME rootdbs # Root dbspace name
> ROOTPATH C:\\IFMXDATA\\ol_server\\rootdbs_dat.000 # Path for device> containing root dbspace
> # Path for device containing root
> dbspace
> # Path for device containing root
> dbspace
> # Path for device containing root
> dbspace
> ROOTOFFSET 0 # Offset of root dbspace into device
> (Kbytes)
> ROOTSIZE 20480 # 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 baandb_plog # Location (dbspace) of physical log
> PHYSFILE 409600 # Physical log file size (Kbytes)> # Logical Log Configuration
> LOGFILES 20 # Number of logical log files
> LOGSIZE 102400 # Logical log size (Kbytes)> # Diagnostics
> MSGPATH C:\\Informix\\online.log # System message log file path
> CONSOLE C:\\Informix\\console.log # System console message path
> ALARMPROGRAM C:\\Informix\\etc\\log_full.bat # Alarm program path
> #ALARMPROGRAM NUL # Alarm program path
> TBLSPACE_STATS 1 # Maintain tblspace statistics ***>
> # System Archive Tape Device
> #TAPEDEV NUL # Tape device path
> TAPEDEV \\\\.\\TAPE0 # Tape device path
> TAPEBLK 512 # Tape block size (Kbytes)
> TAPESIZE 24000000 # Maximum amount of data to put on tape
> (Kbytes)> # Log Archive Tape Device
> LTAPEDEV NUL # Log tape device path
> LTAPEBLK 16 # Log tape block size (Kbytes)
> LTAPESIZE 1363148 # Max amount of data to put on log tape
> (Kbytes)
> # Optical> STAGEBLOB # INFORMIX-OnLine/Optical staging area
> # System Configuration
> SERVERNUM 0 # Unique id corresponding to a OnLine> instance
> DBSERVERNAME ol_server # Name of default Dynamic Server
> DBSERVERALIASES # List of alternate dbservernames> #07sep03 NETTYPE soctcp,3,100,NET # Override sqlhosts nettype
> parameters
> NETTYPE soctcp,4,100,NET # Override sqlhosts nettype parameters
> #07sep03
> DEADLOCK_TIMEOUT 60 # Max time to wait of lock in> distributed env.
> RESIDENT 0 # Forced residency flag (Yes = 1, No =
> 0)
> MULTIPROCESSOR 1 # 0 for single-processor, 1 for> multi-processor
> #07sep03 NUMCPUVPS 3 # Number of user (cpu) vps
> NUMCPUVPS 4 # Number of user (cpu) vps #07sep03
> #VPCLASS CPU,NUM=3 #Recom.Rob.Machare
> SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps> to one
> NOAGE 0 # Process aging
> AFF_SPROC 0 # Affinity start processor> #07sep03 AFF_NPROCS 3 # Affinity number of
> processors
> AFF_NPROCS 4 # Affinity number of processors
> #07sep03> # Shared Memory Parameters
> LOCKS 600000 # Maximum number of locks> #14sep03BUFFERS 52413 # Maximum number of shared
> buffers
> BUFFERS 90000 # Maximum number of shared buffers
Looks like you have the memory, so you could increase BUFFERS up to ...
250,000??? (i.e. to keep below 1.75 Gig 'cos of NT things).
> #14sep03 Recom.F.Sliva
> #NUMAIOVPS 1 # Number of IO vps
> #07sep03 NUMAIOVPS 20 #4X#DISCOS
> #NUMAIOVPS 48 #4X#DISCOS #07sep03
> NUMAIOVPS 4 #14sep03 Recom.F.Sliva
> #VPCLASS AIO,NUM=20 #Recom.Rob.Machare> #PHYSBUFF 256 # Physical log buffer size (Kbytes)
> #14sep03PHYSBUFF 384 # Physical log buffer size
> (Kbytes) #FSILVA08nov02
> PHYSBUFF 512 # Physical log buffer size (Kbytes)
This is large in comparison to your LOGBUFF - why?
If anything perhaps just set them both to 64 each.
> #14sep03 Recom.F.Sliva
> LOGBUFF 32 # Logical log buffer size (Kbytes)> LOGSMAX 235 # Maximum number of logical log files
> #CLEANERS 4 # Number of buffer cleaner processes
> #CLEANERS 5 # NUMERO DE DISCOS EN EL RAID
> #07sep03 CLEANERS 6 # NUMERO DE DISCOS EN EL RAID #CFAB17feb03
> CLEANERS 12 # NUMERO DE DISCOS EN EL RAID #07sep03
> SHMBASE 0xc000000 # Shared memory base address> #SHMVIRTSIZE 327680 # initial virtual shared memory
> segment size
> SHMVIRTSIZE 655360 # initial virtual shared memory segment> size (CFAB08abr02:para asignar inicialmente la memoria requerida en un
> dia)
> SHMADD 163840 # Size of new shared memory segments
> (Kbytes) (CFAB08abr02:como antes de 20ago01)> #SHMADD 327680 # Size of new shared memory segments
> (Kbytes)
> SHMTOTAL 0 # Total shared memory (Kbytes).
> 0=>unlimited
> CKPTINTVL 300 # Check point interval (in sec)
> LRUS
In addition to some good recommendations of TBP...
Since this is Baan and the # of tables is as usual incredible you
may want to set also DS_HASHSIZE and DS_POOLSIZE
in onconfig.
see old article from Art:
--------
DS_HASHSIZE is the number of hash list and must be a prime number.
It defaults to 31 in IDS 7.21->7.31.
DS_POOLSIZE is the number of entries in each hash list. It defaults to
50 in IDS 7.21->7.24 and 127 in IDS 7.31.
--------
set them bigger.
Superboer.
Christian Knappke schreef:
> In addition to some good recommendations of TBP...
>
> From the keyboard of "Jaime Casanova" <systemguards@gmail.com>:
>
> > Hi,
> >
> > i'm just starting in an enterprise that has BaaN IV c with the
> > following specifications:
> >
> > Server:
> > 3 RAID5 (with 4 disks each one)
> > 4 processors
> > 4Gb Ram
> >
> > OS: NT4
> >
> > DataBase: Informix 9.2x (i don't remeber the exact number right
> > now :)
> >
> > The enterprise has a dbspace called baandbs and all the Informix
> > objects created in that dbspace, the size of the extents for all
> > the objects is default (16k) and about 50 chunks (the chunks are
> > created almost in a random fashion between 2 of the RAID's)
>
> Parallel archives are parallel only on dbspace level. With this
> one dbspace only approach there is no parallel archive. If your
> archive extends into the daytime it slows down online processing.
> I'd distribute the data over several dbspaces.
>
> [...]
>
> > But from BaaN's distributor says that BaaN will scream if i do
> > something like that...
>
> Seems that they don't know much about Informix :-)
>
> > they give to me a procedure to defragment
> > the databases but because of the size of the database here it
> > seems very impractical or at least a procedure that cannot be
> > done once a month, not even once every six months...
>
> [...]
>
> > ROOTPATH C:\\IFMXDATA\\ol_server\\rootdbs_dat.000 # Path
>
> This is the system disk. Presumably it also contains the swap
> file. No good idea IMHO to put the rootdbs on his particular disk.
>
> [...]
>
> > MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
>
> For security reasons I'd mirror rootdbs.
>
> [...]
>
> > LTAPEDEV NUL # Log tape device path>
> This is really bad on a production system! You won't be able to
> recover your database in case a restore is necessary. RAID5 will
> not deliver you from it. In case of resore you reset all your work
> to the time of the archive. Everything after that is lost. And
> it's you head that's going to roll...
>
> [...]
>
> > NUMCPUVPS 4 # Number of user (cpu) vps>
> Is this a stand alone database server or is there also BaaN
> running on it. In the latter case I'd allow BaaN to use the CPUs
> too. Reduce to 2.
>
> [...]
>
> > NUMAIOVPS 4 #14sep03 Recom.F.Sliva>
> This is senseless (and ignored) on NT. It is hard coded to 1 and
> just leaves a note in the message log.
>
> [...]
>
> > FILLFACTOR 60 # Fill factor for building>
> This leads to bigger than neccessary indexes. I'd set it to 90.
>
> > LBU_PRESERVE 0 # Preserve last log for log
>
> Set this to 1 after you have fixed LTAPEDEV or you risk the need
> to restore when your log backup procedure fails.
>
> [...]
>
>
> HTH
> Christian
> --
> #include <std_disclaimer.h>
> /* The opinions stated above are my own and not
> necessarily those of my employer. */
ahum getting old... DD_HASHSIZE,DD_HASHMAX Superboer.
Jaime Casanova wrote: > one of the things i tought of was create more dbspaces and ALTER > FRAGMENT some tables > > But from BaaN's distributor says that BaaN will scream if i do > something like that... > It's not true. We have BaaN and we have fragmented tables. And BaaN has a special file called 'inf_storage' where you can set storage options for individual tables.
>> But from BaaN's distributor says that BaaN will scream if i do >> something like that... they give to me a procedure to defragment the >> databases but because of the size of the database here it seems very >> impractical or at least a procedure that cannot be done once a month, >> not even once every six months... > >Can you do a table or two each weekend? > That was my original idea, but their procedure include drop and recreate all tables... the tables are not created with informix (ie: with a script) but the BaaN does the work... and it adds some hash columns for indexing... (don't ask me why BaaN does that when informix has its own indexes)... regards, Jaime Casanova
Well first get a consultant like me in to review things!
I don't believe Baan don't have tools to move individual tables. They
just need to supply them to you.
I change the following ONCONFIG parameters.
RESIDENT to -1 (if you have enough phyiscal memory)
NOAGE to 1CLEANERS to 50 ( I assume "NUMERO DE DISCOS EN EL RAID" means number of
disks in RAID)
As Andrew Hamme has demonstrated you can more than I/O at one to a
drive.
LRUS to 50 (same as CLEANERS).
RA_PAGES to 16
RA_THRESHOLD to 8.
LRU_PRESERVE tp 1.
You need to sort out this disk layout. Query sysmaster:sysextents and
group by dbsname/tabname.
How many extents per table?
Think about recreating indexes in seperate dbspaces.
IF Baan say they have no tools to move individual tables then let me
know (david@smooth1.co.uk) and I'll
kick their arse! I'll also use my IBM contacts to kick them as well.
Do Baan support IDS 10?
Query sysmaster:syscfgtab (sysmaster:sysconfig is a view that hides undocumented paramaters)! There are DS_ parameters (?? Data dictionary caching). DD_ parameters (?? Data distribution caching) PC_ parameters (SPL caching) Check the IDS 10 manuals they document this stuff now!
> ( I assume "NUMERO DE DISCOS EN EL RAID" means number of disks in RAID) good assuption :) > IF Baan say they have no tools to move individual tables then let me know (d...@smooth1.co.uk) and I'll > kick their arse! I'll also use my IBM contacts to kick them as well. not BaaN but my local distributor :( i will try your suggestions....
> Query sysmaster:syscfgtab (sysmaster:sysconfig is a view that hides undocumented paramaters)!
64 DD_HASHSIZE 1 31 31
65 DD_HASHMAX 1 10 10
95 DS_HASHSIZE 1 31 31
96 DS_POOLSIZE 1 127 127
111 DS_MAX_QUERIES 0 1 1 -1
112 DS_TOTAL_MEMORY 0 2048 2048 -1
113 DS_MAX_SCANS 0 1048576 1048576 1048576
> You need to sort out this disk layout.
> Query sysmaster:sysextents and group by dbsname/tabname. How many extents per table?
:) i have tried this query twice before you ask...
select dbsname, tabname, count(*) num_extents, sum(size) num_pages
from sysextents
where dbsname like "baan%"
and tabname not like "%abaan"
and tabname like "t%"
group by tabname, dbsname
into temp tablas;
select * from tablas where num_extents > 8 order by num_extents desc;
and online go down with this message in online.log (online goes down
both times, there where some days between one and the other)
--- extracted from online.log ---
15:48:26 shmdt: errno = 22
15:48:26 out of virtual shared memory
15:48:27 shmat: [ENOMEM][12]: out of available data space, checksystem MAXMEM
--- end extraction ---
onstats
--- onstat -l ---
Informix Dynamic Server 2000 Version 9.21.TC7 -- On-Line -- Up
05:42:25 -- 1078592 Kbytes
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-2 126 128 59804 499 119.85
phybegin physize phypos phyused %used
400035 102400 35643 382 0.37
Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-2 0 8 594111 64514 55846 9.2 1.2
Subsystem numrecs Log Space used
OLDRSAM 594111 72280272
address number flags uniqid begin size used %used
f16012c 1 U-B---- 100264 500035 25600 25600 100.00
f160148 2 U-B---- 100265 506435 25600 25600 100.00
f160164 3 U---C-L 100266 50c835 25600 19960 77.97
f160180 4 U-B---- 100247 512c71 25600 25600 100.00
f16019c 5 U-B---- 100248 519071 25600 25600 100.00
f1601b8 6 U-B---- 100249 51f471 25600 25600 100.00
f1601d4 7 U-B---- 100250 525871 25600 25600 100.00
f1601f0 8 U-B---- 100251 52bc71 25600 25600 100.00
f16020c 9 U-B---- 100252 539835 25600 25600 100.00
f160228 10 U-B---- 100253 532071 25600 25600 100.00
f160244 11 U-B---- 100254 1e00003 25600 25600 100.00
f160260 12 U-B---- 100255 1e06403 25600 25600 100.00
f16027c 13 U-B---- 100256 1e0c803 25600 25600 100.00
f160298 14 U-B---- 100257 1e12c03 25600 25600 100.00
f1602b4 15 U-B---- 100258 1e19003 25600 25600 100.00
f1602d0 16 U-B---- 100259 1e1f403 25600 25600 100.00
f1602ec 17 U-B---- 100260 1e25803 25600 8715 34.04
f160308 18 U-B---- 100261 1e2bc03 25600 25600 100.00
f160324 19 U-B---- 100262 1e32003 25600 25600 100.00
f160340 20 U-B---- 100263 1e38403 25600 25600 100.00
--- end onstat -l ---
--- onstat -p ---
Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
5903183 5970942 113964977 94.82 146394 237159 536689 72.72
isamtot open start read write rewrite delete commit
rollbk
109288380 704431 3592216 91430105 235317 156072 20894 57847
4
gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
0 0 0 0 0 0 0
ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 11571.70 5067.85 58 140
bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
243929 0 8435195 0 0 30 4799 13532
ixda-RA idx-RA da-RA RA-pgsused lchwaits
912854 2 223872 1038680 63158
--- end onstat -p ---
onstat -a, onstat -u and onstat -t are very large to include here so iwill post three other messages with that info
--- onstat -u ---
Informix Dynamic Server 2000 Version 9.21.TC7 -- On-Line -- Up
05:42:45 -- 1078592 Kbytes
Userthreads
address flags sessid user tty wait tout locks nreads
nwrites
25e63018 ---P--D 1 informix - 0 0 0 186
3067
25e63608 ---P--F 0 informix - 0 0 0 0
6379
25e63bf8 ---P--F 0 informix - 0 0 0 0
6436
25e641e8 ---P--F 0 informix - 0 0 0 0
7343
25e647d8 ---P--F 0 informix - 0 0 0 0
6750
25e64dc8 ---P--F 0 informix - 0 0 0 0
8443
25e653b8 ---P--F 0 informix - 0 0 0 0
7780
25e659a8 ---P--F 0 informix - 0 0 0 0
5414
25e65f98 ---P--F 0 informix - 0 0 0 0
5692
25e66588 ---P--F 0 informix - 0 0 0 0
6201
25e66b78 ---P--F 0 informix - 0 0 0 0
5078
25e67168 ---P--F 0 informix - 0 0 0 0
5580
25e67758 ---P--F 0 informix - 0 0 0 0
6232
25e67d48 ---P--- 9 informix - 0 0 0 0
7
25e68338 ---P--B 10 informix - 0 0 0 411
2338
25e68928 ---P--- 28 informix - 0 0 0 11489
0
25e68f18 Y--P--- 32 informix - 2d39bef8 0 1 0
0
25e69508 ---P--D 13 informix - 0 0 0 0
0
25e69af8 ---P--- 16 informix - 0 0 0 0
0
25e6a0e8 ---P--- 17 informix - 0 0 0 0
0
25e6a6d8 ---P--- 18 informix - 0 0 2 0
0
25e6acc8 ---P--- 19 informix - 0 0 0 0
0
25e6b2b8 ---P--- 20 informix - 0 0 1 0
0
25e6b8a8 ---P--- 21 informix - 0 0 1 0
0
25e6be98 ---P--- 22 informix - 0 0 1 0
0
25e6c488 ---P--- 23 informix - 0 0 1 0
0
25e6ca78 ---P--- 24 informix - 0 0 1 0
0
25e6d068 ---P--- 25 informix - 0 0 1 0
0
25e6d658 Y--P--- 31 informix - 26561d08 0 1 0
0
25e6dc48 ---P--- 30 informix - 0 0 1 0
0
25e6e238 Y--P--- 33 informix - 2d39bef8 0 1 0
0
25e6e828 Y--P--- 34 informix - 2d39be10 0 1 105
628
25e6ee18 Y--P--- 35 informix - 2d39be10 0 1 122
593
25e6f408 Y--P--- 36 informix - 2d39bd80 0 2 10374
17817
25e6f9f8 Y--P--- 37 informix - 2d39bd80 0 2 10113
16284
25e6ffe8 Y--P--- 38 informix - 2d39bd80 0 2 6614
11152
25e705d8 Y--P--- 39 informix - 2d39bd80 0 2 8637
13727
25e70bc8 ---P--- 27 informix SERVER_U 0 0 1 0
0
25e711b8 Y--P--- 41 informix - 2d4995a0 0 1 4
1
25e717a8 Y--P--- 40 msandova SERVER 2d4cd960 0 1 1608
516
25e71d98 Y--P--- 42 msandova SERVER 264dc5b8 0 1 525
0
25e72388 Y--P--- 43 msandova SERVER 2d596f10 0 1 20
0
25e72978 Y--P--- 44 msandova SERVER 2d6592d0 0 1 75
0
25e72f68 Y--P--- 45 msandova SERVER 2d691ab0 0 1 114
0
25e73558 Y--P--- 46 msandova SERVER 2d720cd0 0 1 12
0
25e73b48 Y--P--- 47 msandova SERVER 2d2041a8 0 1 303
0
25e74138 Y--P--- 48 msandova SERVER 2d7db238 0 1 44
0
25e74728 Y--P--- 49 msandova SERVER 2d81cfb0 0 1 57
0
25e74d18 Y--P--- 50 msandova SERVER 2d260420 0 1 4038
143
25e75308 Y--P--- 51 msandova SERVER 2d97a068 0 1 781
2
25e758f8 Y--P--- 52 msandova SERVER 2d2f88c8 0 1 13
0
25e75ee8 Y--P--- 53 msandova SERVER 2da26ec8 0 1 6141
149
25e764d8 Y--P--- 54 msandova SERVER 2db2a928 0 1 8807
14
25e76ac8 Y--P--- 1637 mmerchan SERVER 41907780 0 1 237
2
25e770b8 Y--P--- 56 msandova SERVER 2dd1e610 0 1 3378
1210
25e776a8 Y--P--- 1541 ptrujill SERVER 43aadca0 0 1 532
0
25e77c98 Y--P--- 381 spaguay SERVER 376fad18 0 1 529
1
25e78288 Y--P--- 63 dherrera SERVER 2dee51f8 0 1 628
25
25e78878 Y--P--- 64 dherrera SERVER 2e477f60 0 1 382
0
25e78e68 Y--P--- 65 dherrera SERVER 2e4f9760 0 1 324
0
25e79458 Y--P--- 66 oespinoz SERVER 2e53ae90 0 1 53
4
25e79a48 Y--P--- 67 oespinoz SERVER 2e5ba298 0 1 150
0
25e7a038 Y--P--- 68 oespinoz SERVER 2e5fc748 0 1 362
0
25e7a628 Y-BP--- 69 oespinoz SERVER 2e677888 0 1402 37842
258
25e7ac18 Y--P--- 71 smontiel SERVER 2e6f6fd0 0 1 1030
94
25e7b208 Y--P--- 72 smontiel SERVER 2e6c0248 0 1 669
0
25e7b7f8 Y--P--- 73 jvillon SERVER 2e76e6a8 0 1 712
178
25e7bde8 Y--P--- 74 jvillon SERVER 2e7afa90 0 1 121
0
25e7c3d8 Y--P--- 75 jvillon SERVER 2e82bb58 0 1 16507
18
25e7c9c8 Y--P--- 76 jvillon SERVER 2e8fb330 0 1 172
21
25e7cfb8 Y--P--- 77 jvillon SERVER 2e947cc8 0 1 1147
0
25e7d5a8 Y--P--- 78 jvillon SERVER 2e990cf0 0 1 6
0
25e7db98 Y--P--- 79 jvillon SERVER 2ea096a8 0 1 65
0
25e7e188 Y--P--- 80 cloor SERVER 2eaa33d8 0 1 50
9
25e7e778 Y--P--- 81 cloor SERVER 2eadb7c8 0 1 224
0
25e7ed68 Y--P--- 83 mmerchan SERVER 2e6c07c0 0 1 300
66
25e7f358 Y--P--- 84 mmerchan SERVER 2ebf8568 0 1 242
0
25e7f948 Y--P--- 85 mmerchan SERVER 2ec7ce10 0 1 403
0
25e7ff38 Y--P--- 502 msandova SERVER 384dfa98 0 1 1705
592
25e80528 Y--P--- 87 emoreira SERVER 2eddd9b8 0 1 29
0
25e80b18 Y--P--- 88 emoreira SERVER 2ee42db0 0 1 9
0
25e81108 Y--P--- 89 emoreira SERVER 2eeb17f8 0 1 551
0
25e816f8 Y--P--- 90 dherrera SERVER 2ef3b148 0 1 316
8
25e81ce8 Y--P--- 137 ptrujill SERVER 2f2761a8 0 1 4637
1466
25e822d8 Y--P--- 92 emoreira SERVER 2efbfa58 0 1 149
4
25e828c8 Y--P--- 140 aleyton SERVER 2f78dcf0 0 1 141
0
25e82eb8 Y--P--- 1131 vsalavar SERVER 304cfa60 0 1 268
0
25e834a8 Y--P--- 1132 msandova SERVER 40ae8a18 0 1 0
0
25e83a98 Y--P--- 142 crivaden SERVER 2f3d32d8 0 1 742
282
25e84088 Y--P--- 139 aleyton SERVER 2f58a2e8 0 1 549
65
25e84678 Y--P--- 1638 mmerchan SERVER 4209a568 0 1 1
0
25e84c68 Y--P--- 1139 spaguay SERVER 400c35b8 0 1 2733
12
25e85258 Y--P--- 111 ptrujill SERVER 2f9b9a98 0 1 574
507
25e85848 Y--P--- 112 ptrujill SERVER 2f9b9fd0 0 1 84
0
25e85
I forgot something important: i have maximum 37 users concurrents regards, Jaime Casanova
get rid of the RAID 5 and go for RAID 1+0