From: Holger.VanKoll@SWISSCOM.COM
Date: Mon Jun 30 2003 - 13:39:16 EDT
never set maxfree to less than minfree+maxpgahead
so, set it to 128+64 and see if that changes something
-----Original Message-----
From: Spencer Johnson [mailto:Spencer.Johnson@2020LOG.COM]
Sent: Monday, June 30, 2003 10:34 AM
To: aix-l@Princeton.EDU
Subject: Re: S85 not quite right !!
Thanks for replies Mark / Simon,
To answer some of your questions :
- Disks are 50% active on average is quite good as this means layout of database is good.
- Our vmtune settings are currently :
vmtune: current values:
-p -P -r -R -f -F -N -W
minperm maxperm minpgahead maxpgahead minfree maxfree pd_npages maxrandwrt
104855 209711 2 64 128 144 524288 0
-M -w -k -c -b -B -u -l -d
maxpin npswarn npskill numclust numfsbufs hd_pbuf_cnt lvm_bufcnt lrubucket defps
1677691 100608 25152 1 93 1584 9 131072 1
-s -n -S -L -g -h
sync_release_ilock nokilluid v_pinshm lgpg_regions lgpg_size strict_maxperm
0 0 0 0 0 0
-t
maxclient
1676868
number of valid memory pages = 2097113 maxperm=10.0% of real memory
maximum pinable=80.0% of real memory minperm=5.0% of real memory
number of file memory pages = 942297 numperm=44.9% of real memory
number of compressed memory pages = 0 compressed=0.0% of real memory
number of client memory pages = 0 numclient=0.0% of real memory
# of remote pgs sched-pageout = 0 maxclient=80.0% of real memory
-------- IBM have also suggest turning sync_release_ilock (s) to 1 and strict_maxperm (h) to 1.
I will be shortly upgrading our Dev server to ML 11, will let you know how I get on.
Spencer
-----Original Message-----
From: Green, Simon [mailto:Simon.Green@EU.ALTRIA.COM]
Sent: 30 June 2003 15:29
To: aix-l@Princeton.EDU
Subject: Re: S85 not quite right !!
The only problems I have experienced - other than an actual shortage of resources - have been due to the wrong vmtune settings. (And remember that the default settings are NOT good for a database.)
It's worth considering AIO as well, but I've never had a problem with that.
The sort of settings I use are:
/usr/samples/kernel/vmtune -p3 -P8 -b400
That's taken from an 8-way S7A with 8GB memory, running SAP with a 750GB database. It's quite busy, but has almost no paging. It's based on our experience and recommendations from SAP.
If you don't have something similar - particularly the -p/-P - then take care of that before tackling anything else.
When you say the disks are "only 50% busy" what do you mean? If that's either I/O Wait or % active then I'd say it's on the high side. What sort of disk subsystem do you have?
Simon Green
Altria ITSC Europe Ltd
AIX-L Archive at http://marc.theaimsgroup.com/?l=aix-l&r=1&w=2
AIX FAQ at http://www.faqs.org/faqs/aix-faq/
N.B. Unsolicited email from vendors will not be appreciated.
-----Original Message-----
From: Spencer Johnson [mailto:Spencer.Johnson@2020LOG.COM]
Sent: 30 June 2003 14:49
To: aix-l@Princeton.EDU
Subject: S85 not quite right !!
Hi list,
I have a slight problem / issue, this is related to an 7017-S85 server, connected to F20 ESS. The server is a 6W - 8 GB RAM running Oracle 8.1.7.4 with
database instance of approx. 1 TB.
The problem is that most operations (coping files, etc) cause the system to page and send the CPU's into Wait state constantly, I have logged a call with IBM and they have
come back with a few suggestions of changing vmtune parameters.
Oracle is tuned to allow for 6W processors but I feel that the O/S is being restricted by something. The disks do not perform that much work (only 50% busy at max).
The O/S is currently at 4.3.3 ML 10, but am considering going to ML 11.
Has anyone out there had similar experiences and how have they been overcome.
***************************************************************
Disclaimer :-
This email is confidential and intended solely for the use of the
individual to whom it is addressed. Any views or opinions are solely
those of the author and do not necessarily represent those of
20:20 Logistics Ltd, Dextra Accessories Ltd,
The Discovery Store Ltd and The Mobile Phone Repair Company Ltd.
If you are not the intended recipient, be advised that you have
received this email in error and that any use, dissemination,
forwarding, printing or copying is strictly prohibited. If you
have received this email in error please delete it from your system
and notify the sender immediately.
***************************************************************
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:58 EDT