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
21 Comments. Leave new
Hi Paul,
After reading the diary, I am start to wondering about the settings for our system. We have 2 databases running on the same RHEL3 box. Total RAM is 6G. The current settins are as follows:
kernel.shmall = 2097152
kernel.shmmax = 2147483648
Right now, for both databases, the sga parameters are as follows:
sga_max_size big integer 1536M
sga_target big integer 1536M
I am thinking of doubling the kernel.shmall parameter (from 2097152 to 4194304), since there 2 databases running on the same server. I’d like to hear your thoughts on this.
Thanks,
Hai
Hi Hai,
If your pagesize is 4096 that setting for kernel.shmall will allow up to 8G to be addressed in a 64 bit OS running 64 bit Oracle. Given you only have 6G of RAM the setting may be better set lower not higher.
Have Fun
Paul
Thanks Paul.
– Hai
[…] pythian.com/blogs/245/the-mysterious-world-of-shmmax-and-shmall […]
Hi Paul,
Just thought that I’d mention that you page size changes
depending of you are using hugepages or not
RHEL 3 – vm.hugetlb_pool
RHEL 4 – vm.nr_hugepages
the default pagesize for Redhat at least is 4K, vs 2048K with hugepages enabled
cat /proc/meminfo |grep Hugepagesize
Thanks
#!/bin/bash
cat /proc/sys/kernel/shmall
TotalKbytes=`awk ‘/MemTotal:/ { print $2 }’ /proc/meminfo`
TotalBytes=`expr $TotalKbytes \* 1024`
PageSize=`getconf PAGE_SIZE`
ShmallValue=`expr $TotalBytes / $PageSize`
echo $ShmallValue
echo $ShmallValue > /proc/sys/kernel/shmall
sysctl -p
cat /proc/sys/kernel/shmall
[…] thought that the SHMMAX kernel parameter (see also Paul Moen’s The mysterious world of shmmax and shmall) was limiting as the SGA size was bigger than SHMMAX size. After changing the SHMMAX parameter, […]
Big Dave,
I notice you’re using all your memory, not half.
This would give a better value for ShmallValue:
ShmallValue=`expr $TotalBytes / $PageSize / 2`
Also, what is a good value for shsmax? A small
multiple of `getconf PAGE_SIZE`?
s/shsmax/shmmax/
[…] and shmmax and shmall Filed under: Linux, Oracle — Sonia @ 5:06 pm A good article on Oracle and shmmax and shmall. In a […]
Hi Paul,
After reading your post, I decide to ask your help.
How do you recommend me to set the params shmmax and shmall if I have 20 Oracle DBs with 256M set max SGA? The server has OEL5.1 x86_64 and 16G RAM.
Thank you.
Just had an interesting query from a client who is trying to increase SGA + PGA memory beyond 12GB on a system with 32GB. If he adds +1GB to any area, the instance is not starting up. Not only it’s not starting, but it’s also not giving any hints, errors or other clues what’s wrong. Alert log just says “Starting ORACLE instance (normal)” and nothing more (it’s 10.2.0.3 RAC).
It boiled down to the possibility that shmall is too small (3279547 ~ 12.5G).
Thanks for the hint Paul!
what is potential harm of having shmmax too high? i noticed on my RAC system i have shmmax = 21474836480 while oracle recommends
“(4 GB – 1 byte), or half the size of physical memory (in bytes), whichever is lower” – we have 34 G RAM. It is 11g and we switched to using hugepages, previously used AMM – upon oracle support recommendation.
thanks,
–george
not 34 G, 32 G of RAM
Dear Paul,
so, from the articel above, we summarized:
server 2 Quad Xeon, 16GB memory
shmmax = 17179869184 (16GB) more than this = hell paging
maximum amount of memory = shmall * pagesize
16GB = shmall * 4096 (default)
shmall = 16GB / 4096 = 4194304 (4MB)
is this right?
“Making shmall larger than free RAM is a recipe for paging hell and much gnashing of teeth.” -> means shmall can be set to max 17179869184? more than that, hell paging?
“Oracle recommends half the RAM, we pushed the envelope and chose 75% as 8 gigabytes of free for OS and cache is just wasteful.” -> recommends shmall or shmmax? if it’s shmmax, why from the formula above i’ve got shmall=4MB even2 farrrrrrrrrrrrrrrrrrrrr from half of memory (8GB)
from Oracle 10g Release 2 Linux x86 documentation
shmmax = Half the size of physical memory (in bytes)
Regards,
Robby
Junior DBA
Revisiting this question. The original author left 4 GB of RAM for Linux and Cache.
Thus, Total RAM – 4 GB RAM = SHMMAX
# As a percent of Physical Memory that is 100% * (1-4GB/Total)
And, SHMALL = SHMAX / PAGE_SIZE
So, for a 64 GB RAM, 64 bit system…
That is 64 GB – 4 GB RAM = 60 GB SHMMAX
ANd, SHMALL = 60 GB / 4096 = 15 MB SHMALL
Any more than that cause paging hell as the Linux Kernel and Cache become involved in potential paging…
If I read this all right, the only adjustment is to make sure that the Linux kernal and cache fit inside that 4 GB. If not make it larger and recompute.
If I have this right, then the basic reason for loading Physical RAM in the first place — reducing the opportunity for paging to occur is met and maximized. Did I get it right?
Oracle has a certified system that has 8GB of physical RAM and 4TB SHMALL setting.
So, it is not, necessarily a ‘recipe for paging hell’. From what I understand, it’s just an upper limit.
Using too much RAM, is a recipe for paging hell, but what do you want to happen, the system to crawl to a halt, or the system to completely stop working with errors. Setting the limit lower, just means you will have the out of memory error.
The long term solution seems to be, don’t use more memory than you need.
With that said, I have had all kinds of problems trying to set a large SGA without getting herky-jerky results on Linux.
But setting this limit lower as desribed in this article, did not change the results for me, and I suspect it isn’t the answer.
See this “oracle validated configuration” here:
https://linux.oracle.com/pls/apex/f?p=102:2:4310916404894033::NO::P2_VC_ID:471
[…] 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. […]
[…] mysterious setting has been explained pretty well here: and am reposting my findings since last time I dealt with these settings, I just solved my problem […]
> 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.
That’s not true. SHMMAX determines the amount in bytes a process can allocate in its process space. SHMALL is the setting for the system.