Quote:
Originally Posted by rabbit00
CommitLimit: 6144212 kB
Committed_AS: 5452660 kB
|
That suggests another possible problem.
Try
Code:
sysctl vm.overcommit_memory
That displays a value 0, 1 or 2 for the behavior of your system when memory is over committed.
Note sysctl is normally in /sbin so if you aren't root it likely won't be in your path. But it can run (read only) as non root. If the earlier command is not found try
Code:
/sbin/sysctl vm.overcommit_memory
If the value is 2, that may explain your problem.
Many programs reserve large amounts of anonymous memory that they aren't using and probably never will use. The Committed_AS statistic is the total of all that reserved memory whether currently in use or not. As you can see, on your system the amount reserved is about 3.5GB bigger than the amount used.
If vm.overcommit_memory is set to 2, then the kernel requires unused swap space to cover all of the reserved but unused anonymous memory. You have only a little over 3.5GB of unused swap space, so if processes reserve a little more anonymous memory the system would stop permitting them to reserve any beyond that. That could be the hang you're seeing.
Normally vm.overcommit_memory is set to 0, meaning the system requires unused swap space that is only a fraction of the reserved but unused anonymous memory. That makes sense because programs tend to reserve a lot of anonymous memory they won't actually use.
If the current setting is 2, you could set vm.overcommit_memory to 0 to get the ordinary behavior, or you could even set it to 1, which tells it to never refuse to reserve memory. Then you would get failures from too little memory only when all the memory is actually used, not when it is just reserved.
But since disk space is cheap, you might prefer to just increase the size of the swap space. Even though that swap space wouldn't actually get used, its existence allows Linux to reserve more anonymous memory.
To change vm.overcommit_memory, you must be root
Code:
sysctl vm.overcommit_memory=0
