From: Hunter, Mark (Mark.Hunter@ANHEUSER-BUSCH.COM)
Date: Mon Jun 30 2003 - 12:14:35 EDT
With maxperm at 10% but current perm at 44.9% means you have lots of memory and
no real use for it so the system has used it to cache. min/max perm just change
the reclaim algorithm. From your stats, the oracle dbas can use more memory for
the SGA. What is their cache hit ratio?
Do not set strict. It can have really nasty side effects.
-----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
<http://marc.theaimsgroup.com/?l=aix-l&r=1&w=2> &r=1&w=2
AIX FAQ at http://www.faqs.org/faqs/aix-faq/ <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