Home > Uncategorized > Setting shmmax, shmall oracle

Setting shmmax, shmall oracle

If you get an ORA-27102 “out of memory” raised when creating a database, the most common problem is that the database is trying to request more shared memory than your operating system will allow.

Even if you follow the pre-reqs in the installation manuall, you might get this creating databases with large SGA.

Calculate SHMALL

The value of SHMALL determines the maximum amount of memory that all shared memory can use.

Max shared memory = shmall * page_size

You can get page_size issuing the command getconf:

mylinux$ getconf PAGE_SIZE
4096

So if you have a system with 32GB RAM, you might want a large sga with at least 10G. SGA resides in the shared memory. So lets set SHMALL to 10GB.

10*1024*1024*1024=107374182240 (10Gb in bytes)

107374182240/4096=2621440

SHMMAX

Contiguous shared memory for an application in bytes. Set this to the maximum size you will allow one oracle process to use.

10737418240 = 10GB

dari http://www.pythian.com/news/245/the-mysterious-world-of-shmmax-and-shmall/

 

The mysterious world of shmmax and shmall

Over the Top Tales from the trenches.
Motto: Bringing order to the chaos of every day DBA life.

Dear Diary,

Today I delved into the internal workings of Linux kernel memory settings.
A recalcitrant machine would not allow me to open a second newly created instance due to ORA-27102 “out of memory”.
I determined using free that there was in fact 16 Gigabytes of fresh free RAM available, and this was linux x86_64 from uname -a.
So no jumping through hugepage hoops to get a 32 bit OS to allow a 32 bit db address more than 1.7 Gig.
So what was the story, I wondered…
Do I ring the bat phone on the desk and ask a SA (System Admin) or Unix admin as we call them here, and get the answer in a jiffy, handed on a plate?

No, you can only learn by pushing the envelope, lifting that little extra weight, growing that bit taller to reach the sun using whatever fertiliser required, google and metalink are good starts.

I walked my well worn path to the sage of metalink, payed homage and received enough info (Note:301830.1) to begin the journey to discovering how linux kernel shared memory settings affect Oracle.

Like Soviet central planners there are two important settings. Like most people I knew about shmmax, but it is sly, it is not the maximum amount of memory which can be allocated, it is the maximum size of any shared memory chunk.
Shmmax is how big a bite you want per bite from free memory.
The real godfather, the wizard behind the curtain is shmall. Its value determines the maximum amount of memory that ALL shared memory can take.
Just to make it fun, the actual setting is derived…
the maximum amount of memory = shmall * pagesize
where pagesize = getconf PAGE_SIZE and shmall = cat /proc/sys/kernel/shmall

Making shmall larger than free RAM is a recipe for paging hell and much gnashing of teeth. Oracle recommends half the RAM, we pushed the envelope and chose 75% as 8 gigabytes of free for OS and cache is just wasteful.
Especially given Oracle is already caching hot blocks in its memory.

Happy days and the 2nd and 3rd instance had plenty of room to startup and become managed standbys… a story for another day.

Boiled down to one sentence summary:
shmall determines the total amount of shared memory to be allocated using its value multipled by the OS pagesize.

Have Fun

Paul

Categories: Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: