Re: shmmax sizing recommendations

I highlight three points in your message: ORA-4030, 11g, HugePages. You probably already know that to use HugePages in 11g you need to turn off AMM by setting memory_target to 0. Can you double check? Make sure SGA *is* using HugePages, otherwise you would squeeze the memory available for not only SGA but also PGA to a small number.

I have a note about HugePages:

http://yong321.freeshell.org/oranotes/HugePages.txt

> In the past I have set SHMMAX to either 1) the physical ram or 2)
> theoretical limit. Since this is simply an upper limit, it really
> has no performance "hit" for setting it too high.

I remember Jim Mauro in his "Solaris Internals" 1st ed says shmmax is just a number checked to see if you attempt to create a shared memory segment larger than that. There's no other use. So there's no danger setting it too large. I think it's the same on Linux. Here's my setting:

[oracle_at_dctrpcora1a ~]$ sysctl kernel.shmmax kernel.shmmax = 4294967296
[oracle_at_dctrpcora1a ~]$ ssh dctrpcora1b /sbin/sysctl kernel.shmmax kernel.shmmax = 68719476736

On both RHEL boxes, I have only 4 GB physical RAM. But I tested setting shmmax to 68 GB on one of them without any issue.

> There is some overhead in having multiple shared memory segments vs.
> a single one (for any given instance) but I dont have any numbers
> in my pocket to qualify that.

Steve Adams in his O'Reilly book says having multiple fragments in a shared memory segment slightly slows down instance startup and server process creation, with no other negative impact. But if you have very frequent process creations, it's better to have one big shared memory segment.

Yong Huang       

--
http://www.freelists.org/webpage/oracle-l