| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: SHMMAX setting with multiple instances? Solaris 2.8,Oracle 8.1.7.4
Ah, ok got it!
However, if your SGA is larger than physical memory, so bits of the SGA = have to swap in and out of RAM, I think you have bigger problems than = ISM being disabled....;-)
-Mark
Mark J. Bobak
Oracle DBA
ProQuest Company
Ann Arbor, MI
"Imagination was given to man to compensate him for what he is not, and =
a sense of humor was provided to console him for what he is." --Horace =
Walpole
-----Original Message-----
From: Tanel P=F5der [mailto:tanel.poder.003_at_mail.ee]=20
Sent: Wednesday, February 18, 2004 5:55 AM
To: oracle-l_at_freelists.org
Subject: Re: SHMMAX setting with multiple instances? Solaris 2.8,Oracle =
8.1.7.4
Hi!
Actually I got what you said right. I just wanted to complement it with =
my
understanding of few ISM issues.
ISM automatically locks all pages to physical memory (even without =
lock_sga
parameter), for performance reasons like sharing pagetable entries, =
better
usage of CPU cache and speeding up context switches etc, thus you can't =
have
ISM segments allocated with total size bigger than your physical RAM. So =
if
you tried to do it, I think you got an error message if _use_ism was =
true.
Otherwise ISM wasn't just used and you got a lot of paging and =
performance
hit when SGA was becoming fully utilized (there might have been the
optimization, that if your SGA consisted of several shared segments, =
then
ISM was used for the ones which "fit" into physical memory, but I'm not =
sure
about that).
In 9i, with dynamic SGA resizing (and dynamic domain reconfiguration in
Sun's high-end servers like E15000), you might well want to have your
sga_max_size larger than current physical memory seen by OS. That's =
probably
one of the reasons why there is dynamic ISM (DISM) starting from =
Solaris8.
This allows you to allocate ISM segments without locking them to =
physical
memory, you even can lock only parts of segments, keeping unused parts
unlocked.
When you start up an instance on Solaris, then if your sga_max_size is
smaller or equal to memory required by all SGA components, then ISM is =
used.
When sga_max_size is set larger than total memory needed by SGA =
components,
then DISM is used and parts of shared segments can be locked and =
unlocked
depending on Oracle's need for them.
ISM is generally claimed to be faster than DISM, because it can't have
paging (is sharing PTE's etc..).
Tanel.
> Tanel,
>
> I think you misunderstood what I was trying to say. What I was trying =
=3D
> to say was, there was (is?) a rumour floating around that if your SGA =
=3D
> was broken up into multiple shared memory segments, then ISM would not =
=3D
> be used. In other words, if SHMMAX was set to, for example, 64MB, and =
=3D
> you created a 200MB SGA, there would need to be four chunks of shared =
=3D
> memory, 64MB, 64MB, 64MB, and 8MB. The rumour stated that the fact =
that =3D
> the SGA was in multiple segments would cause ISM to be disabled. That =
=3D
> is not true.
>
> What do you mean by "locked" into memory? Does this have to do with =
the =3D
> lock_sga paramter? I have databases that have lock_sga=3D3Dfalse that =
are =3D
> using ISM. (8.1.7.4 on Solaris 8)
>
> -Mark
>
>
> -----Original Message-----
> From: Tanel P=3DF5der [mailto:tanel.poder.003_at_mail.ee]
> Sent: Friday, February 13, 2004 5:17 PM
> To: oracle-l_at_freelists.org
> Subject: Re: SHMMAX setting with multiple instances? Solaris =
2.8,Oracle
> 8.1.7.4
>
>
> ISM can't be used for those segments which can't be locked into =
memory,
> because ISM segments can never be paged out. But it'd be stupid to =3D
> create a
> SGA larger than RAM anyway, thus this isn't really an issue...
>
> Tanel.
>
> ----- Original Message -----
> From: "Bobak, Mark" <Mark.Bobak_at_il.proquest.com>
> To: <oracle-l_at_freelists.org>
> Sent: Friday, February 13, 2004 9:06 AM
> Subject: RE: SHMMAX setting with multiple instances? Solaris =
2.8,Oracle
> 8.1.7.4
>
>
> > Er, regarding ISM, what I meant to say was:
> > The rumor states that unless your SGA is in one contiguous shared =
=3D
> memory =3D3D
> > segment, Solaris won't use ISM. That is false. ISM will be used =
=3D3D
> > regardless of whether the SGA is broken into multiple shared memory =
=3D
> =3D3D
> > segments.
> >
> > -Mark
> >
> > -----Original Message-----
> > From: Bobak, Mark=3D3D20
> > Sent: Friday, February 13, 2004 10:53 AM
> > To: oracle-l_at_freelists.org
> > Subject: RE: SHMMAX setting with multiple instances? Solaris =3D
> 2.8,Oracle
> > 8.1.7.4
> >
> >
> > Carmen,
> >
> > SHMMAX determines the largest size a single shared memory segment =
can =3D
> =3D3D
> > =3D3D3D
> > be. It does NOT govern the total amount of shared memory that can =
be =3D
> =3D3D
> > =3D3D3D
> > allocated, just the max allowable size of a single chunk.
> >
> > The value you show, 4,294,967,295 (shown w/ commas to demonstrate =
it's =3D
> =3D3D
> > =3D3D3D
> > 4GB-1, not 400MB) is fine. In a 32 bit
> > environment, 4GB is the largest amount of memory that a program can =
=3D
> =3D3D3D
> > address, since 2^32=3D3D3D3D4GB.
> >
> > So, if your Oracle installation is 32-bit code, that value is more =
=3D
> than =3D3D
> > =3D3D3D
> > enough. Even if it was 64-bit code, and you specified an SGA larger =
=3D
> =3D3D3D
> > than 4GB, having SHMMAX set to 4,294,967,295 would not harm you. =
You =3D
> =3D3D
> > =3D3D3D
> > would just see that your SGA was made up of multiple shared memory =
=3D
> =3D3D3D
> > segments. (Do 'ipcs -m' on Solaris to see all the shared memory =
=3D3D3D
> > segments.) Note that there has been a vicious rumor that Solaris =
must =3D
> =3D3D
> > =3D3D3D
> > have your entire SGA in a single shared memory segment, if ISM =3D
> (Intimate =3D3D
> > =3D3D3D
> > Shared Memory) would be disabled. This is NOT TRUE. There is no =
harm =3D
> =3D3D
> > =3D3D3D
> > in having your SGA in multiple shared memory segments.
> >
> > Bottom line, you should go ahead with:
> > set shmsys:shminfo_shmmax=3D3D3D3D4294967295
> >
> > and forget about it. You'll be fine, and it won't cause you any =
=3D3D3D
> > problems.
> >
> > -Mark
> >
> > -----Original Message-----
> > From: Carmen Rusu [mailto:carmen.rusu_at_rrc.state.tx.us]
> > Sent: Friday, February 13, 2004 9:57 AM
> > To: mgogala_at_adelphia.net; oracle-l_at_freelists.org
> > Subject: Re: SHMMAX setting with multiple instances? Solaris =3D
> 2.8,Oracle
> > 8.1.7.4
> >
> >
> > Here's from Sun Tech support. Does it make any sense to you? To me, =
it
> > doesnt :-(
> >
> >
> > > customer. I wouldset=3D3D3D20
> > > shmmax=3D3D3D3DTHE_HIGHEST_NUMBER_OF_BYTES_TO_BE_USED_BY_THE_SGA+ =
some =3D
> =3D3D
> > extra
> >
> > > head room.
> > >=3D3D3D20
> >
> > Carmen Rusu
> >
> > >>> mgogala_at_adelphia.net 2/13/2004 7:31:05 AM >>>
> >
> > On 02/13/2004 08:17:14 AM, Carmen Rusu wrote:
> > > Oracle install guide recommends the minimum value
> > >=3D3D3D20
> > > set shmsys:shminfo_shmmax=3D3D3D3D4294967295
> > >=3D3D3D20
> > > How does this number depend on the the available physical RAM on =
the
> > > box?
> > >=3D3D3D20
> > > Does this number depend on the number of instances on the box ?
> > >=3D3D3D20
> > > Did you experiment with this setting? Horror stories?
> > >=3D3D3D20
> > > Thanks,
> > >=3D3D3D20
> > > Carmen Rusu
> > >
> >
> > Carmen, the number in question is 400MB and it is the maximum
> > size of a shared memory segment on Slowaris. It also represents
> > the largest SGA that oracle can construct in a single piece.
> > It doesn't have any direct impact on your RAM unless you really =3D
> =3D3D3D20
> > allocate the SGA.
> >
> > --=3D3D3D20
> > Mladen Gogala
> > Oracle DBA
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: =
oracle-l-request_at_freelists.org=3D3D3D20
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/=3D3D3D20
> > FAQ is at =
http://www.freelists.org/help/fom-serve/cache/1.html=3D3D3D20> > FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> > -----------------------------------------------------------------
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/
> > FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> > -----------------------------------------------------------------
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/
> > FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> > -----------------------------------------------------------------
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Wed Feb 18 2004 - 10:16:10 CST
 |
 |