SUMMARY: kernel settings / tuning

From: Adam.Bentley@eme.co.uk
Date: Tue Jan 21 2003 - 10:13:54 EST


My thanks to the following:

Pat O'Brien
Mark Deiss
Andy Pavitt
Johan Brusche

All of you confirmed what I thought regarding making changes (ie. avoid updating
the kernel config directly). Had some interesting stuff (esp. regarding oracle -
thanks Mark) and some manual pages I'd not come accross before (thanks Johan)

SOME RESPONSES:
---------------------------------------------------

I know of no xref list between sysconfig and kernel params names.
`man sys_attrs_proc` may be of some use.

As for a rule of thumb for maxusers, below what sys_check uses for it's
advise:

     vmmanagepg = "managed pages from `vmstat -P`"

        vmmanagepgsz=`expr $vmmanagepg '*' 8` # in KB
        memsize1=`expr $vmmanagepgsz / 1024` # in MB
# Max in V4 is 4096
        desiremxu="2048"
        if [ $memsize1 -lt 2048 ]; then
                desiremxu="1024"
        fi
        if [ $memsize1 -lt 1024 ]; then
                desiremxu="512"
        fi
        if [ $memsize1 -lt 512 ]; then
                desiremxu="256"
        fi
        if [ $memsize1 -lt 256 ]; then
                desiremxu="128"
        fi

        if [ $desiremxu -gt $maxusers ]; then
                warnmsg 56 WARNING
# Increase the value of maxusers ( $maxusers ) to at least $desiremxu

______SOME INTERESTING ORACLE STUFF_____________

Not aware of any definitive document... you may find something on the
documentation CD. Dr. Blinn will of course direct you to something or other.

For setting the kernel for your oracle/bespoke.... a lot will depend on how
many oracle instances you will be running, how many associated bespoke
instances, what will be the SGA sizes of your Oracle instances. We have one
"cluster" here of two GS-60s, two ES-40s, one ES-45 running around 24 oracle
instances and a nebulous assortment of BEA/Tuxedo/Jolt and Peoplesoft
process schedulers/application servers. Some of the Peoplesoft instances are
also running over on NT servers. Kernel tuning will typically be a moving
target as your application mix and oracle database settings evolve. Best
thing to do is get some performance trending in place to help you tune
kernel values over time.

Anyways, I don't think your maxusers will be so much a tuning requirement as
your max_proc_per_user and some of your shared memory settings. For
performance purposes, you will want to have your oracle DBAs realistically
set the SGA size(s). Based on those value(s) it tends to be more efficient
to size your maximum shared memory segment size to be able to support your
SGA in one memory segment. This is rough - if you have one monster SGA
(production) and a lot of smaller SGAs (development), then you may want to
size so the monster takes several and your developments are ensured to only
use one.

Without tuning shared memory you can run into a problem of running out of
shared segments so new processes cannot not start even though you have a lot
of unused memory (our boxes tend to run upwards of 8 GB of RAM). Having a
overly large max share size does not hurt you as a smaller allotment will be
grabbed for smaller demand processes. You can see this by monitoring your
shared memory via ipcs command. Oh yeah, sometimes if your application comes
down improperly, the shared memory segment may not have been released - so
look for segments owned by your oracle and bespoke accounts with zero
attachments. At least with oracle, if you have some shared memory still in
use, you may run into problems restarting the downed instance.

The max_proc_per_user comes into play as oracle tends to fork a lot of
support processes per instance. So if you have multiple instances - you will
need to have this upped to support the process load. We have ours set at
256. We have our maxusers set at 2048 - don't recall this ever being a
concern. I am not familiar with your Bespoke application. Something also to
keep in mind is that some application suites on start up have additional
processes started initially then throttle back to a minimum process count
that may increase per demand (sort of like http processes for a web server).
You will want to pad your settings to allow for possible peak demands. An
example of this may be a transaction log flusher that wakes up to process
that area. If you don't allow for something like this, your application may
become hung.
     The performance trending comes into play for this. We had an
incident on one server where the oracle account ran out of processes for a
short period of time. Our trending indicated that there was a very large
jump in the number of zombie processes per the number of total processes.
This indicated that oracle had a runaway process that was not efficiently
acknowledging the terminated sub-processes. In this case, increasing the
process count per the system error messages would have been incorrect.

And lastly, you can run the Compaq utility /usr/sbin/sys_check - if you do
not have this installed, you can grab it from the Compaq ftp site. Should be
at version 1.29+. This package when run by root will create a html (or
ascii) file containing analysis of your hardware, software, kernel settings,
ad nauseum. It polls everything imaginable. It will generate some rough
recommendations on tuning settings. Take these tuning recommendations as a
starting point - do not just implement them without careful review.
     Be careful running sys_check for the first time - it would be best
to tweak down some of the tests initially. I am always leery of it's usage
of hsxterm/hsxterm5 against the storage farms. If your system configuration
is the least bit funky, running sys_check can generate all kinds of errors
in your binary.errlog/messages/syslog files so note the time window you ran
sys_check.

________MY ORIGINAL QUESTION________________

Subject: kernel settings / tuning

Hi all,
               a couple of quickies. Is there any documentation which
describes
the mapping between entries in the kernel config and those listed in
/etc/sysconfigtab and dxkerneltuner? I've been sent some settings from a 3rd
party and I think they've got their wires crossed as they are quoting stuff
like

set maxdsiz to <some value> in the kernel config

and then later on saying

set max-per-proc-data-size to <some other value> in /etc/sysconfigtab

I am guessing but I think these two refer to same parameter.. if anyone
knows of
a doc which shows all the naming conventions for these kernel subsystems can
they direct me to it...

I am certain that editing of the kernel config these days has been
deprecated
and all edits should really go into /etc/sysconfigtab which takes precedence
over the kernel config file when reading settings anyway...

Secondly I was wondering about setting of maxusers (normally you'd define
this
based on the amount of physical memory in your box). I have an ES40 model 2
with
4gb of RAM, same for swap and 2 x 833mhz ev6-7 cpus.

It will be running oracle and a bespoke app.

What what be a recommened setting for Maxusers under a configuration of this
sort? Is there a good rule of thumb for this kind of stuff...

many thanks...

---------------------

cheers Adam.

___________________________ Disclaimer Notice __________________________
This message and any attachments are confidential and should only be read
by those to whom they are addressed. If you are not the intended recipient,
please contact us, delete the message from your computer and destroy any
copies. Any distribution or copying without our prior permission is
prohibited.

Internet communications are not always secure and therefore the Powergen
Group does not accept legal responsibility for this message. The recipient
is responsible for verifying its authenticity before acting on the
contents. Any views or opinions presented are solely those of the author
and do not necessarily represent those of the Powergen Group.

Registered address:

East Midlands Electricity Distribution plc,
Westwood Way, Westwood Business Park, Coventry, CV4 8LG
Registered in England & Wales No. 2366923.



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:04 EDT