SUMMARY: Oracle shared mem params - DU 4.0B

From: Judith Reed <jreed_at_AppliedTheory.com>
Date: Mon, 25 Aug 1997 15:04:27 -0400

Thanks to all the folks who sent info on oracle shared memory parameters
for Oracle v7.3.*, DU 4.0B, and apologies for lateness of summary - the
disk corruption that resulted from trying to *find* the values of the
params by installing dxkerneltuner sort of preempted my remembering
to summarize!!

In the end, we ended up setting:
                shm-max: 80% of our physical memory size
                shm-mn: 1
                shm-mni: 100
                shm-seg: 1
=====================================================================
From: "Flack, Peter" <flackp_at_bestwestern.com>

First a caveat - we are running 3.2 not 4.0, so I am not sure of the
differences in the shared memory area...

I think some of these questions depend on whether or not you are using
the gh-chunks shared memory enhancements. If you have set gh-chunks so
that your SGA will fit into shared memory (i.e. memory that is not
managed by the system VM system), then ORACLE will perform better -
especially for large numbers of users and large SGA sizes. We use an
SGA of almost 1.5GB, by using 12 128MB shared memory segments. We set
our shmmax to 134217728 (which is 128MB in bytes), we have gh-chunks set
to 384 (each chunk is 4MB). This means that each process only has to
map 12 page table entries on connecting to the database to map the SGA.
We use 12 chunks instead of 1 large one as we have an ASE environment
and some smaller databases use smaller SGA sizes - so they use some
number of 128MB chunks. I don't understand the 80% rule. ORACLE in
their VLM tuning guide recommends msg-mni to be at 1024 - we have not
played with shm-mni - so it is at the default of 128. Our shm-seg is
set to 52 (from earlier days of testing - it used to be 32 and we have
never turned it back - shouldn't have any effect if it large enough).
There is no shm-mns that I can find using sysconfig.

The advantages of using the shared memory segments are that processes
map MANY fewer pages to map the SGA and that all of shared memory is a
single contigous chunk that gets a physical to virtual mapping with a
single translation buffer entry - which means that it will almost always
be in the translation buffer and speeds up all virtual to physical
translations (don't have to flush the buffer as often due to TB misses).
=========================================================================
From: Alex_Nord_at_jabil.com
        To see what your current values are, try :
     
     sysconfig -q ipc
     
     
     Then, you can use sysconfigdb to modify the values (or add entries to
     your /etc/sysconfigtab file). Following is one of the things we added
     to our /etc/sysconfigtab file when we installed Oracle (DU 4.0, not
     even sure on the Oracle version).
     
     ipc:
        shm-max=67108864
        ssm-threshold=0
========================================================================
From: "Vipin Gokhale, DEC SBU, Oracle Corporation" <VGOKHALE_at_us.oracle.com>
 
 General thumb rule is to set shmmax to size of largest SGA the database is
configured for. Round that size up to next higher multiple of 8MB.
 
Other parameters should not need any changes. If shmmax is set correctly,
database will allocate just one segment big enough to hold all of SGA. Else if
shmmax is under configured, SGA will be created out of multiple (upto 30)
smaller segments.
 
Assumption is that physical memory on the machine is sized to be atleast 1.5
times size of the SGA the database will use.
========================================================================
From: Julian Rodriguez <RodrigJUL_at_mail.dec.com>

>is the unit of shmmax in bytes ? Yes
>how does one find/define the maximum number of shared memory segs ?Edit
>/etc/sysconfigtab, and change/add the shm-mni entry within the ipc
>subsystem, set to the value you want.
>how does one find/define the maximum number of segs a user can att.?Edit
>/etc/sysconfigtab, and change/add the shm-seg entry within the ipc subsystem,
>set to the value you want.
>shmmns - ?Edit /etc/sysconfigtab, and change/add the num-of-segs entry within
>the ipc subsystem, set to the value you want.
============================================================================
From: franx_at_oas.telstra.com.au (franXoSAURus reX)

1. The site I work at has an AlphaServer 2100 5/375 running Digital UNIX
3.2c (upgrading to 4.0b) with 640 Meg. of RAM, with RAIDsets on a Digital
StorageWorks HSZ40 Controller in a dual-redundant configuration.
 
We are running ORACLE7 RDBMS Instances under Ver. 7.1.6.2.0 and Ver.
"Oracle7 Server Release 7.2.2.4.0 with the 64-bit option - Production
Release", and are currently upgrading to ORACLE 7.3.2.3..

We are running 3 instances, currently all on different versions of the
ORACLE RDBMS, with a kernel built with the following parameters:

(this is a snip from the config file that was used to build the kernel
we are currently running)

maxusers 256
maxuprc 1024
semmni 40
semmns 500
semmsl 50
semume 40
shmmax 125829120
# i.e. 120 Meg.
#
shmmni 200
shmseg 64

2. My reading of the ORACLE performance tips UNIX is that you should make your
SGA contiguous (and memory resident) by making shmmax as big as your largest
SGA of any database instance that you have running; we actually had the case
where we upgraded to three(3) "EV5" cpu boards, and the database systems ran
slower!! Performance was restored when we sat down worked out that bits of the
SGA of our ORACLE instances were being paged out, built a kernel where shmax
would allow the SGA to be accomated in one shared segment..

3. Try to maximise the size of your SGA by tweeking the "db_block_buffers"
ORACLE RDBMS initialization parameter, giving your database writers more
buffer space to do their updates, keep more indexes in memory, etc..
(if you still not happy with performance, install more RAM and alter your
kernel and ORACLE init. parms accordingly).

> - ? is the unit of shmmax in bytes ?

Yes, shmmax is in bytes.

> - ? how does one find/define the maximum number of shared memory segs ?

I'm not sure I understand the question,
the UNIX command "ipcs" will tell you currently what is in use,
(the ORACLE utility "tstshm" also provides useful info),
to "define" it you edit the config file, build a kernel and boot it.
see the man page "doconfig(8)".

>
> shmseg - number mem. segments a user process can attach - DBA says "set this
> to
> maximum number of shared memory segments a user process can attach"
> - ? how does one find/define the maximum number of segs a user can att.?
>

Ditto.
========================================================================
From: Oisin McGuinness <oisin_at_sbcm.com>

Running sysconfig -q ipc on our DU4.0b system produces:

ipc:
msg-max = 8192
msg-mnb = 16384
msg-mni = 64
msg-tql = 40
shm-max = 471859200 <---- shmmax
shm-min = 1
shm-mni = 128
shm-seg = 32
sem-mni = 16
sem-msl = 25
sem-opm = 10
sem-ume = 10
sem-vmx = 32767
sem-aem = 16384
num-of-sems = 60
max-kernel-ports = 29399
port-hash-max-num = 1469950
port-reserved-max-num = 29399
set-max-num = 3333
ssm-threshold = 0
ssm-enable-core-dump = 1

We set shm-max for Sybase in /etc/sysconfigtab. Do man on sysconfig and
sysconfigtab.
Its much nicer to use sysconfig than rebuilding the kernel; you will still
need to reboot
though. The Kernel config/Sysadmin manual may explain some of the parameters.
Received on Mon Aug 25 1997 - 22:36:54 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:36 NZDT