Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Do user processes apply against shmmax limit?

RE: Do user processes apply against shmmax limit?

From: Rich Holland <holland_at_guidancetech.com>
Date: Fri, 29 Nov 2002 05:48:38 -0800
Message-ID: <F001.0050EF14.20021129054838@fatcity.com>


Jay,

My understanding is that the PGA is contained within the SGA, and that shmmax is the "maximum size of a single shared memory segment". If you set shmmax to 256MB and configure 1GB SGA, you should see it allocate 4 shared memory segments for that purpose. Some Unix variants have limitations on the number of shared memory segments which can either be created (AIX) or simultaneously accessed (HP-UX). I haven't done much with Sun in the last few years so don't specifically know of the Solaris limitations, but I'm sure there is probably something there to consider. That's typically why you want to set shmmax as high as you realistically can -- to reduce the NUMBER of segments you need to allocate for shared memory.

Your sysadmin also mentions turning on "priority paging" to give the user processes access to the memory before the file cache (aka buffer cache). Again I'm not sure about Solaris, but AIX and HP-UX both ship with their buffer cache set to something like 10% - 20% of total memory by default, which is a pretty good guess for a generic system when the vendor has no idea what you'll be using it for specifically... however, for large Oracle systems, I typically tune this back a bit, depending on the memory in the system. Normally something in the 2-8% or 3-10% range is sufficient. Remember, Oracle does all it's own buffering via DB_BLOCK_BUFFERS so doesn't really need to rely on the system buffer cache, even using filesystems (of course, raw devices completely bypass the system buffer cache).

You might want to see what he's got the two parameters set to which control the size of the system buffer cache; sometimes reducing that will help quite a bit with paging/swapping.

Rich

> -----Original Message-----
> From: root_at_fatcity.com [mailto:root_at_fatcity.com] On Behalf Of Miller,
Jay
> Sent: Saturday, November 23, 2002 1:49 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Do user processes apply against shmmax limit?
>
> Hi everyone,
>
> I was always under the impression that the only concern with shmmax
was
> that
> it be large enough for the SGA to fit into it. One of my System
> Administrators has just told me that the individual user processes
(i.e.,
> the PGA since we're not using multi-threaded server) get added to the
SGA
> and if that SGA + user processes > shmmax the system will start
swapping.
>
> I haven't found anything to specifically address this issue on
Metalink so
> I
> though I'd throw it open. We've started experiencing system slowdown
and
> he
> says that increasing shmmax could resolve it. I'm skeptical (he also
> suggested increasing SGA to decrease swapping which I told him in no
> uncertain terms was nonsense).
>
> If anyone has a link to a note or white paper I'd appreciate that too.
>
> I've appended his email at the bottom. This slowdown seems to occur
even
> when there's virtually on oracle activity so I'm suspecting some other
> cause.
>
> Thanks,
> Jay Miller
>
>
>
>
> nycsun1 and njsun7 has 6 GB of memory and only 2 GB of share memory.
This
> morning nycsun1 was very slow and I noticed that there was lots of
> swaping.
> see vmstst and iostat below in red:
>
> procs memory page disk faults
cpu
> r b w swap free re mf pi po fr de sr s2 s4 s4 sd in sy cs
us
> sy
> id
> 0 0 23 4366736 97528 1 2186 16 12 12 95520 0 0 0 0 0 1104 3330 974
11
> 8
> 81
> 0 0 23 4365992 96056 1 451 16 24 52 85968 3 0 0 0 0 935 847 416
3
> 1
> 96
> 0 0 23 4364712 95512 2 310 36 24 492 85968 68 0 0 0 0 1036 2183 670
13
> 4
> 84
> 0 0 23 4361568 95488 9 2264 0 76 964 95520 136 0 0 0 0 979 4065 607
12
> 6
> 82
> 0 0 23 4362384 96080 1 6 4 8 8 77376 0 0 0 0 0 975 465 457
2
> 1
> 97
> 0 0 23 4361944 95712 4 730 92 48 532 95520 64 0 0 0 0 1040 1859 734
8
> 3
> 89
> 0 0 23 4360424 95480 4 41 36 40 100 77376 7 0 0 0 0 986 1250 542
6
> 0
> 94
> 0 0 23 4361304 96096 3 264 76 36 88 88496 7 0 0 0 0 1037 942 665
5
> 3
> 92
> 0 0 23 4359680 95784 2 449 4 28 84 95520 8 0 0 0 0 922 1047 374
4
> 1
> 95
> 0 0 23 4359936 95464 2 544 4 20 332 95520 44 0 0 0 0 931 1095 384
2
> 2
> 96
>
> /s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
> 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c2t6d0
> 0.0 34.5 0.0 270.0 0.2 13.8 6.7 399.5 6 44 c5t12d0 --
swap
> disk
> 0.0 34.5 0.0 270.0 0.5 10.7 15.5 309.4 18 39 c5t13d0 --
swap
> disk
>
>
> This shows that the system is not effectively using memory. I suggest
> increasing the share memory to 4 GB so that DBAs can increase their
memory
> usage. Also set priority paging on. Priority paging will give
application
> first priority then free memory will be allocated to file cache(
Solaris
> 2.6
> and 7. Solaris 8 is set dynamically).
>
> * ORACLE CONFIGS
> set shmsys:shminfo_shmmax =2048000000 -- increase to 4096000000
> set shmsys:shminfo_shmmin=1
> set shmsys:shminfo_shmmni=300
> set shmsys:shminfo_shmseg=30
> set semsys:seminfo_semmap=500
> set semsys:seminfo_semmni=200
> set semsys:seminfo_semmns=2000
> set semsys:seminfo_semmsl=1000
> set semsys:seminfo_semmnu=500
> set semsys:seminfo_semume=150
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Miller, Jay
> INET: JayMiller_at_TDWaterhouse.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rich Holland
  INET: holland_at_guidancetech.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Fri Nov 29 2002 - 07:48:38 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US