On 11/03/07, Leonardo Vilela Pinheiro leopinheiro@gmail.com wrote:
Hi,
I'm sorry for a so big email, but this might be a bug.
As some of you may know, there is a characteristic of malloc called overcommit, which lets a program "allocate" more virtual memory than is available on the system. I've set overcommit_memory=2 and turned off swap, but I believe the behaviour of malloc is not the expected.
...
Conditions: Kernel: 2.6.9-42.0.10.ELsmp RAM memory: 2GB Swap: OFF overcommit_memory=2 (changed by me) overcommit_ratio=50 (default)
' free ' yields: total used free shared buffers cached Mem: 2065252 602872 1462380 0 12372 283248 -/+ buffers/cache: 307252 1758000 Swap: 0 0 0
There is about 1.4GB free RAM memory.
Then I've executed the test code got: malloc 178 MB - (nil) Returned null
According to the kernel document above: "The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM. Depending on the percentage you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate."
Shouldn't I have got something about 1000 MB instead of 178 MB, because 1000 MB is 50% of physical memory? As long as I have 1.4GB free, I should be able to allocate those 1000 MB. Are there other (configurable or not) limits for memory allocation? (ulimit is not being used)
I think the memory available with overcommit_memory=2 is for system as a whole, not individual processes ...
You need to increase the overcommit_ratio number to get more memory - strangely this number can be greater than 100
James Pearson