CentOS - May 2012 - Setting overcommit_memory=2 kills system

Hello,

In general I am in the habit of turning off memory overcommit because I
believe it's a bad thing in a multi-user environment.   This was never a
problem on rhel5 systems, but on rhel6, I am having issues.    When I try
to set overcommit_memory=2, my system locks up.   It basically behaves as
if the memory is all used up...   I see the same behavior on centos6 or
rhel6.   Following is some output from each platform.

# --   RHEL6
# uname -a
Linux joker 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64
x86_64 x86_64 GNU/Linux

#lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseWorkstation
Description:    Red Hat Enterprise Linux Workstation release 6.2 (Santiago)
Release:        6.2
Codename:       Santiago

# free
             total       used       free     shared    buffers     cached
Mem:       2052176     234828    1817348          0      15352     112852
-/+ buffers/cache:     106624    1945552
Swap:      2052088          0    2052088

# sysctl -a |grep commit
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.nr_overcommit_hugepages = 0
# sysctl -w vm.overcommit_memory=2
vm.overcommit_memory = 2
# ls
-bash: fork: Cannot allocate memory
#

#--- CENTOS6 --------------------------
# uname
-a
Linux joker 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64
x86_64 x86_64 GNU/Linux

# lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:    CentOS release 6.2 (Final)
Release:        6.2
Codename:       Final

# free
             total       used       free     shared    buffers     cached
Mem:       2052176     378668    1673508          0      19472     252576
-/+ buffers/cache:     106620    1945556
Swap:      2052088          0    2052088

# sysctl -a |grep commit
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.nr_overcommit_hugepages = 0
# sysctl -w vm.overcommit_memory=2
vm.overcommit_memory = 2
[root at joker ~]# ls
-bash: fork: Cannot allocate memory

One last point.   If I set the overcommit values in /etc/sysctl.conf and
then reboot, the values get set correctly on boot and everything seems
fine.   In addition I can then change the value of overcommit_memory to 0
and back to 2 with out any ill affects.

Searches for issues with setting overcommit_memory=2 haven't turned up
anything useful..


Thanks.
-- 
-MichaelC

On Thu, 2012-05-17 at 13:08 -0600, Michael Coffman wrote:
> vm.overcommit_ratio = 50
                                         ^^

Try changing the commit ratio to a greater value (yes you can go over
100).
Then sysctl -w vm.overcommit_memory=2

Just because one machine fails gracefully does not mean the next will.
But really buy some ram for real. OR solve the real problem.



John