On 11/03/07, Leonardo Vilela Pinheiro <leopinheiro at 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