Re: IDS9.4/AIX5.2 performace degradation
Posted in 2004
I have an IBM Redbook pdf with advices for tunning AIX 5L parameters
for improving performance on DB2 , IDS and Oracle .
I cand send it directly to your email if you want. (3.4 Megabytes).
Regards
----- Original Message -----
From: "Art S. Kagel" <kagel@bloomberg.net>
To: <informix-list@iiug.org>
Sent: Friday, July 23, 2004 8:41 AM
Subject: Re: IDS9.4/AIX5.2 performace degradation
> On Fri, 23 Jul 2004 06:06:52 -0400, Ben Thompson wrote: Dalibor,
>
> I did not see the post that Ben is replying to at all, I am commenting on
> what's below, but if you send me the full posting with the SYSTEM
DESCRIPTION
> and the onstat's I requested, via email I'll look it all over. Ben's
comments
> are mostly well taken. See below.
>
> Art S. Kagel
>
> > Dalibor Krleza wrote:
> >
> > I may have missed it in your long post, but I didn't see anything about
disc
> > layouts or number of CPUs. Also I may have missed it as well but I
couldn't
> > see any output from "onstat -g iof" or "onstat -g iov". I have commented
on
> > your onconfig anyway.
> >
> >> OK Art, I will post these lists. Hope you'll find something. UPDATE
> >> STATISTICS - done. After US recreated all indexes, same thing.
> >>
> >> Everyone else, sorry for long post! I'll try to be short as possible by
> >> kicking all remarks out of lists.
> >>
> >> ***ONCONFIG***
> >>
> >> ROOTNAME rootdbs
> >> ROOTPATH /dev/rlvinfx01
> >> ROOTOFFSET 16
> >> ROOTSIZE 30000> >> MIRROR 0
> >> MIRRORPATH
> >> MIRROROFFSET 0> >> PHYSDBS fizldbs
> >> PHYSFILE 48000
> >> LOGFILES 150
> >> LOGSIZE 2000> >
> > Personally I think your log size is very small although others may have
more
> > of an idea about this than me.
> >
> >> MSGPATH /informix/online.log
> >> CONSOLE /informix/console.log
> >> ALARMPROGRAM /informix/etc/no_log.sh TBLSPACE_STATS 1
> >
> > Try setting this to 0 unless you need the stats.
> >
> >> TAPEDEV /dev/rmt1
> >> TAPEBLK 256
> >> TAPESIZE 209715200
> >> LTAPEDEV /dev/null
> >> LTAPEBLK 32
> >> LTAPESIZE 8388608> >> STAGEBLOB
> >> SERVERNUM 0>
> I do not like using SERVERNUM zero. It works but almost always causes
> problems when you try to bring up a second server. FWIW.
>
> >> DBSERVERNAME kov_dbs
> >> DBSERVERALIASES
> >> DEADLOCK_TIMEOUT 60
> >> RESIDENT 0>
> RESIDENT 1 can be a big performance improvement!
>
>
> > Try setting to 1 or -1.
> >
> >> MULTIPROCESSOR 1
> >> NUMCPUVPS 2> >
> > Comment this out and use VPCLASS - see 9.40 performance guide.
> >
> >> SINGLE_CPU_VP 0
> >> NOAGE 0>
> I don't remember if there is any issue with using NOAGE on AIX, but this
can
> also improve performance if the OS is aggressive about lowering the
priority
> of long running processes. Solaris and especially HPUX are very
aggressive,
> IB AIX is less so, but it can still help, especially if you notice that
> performance is better for a day or so after you bounce the engine.
>
> >> AFF_SPROC 0
> >> AFF_NPROCS 0> >
> > Comment out NOAGE, AFF_* and use VPCLASS - see 9.40 performance guide.
> >
> >> LOCKS 200000
> >> BUFFERS 200000
> >> NUMAIOVPS>
> Looking at the onstat -g iov output in your other post I see that only one
AIO
> VP is normally used. Since you have KAIO enabled and it would seem that
all
> chunks are RAW devices, you do not need all 24 AIO VPs that are being
> automatically allocated for you because you did not set a value here. Set
> this to 4 to 6 (better take Ben's advice and use a VPCLASS....AIO instead
to
> set the number of AIO VPs).
>
>
> > Comment this out and use VPCLASS - see 9.40 performance guide.
> >
> >> PHYSBUFF 32
> >> LOGBUFF 32
> >> CLEANERS 1>
> This may be the reason why you are seeing so many CHUNK writes and
FGwrites.
> See below for my recommendation for LRUS and set CLEANERS >= LRUS to
improve
> LRU cleaning (and as Ben says if you have many disks set it >= numdisks or
> numchunks to improve checkpoint performance.
>
>
> > How many discs are used by IDS for data? Generally speaking Ttis
parameter
> > should be set to the number of discs you use. Any RAID discs that appear
as
> > one disc to the OS count as 1. The 9.40 performance guide has more
> > information.
> >
> >> SHMBASE 0x700000000000000
> >> SHMVIRTSIZE 8000>
> I did not see the onstat -g seg output, but assuming Ben is correct, it
would
> be VERY good to fold the extra virtual segments into the size of the
initial
> segment as AIX does not do well with multiple segments. Also, IMS, AIX
has
> some kind of minimal allocation so that segments < 256MB are rounded up
> internally, it's a waste to make smaller ones.
>
> > You have a lot of shared memory segments. Try increasing this to more
like
> > 80000, rather than 8000. Check then how many segments you have with
onstat> > -g seg. Ideally you want just one but shared memory should not be bigger
> > than it needs to be.
> >
> >> SHMADD 8192
> >> SHMTOTAL 0
> >> CKPTINTVL 300
> >> LRUS 8>
> Given the BR of 9.51 that I calculated from your original post, I'd
increase
> this to at least 16 (avoid 32, 64, and 96 these specific values have
caused
> performance degradation in previous versions and I do not know if it's
been
> fixed since Informix & IBM have never acknowledged the bug). Don't forget
to
> match or exceed the new LRUS value when setting CLEANERS.
>
> >
> > Read up on LRUS in the 9.40 performance guide.
> >
> >> LRU_MAX_DIRTY 2
> >> LRU_MIN_DIRTY 1>
> With values this low you should not be seeing mostly chunk writes and FG
> writes as you are seeing. The only reason I can see would be the single
> CLEANER or it may be that you just do not have enough BUFFERS configured.
If
> I get to see onstat -P and onstat -p output and time since stats were
zero'd
> I can better determine if you need more buffers.
>
> > You may get more throughput if you set these values higher as long as
> > checkpoint times do not get too high.
> >
> >> TXTIMEOUT 0x12c
> >> STACKSIZE 64
> >> DYNAMIC_LOGS 2
> >> LTXHWM 70
> >> LTXEHWM 80
> >> OFF_RECVRY_THREADS 10
> >> ON_RECVRY_THREADS 1
> >> DRINTERVAL 30
> >> DRTIMEOUT 30
> >> DRLOSTFOUND /usr/informix/etc/dr.lostfound CDR_EVALTHREADS 1,2
> >> CDR_DSLOCKWAIT 5
> >> CDR_QUEUEMEM 4096
> >> CDR_NIFCOMPRESS 0
> >> CDR_SERIAL 0,0
> >> CDR_DBSPACE
> >> CDR_QHDR_DBSPACE
> >> CDR_QDATA_SBSPACE
> >> CDR_MAX_DYNAMIC_LOGS 0
> >> BAR_ACT_LOG /usr/informix/bar_act.log BAR_DEBUG_LOG
> >> /usr/informix/bar_dbug.log BAR_MAX_BACKUP 0 BAR_RETRY 1
> >> BAR_NB_XPORT_COUNT 10
> >> BAR_XFER_BUF_SIZE 31> >> RESTARTAB