Cent OS: How do I turn off or reduce memory overcommitment, and is it safe to do it?

Solution 1:

Memory overcommit can be disabled by vm.overcommit_memory=2

0 is the default mode, where kernel heuristically determines the allocation by calculating the free memory compared to the allocation request being made. And setting it to 1 enables the wizardry mode, where kernel always advertises that it has enough free memory for any allocation. Setting to 2, means that processes can only allocate up to a configurable amount (overcommit_ratio) of RAM and will start getting allocation failure or OOM messages when it goes beyond that amount.

Is it safe to do so, no. I haven't seen any proper use case where disabling memory overcommit actually helped, unless you are 100% certain of the workload and hardware capacity. In case you are interested, install kernel-docs package and go to /Documentation/sysctl/vm.txt to read more, or read it online.

If you set vm.overcommit_memory=2 then it will overcommit up to the percentage of physical RAM configured in vm.overcommit_ratio (default is 50%).

echo 0/1/2 > /proc/sys/vm/overcommit_memory 

This will not survive a reboot. For persistence, put this in /etc/sysctl.conf file:


and run sysctl -p. No need to reboot.

Solution 2:

Totally unqualified statement: Disabling memory overcommit is definitely "safer" than enabling it.

$customer has it set on a few hundred web servers and it helped with stability issues a lot. There's even a Nagios check calling out fire real loud if it's ever NOT disabled.

On the other hand, people might not consider it "safe" getting their processes going out of memory when they'd just like to overcommit a little ram and would never really use that. (i.e. SAP would be a very good example)

So, you're back to seeing if it improves things for you. Since You're already looking into it to get rid of related issues - I think it might help for you.

(I know I'll risk a downvote by some grumpy person)

Solution 3:

I agree that disabling overcommit is safer than enabling it in some circumstances. If the server runs only few large memory jobs (like circuit simulations in my case), it is much safer to deny the application the memory request upfront rather than waiting for an OOM event (which is sure to follow shortly) Quite often we see servers having issues after the OOM killer has done its work.