Oracle shmall shmmax kernel parameters

SHMMAX and SHMALL are two key shared memory parameters that directly impact’s the way by which Oracle creates an SGA. Shared memory is nothing but part of Unix IPC System (Inter Process Communication) maintained by kernel where multiple processes share a single chunk of memory to communicate with each other.

While trying to create an SGA during a database startup, Oracle chooses from one of the 3 memory management models a) one-segment or b) contiguous-multi segment or c) non-contiguous multi segment. Adoption of any of these models is dependent on the size of SGA and values defined for the shared memory parameters in the linux kernel, most importantly SHMMAX.
(zie ook http://padmavyuha.blogspot.nl/2010/12/configuring-shmmax-and-shmall-for.html)

SHMALL sets the total amount of shared memory pages that can be used system wide, in pages.

SHMMAX is the maximum size of a single shared memory segment set in bytes. 

Kernel.shmall (oracle)

kernel.shmall = physical RAM size / pagesize For most systems, this will be the value 2097152. See Note 301830.1 for more information.

# Maximum amount of shared memory (in pages) that

# can be used at one time on the system and should be at

# least ceil(SHMMAX/PAGE_SIZE)

getconf PAGE_SIZE geeft 4096

Dit is dus de minumum value. Beter is groter .

Wijzig ==> set SHMALL= shmmax/page_size= 8589934592/4096 = 2097152

optimal value shmall:

As SHMALL is the total size of Shard Memory Segments System wide, it should always be less than the Physical Memory on the System and should be greater than sum of SGA’s of all the oracle databases on the server. Once this value (sum of SGA’s) hit the limit, i.e. the value of shmall, then any attempt to start a new database (or even an existing database with a resized SGA) will result in an “out of memory” error (below). This is because there won’t be any more shared memory segments that Linux can allocate for SGA.

Setting the value for SHMALL to optimal is straight forward. All you want to know is how much “Physical Memory” (excluding Cache/Swap) you have on the system and how much of it should be set aside for Linux Kernel and to be dedicated to Oracle Databases.

For e.g. Let say the Physical Memory of a system is 6GB, out of which you want to set aside 1GB for Linux Kernel for OS Operations and dedicate the rest of 5GB to Oracle Databases. Then here’s how you will get the value for SHMALL.

Convert this 5GB to bytes and divide by page size. Remember SHMALL should be set in “pages” not “bytes”.

kernel.shmmax (oracle)

kernel.shmmax = 1/2 of physical RAM. This would be the value 2147483648 for a system with 4GB of physical RAM. See Note:567506.1 for more information.

Oracle Global Customer Support officially recommends a " maximum" for SHMMAX of "1/2 of physical RAM".

The maximum size of a shared memory segment is limited by the size of the available user address space. On 64-bit systems, this is a theoretical 2^64bytes. So the "theoretical limit" for SHMMAX is the amount of physical RAM that you have.  However, to actually attempt to use such a value could potentially lead to a situation where no system memory is available for anything else.  Therefore a more realistic "physical limit" for SHMMAX would probably be "physical RAM - 2Gb".

In an Oracle RDBMS application, this "physical limit" still leaves inadequate system memory for other necessary functions. Therefore, the common "Oracle maximum" for SHMMAX that you will often see is "1/2 of physical RAM". Many Oracle customers chose a higher fraction, at their discretion.

Occasionally, Customers may erroneously think that that setting the SHMMAX as recommended in this NOTE limits the total SGA.   That is not true.  Setting the SHMMAX as recommended only causes a few more "shared memory segments" to be used for whatever total SGA that you subsequently configure in Oracle. For additional detail, please see

wijzig ==> set shmmax = 16GB/2=8GB=  8 x 1024x1024x1024= 8589934592

 

optimal value shmmax

Oracle makes use of one of the 3 memory management models to create the SGA during database startup and it does this in following sequence. First Oracle attempts to use the one-segment model and if this fails, it proceeds with the next one which's the contiguous multi-segment model and if that fails too, it goes with the last option which is the non-contiguous multi-segment model.

So during startup it looks for shmmax parameter and compares it with the initialization parameter *.sga_target. If shmmax > *.sga_target, then oracle goes with one-segment model approach where the entire SGA is created within a single shared memory segment.

But the above attempt (one-segment) fails if SGA size otherwise *.sga_target  > shmmax, then Oracle proceeds with the 2^nd option – contiguous multi-segment model. Contiguous allocations, as the name indicates are a set of shared memory segments which are contiguous within the memory and if it can find such a set of segments then entire SGA is created to fit in within this set. 

But if cannot find a set of contiguous allocations then last of the 3 option’s is chosen – non-contiguous multi-segment allocation and in this Oracle has to grab the free memory segments fragmented between used spaces.

So let’s say if you know the max size of SGA of any database on the server stays below 1GB, you can set shmmax to 1 GB. But say if you have SGA sizes for different databases spread between 512MB to 2GB, then set shmmax to 2Gigs and so on.

The idea here is to let Oracle use the efficient one-segment model and for this shmmax should stay higher than SGA size of any individual database on the system.

 

Achtergrondinfo

The SHMMAX parameter is a safeguard parameter that sets the upper limit of how much shared memory a process can possibly request. The maximum supported value of SHMMAX on a 32-bit system is 4 GB - 1 byte.

In other words The SHMMAX kernel parameter defines the upper memory limit of a process. It is a safeguard to stop a bad process from using all memory and causing RAM starvation. The Linux default is 32 MB.

The default PAGE_SIZE in Linux, which also applies to /dev/shm (POSIX) shared memory is 4 KB (4096 bytes). With the introduction of the Linux kernel 2.6, the system can also be configured to use Huge Pages, which uses a page size of 2 MB (2048 kilobyte). Kernel Huge Pages, unlike standard shared memory pages are non-swapable and therefore set and reserved at system startup.
















Oracle 11g database uses Automatic Memory Management (AMM) by default, which relies on /dev/shm. /dev/shm (POSIX shared memory) uses 4 KB pages and is set to 50 % of phsyical memory (RAM), by default. For performance reasons, which can be very drastic depending on how much memory the system has to manage, any Oracle database that uses more than 4 GB of SGA should use kernel Huge Pages.

Shared memory is not the only memory resource a system requires, but it is important for the Oracle Database System Global Area (SGA). If there is insufficient shared memory, the Oracle database instance will not start. Setting the SHMMAX and SHMALL to maximum values therefore disables any possible resource constrains set by the kernel.


Hugepages

As the amount of memory available on systems grows and the amount of memory needed by the database grows the traditional 4k page size used in most Linux systems is becoming a bit too small. As the total memory allocated increases the number of pages that must be managed also increases – meaning more work for the kernel. With HugePages you can increase the typical 4KB page size to something like 2MB. This means that for the same amount of RAM being used your OS will have a multiple of 512 less pages to manage. In addition, with HugePages the pages are pinned in memory and can’t be swapped to disk, thus avoiding possible disk writes. Another key benefit  is that HugePages are managed via a global PageTable rather than every process having its own PageTable – this also reduces the amount of memory needed.


 Hugepages are not compatible with AMM so use with hugepages then ASMM (automatic Shared memory management)

example change from AMM to ASMM

alter system set sga_target=48G scope=spfile sid='*';
alter system set sga_max_size=48G scope=spfile sid='*';
alter system set pga_aggregate_target=16G scope=spfile sid='*';
alter system reset memory_max_target scope=spfile sid='*';
alter system reset memory_target scope=spfile sid='*';