| 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
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 =
> to say was, there was (is?) a rumour floating around that if your SGA =
> was broken up into multiple shared memory segments, then ISM would not =
> be used. In other words, if SHMMAX was set to, for example, 64MB, and =
> you created a 200MB SGA, there would need to be four chunks of shared =
> memory, 64MB, 64MB, 64MB, and 8MB. The rumour stated that the fact that =
> the SGA was in multiple segments would cause ISM to be disabled. That =
> is not true.
>
> What do you mean by "locked" into memory? Does this have to do with the =
> lock_sga paramter? I have databases that have lock_sga=3Dfalse that are =
> using ISM. (8.1.7.4 on Solaris 8)
>
> -Mark
>
>
> -----Original Message-----
> From: Tanel P=F5der [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 =
> 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 =
> memory =3D
> > segment, Solaris won't use ISM. That is false. ISM will be used =3D
> > regardless of whether the SGA is broken into multiple shared memory =
> =3D
> > segments.
> >
> > -Mark
> >
> > -----Original Message-----
> > From: Bobak, Mark=3D20
> > Sent: Friday, February 13, 2004 10:53 AM
> > To: oracle-l_at_freelists.org
> > Subject: RE: SHMMAX setting with multiple instances? Solaris =
> 2.8,Oracle
> > 8.1.7.4
> >
> >
> > Carmen,
> >
> > SHMMAX determines the largest size a single shared memory segment can =
> =3D
> > =3D3D
> > be. It does NOT govern the total amount of shared memory that can be =
> =3D
> > =3D3D
> > 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
> > 4GB-1, not 400MB) is fine. In a 32 bit
> > environment, 4GB is the largest amount of memory that a program can =
> =3D3D
> > address, since 2^32=3D3D3D4GB.
> >
> > So, if your Oracle installation is 32-bit code, that value is more =
> than =3D
> > =3D3D
> > enough. Even if it was 64-bit code, and you specified an SGA larger =
> =3D3D
> > than 4GB, having SHMMAX set to 4,294,967,295 would not harm you. You =
> =3D
> > =3D3D
> > would just see that your SGA was made up of multiple shared memory =
> =3D3D
> > segments. (Do 'ipcs -m' on Solaris to see all the shared memory =3D3D
> > segments.) Note that there has been a vicious rumor that Solaris must =
> =3D
> > =3D3D
> > have your entire SGA in a single shared memory segment, if ISM =
> (Intimate =3D
> > =3D3D
> > Shared Memory) would be disabled. This is NOT TRUE. There is no harm =
> =3D
> > =3D3D
> > in having your SGA in multiple shared memory segments.
> >
> > Bottom line, you should go ahead with:
> > set shmsys:shminfo_shmmax=3D3D3D4294967295
> >
> > and forget about it. You'll be fine, and it won't cause you any =3D3D
> > 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 =
> 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=3D3D20
> > > shmmax=3D3D3DTHE_HIGHEST_NUMBER_OF_BYTES_TO_BE_USED_BY_THE_SGA+ some =
> =3D
> > extra
> >
> > > head room.
> > >=3D3D20
> >
> > 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
> > >=3D3D20
> > > set shmsys:shminfo_shmmax=3D3D3D4294967295
> > >=3D3D20
> > > How does this number depend on the the available physical RAM on the
> > > box?
> > >=3D3D20
> > > Does this number depend on the number of instances on the box ?
> > >=3D3D20
> > > Did you experiment with this setting? Horror stories?
> > >=3D3D20
> > > Thanks,
> > >=3D3D20
> > > 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 =
> =3D3D20
> > allocate the SGA.
> >
> > --=3D3D20
> > 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=3D3D20
> > put 'unsubscribe' in the subject line.
> > --
> > Archives are at http://www.freelists.org/archives/oracle-l/=3D3D20
> > FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html=3D3D20
> > -----------------------------------------------------------------
> > ----------------------------------------------------------------
> > 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/
> > 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
> -----------------------------------------------------------------
>
-- 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 - 04:55:24 CST
 |
 |