RE: Do user processes apply against shmmax limit?

Jay,

I would suggest that your SA look at the 'w' column under procs. This shows that _since_ UNIX restart 23 jobs were continuously in the wait queue. Maybe something starts up on system reboot...

>procs memory page disk
> r b w swap free re mf pi po fr de sr s2 s4 s4 sd in
> 0 0 23 4366736 97528 1 2186 16 12 12 95520 0 0 0 0 0 1104
> 0 0 23 4365992 96056 1 451 16 24 52 85968 3 0 0 0 0 935
> 0 0 23 4364712 95512 2 310 36 24 492 85968 68 0 0 0 0 1036

Also, could he show you 'sar -q' stats? This should show any swapping (as opposed to paging).

John Kanagaraj
Oracle Applications DBA
DB Soft Inc
Work : (408) 970 7002

Listen to great, commercial-free christian music 24x7x365 at http://www.klove.com

• The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers **

>-----Original Message-----
>From: Miller, Jay [mailto:JayMiller_at_TDWaterhouse.com]
>Sent: Saturday, November 23, 2002 10:49 AM
>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: John Kanagaraj
  INET: john.kanagaraj_at_hds.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).