linux 内存分配限制,overcommit_memory 2

诡异场景:

当你发现程序在申请大段内存的时候，发生申请失败。

这时候你通过查看free -g发现free下的内存还有大量可以使用的内存。

然后你再继续查看ulimit -a的时候，却发现max memroy size为不受限。

这时候你或许会很疑惑，为什么在足够内存的情况下，当申请内存达到一定量的时候，却还是失败呢。

这时候你查看sysctl -a | grep "vm.overcommit_memory",如果你发现值为2,那么问题便是发生在这里了

在我们进行内存申请的时候，如malloc 200m,这时候仅仅是进行内存申请，但实际使用的时候可能仅仅是100m, 意味着有100m并没有真是被分配。

这时候我们通过free 看到使用的也只有100m的内存。但是vm.overcommit_memory其关注的是申请的内存，即200m的内存，这点需要注意。

而vm.overcommit_memory的意思:

0 — 默认设置。内核执行启发式内存过量使用处理，方法是估算可用内存量，并拒绝明显无效的请求。遗憾的是因为内存是使用启发式而非准确算法计算进行部署，这个设置有时可能会造成系统中的可用内存超载。

1 — 内核执行无内存过量使用处理。使用这个设置会增大内存超载的可能性，但也可以增强大量使用内存任务的性能。

2 — 内存拒绝等于或者大于总可用 swap 大小以及 overcommit_ratio<
4000
/span> 指定的物理
RAM 比例的内存请求。如果您希望减小内存过度使用的风险，这个设置就是最好的

值为2下的场景:

公式:CommitLimit = (Physical RAM * vm.overcommit_ratio / 100) + Swap
Physical RAM为当前系统的总物理内存

 vm.overcommit_ratio为物理内存的比例,默认为50

Swap为当前系统的总Swap

可以通过查看

grep -i commit /proc/meminfo

CommitLimit:    73955212 kB

Committed_AS:    kB

这里的CommitLimit为当前系统可以申请的总内存，Committed_AS为当前已经申请的内存，记住是申请。

因此当你的free查看有很多大量可用的内存的时候，实际Committed_AS可能已经申请了大量的内存了，在vm.overcommit_memory 2模式下，后续的程序可以申请的剩余内存

为CommitLimit - Commited_AS了。

而vm.overcommit_memory设置为2一般是建议当Swap大于物理内存的时候才进行设置。

而vm.overcommit_memory一般是设置为0模式的。

因此现在你知道该如何查理这种场景了吧。

参考文章:
https://access.redhat.com/documentation/zh-CN/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-captun.html http://linuxperf.com/?p=102 http://engineering.pivotal.io/post/Virtual_memory_settings_in_Linux_-_The_problem_with_Overcommit/