Re: Discontiguous SGA under Solaris 2.5.1? Why?

The way Oracle is linked by default on Solaris limits SGA size to 256M. You need to change the sgabeg symbol in ksms.s and relink. This is easy to do - tech support can give you documentation.

My experience with tstshm has been that it's unreliable and I wouldn't use it. You can get a pretty good picture of how your shared memory is allocated with ipcs -am.

I'm not sure of the precise meaning of those /etc/system parameters, but I think shmmax is the TOTAL per-process allocation allowed, and it can be a single segment or multiple segments, depending on what's available.

Personally, I think if you are trying to allocate 360M to you SGA on a 512M machine, you are going to have problems. I like to see SGA size limited to about 1/3 or so of physical memory if possible. However, depending on what else you're doing on the machine, it might work, try it and see.

Make sure you have at LEAST 1 G of swap,and spread it across a bunch of spindles, 'cause it's likely it's going to get hit hard.

/*+
The opinions expressed are my own and do not necessarily reflect those of Oracle Corporation
+*/
:
: On 18 May 1997 15:27:11 -0400, reynolds_at_vu-vlsi.ee.vill.edu (Jim
: Reynolds) wrote:
:
: >We're running Oracle 7.3.2 on a two processor Sun Ultra 2 with 512MB RAM.
: >Here are some parameters from /etc/system:
: >
: >set shmsys:shminfo_shmmax=402653184
: >set shmsys:shminfo_shmmni=100
: >set shmsys:shminfo_shmseg=10
: >
: >Is 384 MB the largest size of the shared memory space, or the largest size
: >of a single segment of shared memory (of which there can be up to 10).
: >
: >Either way, we have a 60MB SGA and would like to have around 300MB of
: >buffer cache. The problem is that we're stuck at ~256MB, and the shared
: >memory usage refuses to go any higher(i.e. oracle won't start up). So we
: >ran tstshm-- the output is very confusing, and I'm wondering if it's even
: >working correctly:
: >
: >Number of segments gotten by shmget() = 50
: >Number of segments attached by shmat() = 10
: >Segments attach at lower addresses
: >Maximum size segments are not attached contiguously!
: > Segment separation = -2621440 bytes
: >Default shared memory address = 0xef300000
: >Lowest shared memory address = 0xfff80000
: >Highest shared memory address = 0xef300000
: >Total shared memory range = -279445504
: >Total shared memory attached = 20971520
: >Largest single segment size = 2097152
: >Segment boundaries (SHMLBA) = 8192 (0x2000)
: >
: >This seems to indicate that oracle is only using ~20MB of shared memory,
: >which is not the case-- it's more like 256MB. And it also appears that
: >oracle is getting 2MB chunks of memory, as opposed to one large chunk
: >which it should.
: >
: >Here's the output from ipcs -mb:
: >
: >Shared Memory:
: >m 600 0x0b21b0d5 --rw-rw---- oracle dba 256040960
: >
: >That's about as high as we can get it (to within 1%) that will still
: >allow oracle to start. You'll notice that the memory addresses don't jive
: >with what tstshm is reporting. And neither do the sizes. Also, oracle
: >reports multiple segments while ipcs reports a single one.
: >
: >We're going to try increasing the number of segments from 10 to 100, and
: >we susepct that will allow us to further increase the SGA. However, I'd
: >like to understand why a) oracle is grabbing small chunks of memory and b)
: >how to read the output of tstshm (an oracle command) so that it makes
: >sense.
: >
: >Any help would be appreciated. Thanks.
: >
: >Jim.
:
Received on Sun May 25 1997 - 00:00:00 CDT