linux 内存分配参数导致的 buffer_pool 分配不出来的案例排查
linux 内存分配参数导致的 buffer_pool 分配不出来的案例排查
原文地址：http://www.cnblogs.com/gomysql/p/6130405.html
后期参考：http://blog.csdn.net/jollyjumper/article/details/24127009
一台约128G内存的服务器，跑了1个MySQL，设置96G的bufferpool，但提示分配失败。后来发现是内核参数问题。如下：
vm.overcommit_memory
默认值为：0
cat /proc/sys/vm/overcommit_memory
从内核文档里得知，该参数有三个值，分别是：
0：当用户空间请求更多的的内存时，内核尝试估算出剩余可用的内存。【默认值】
1：当设这个参数值为1时，内核允许超量使用内存直到用完为止，主要用于科学计算.
2：当设这个参数值为2时，内核会使用一个决不过量使用内存的算法，即系统整个内存地址空间不能超过swap+50%的RAM值，50%参数的设定是在overcommit_ratio中设定。
具体的描述：
取值为0，系统在为应用进程分配虚拟地址空间时，会判断当前申请的虚拟地址空间大小是否超过剩余内存大小，如果超过，则虚拟地址空间分配失败。因此，也就是如果进程本身占用的虚拟地址空间比较大或者剩余内存比较小时，fork、malloc等调用可能会失败。
取值为1，系统在为应用进程分配虚拟地址空间时，完全不进行限制，这种情况下，避免了fork可能产生的失败，但由于malloc是先分配虚拟地址空间，而后通过异常陷入内核分配真正的物理内存，在内存不足的情况下，这相当于完全屏蔽了应用进程对系统内存状态的感知，即malloc总是能成功，一旦内存不足，会引起系统OOM杀进程，应用程序对于这种后果是无法预测的
取值为2，则是根据系统内存状态确定了虚拟地址空间的上限，由于很多情况下，进程的虚拟地址空间占用远大小其实际占用的物理内存，这样一旦内存使用量上去以后，对于一些动态产生的进程(需要复制父进程地址空间)则很容易创建失败，如果业务过程没有过多的这种动态申请内存或者创建子进程，则影响不大，否则会产生比较大的影响
vm.overcommit_ratio
默认值为：50 【 cat /proc/sys/vm/overcommit_ratio 】
这个参数值只有在vm.overcommit_memory=2的情况下，这个参数才会生效,用于虚拟内存的物理内存的百分比,数据库建议改成10。
那么我们来看一下总的内存地址不能超过多少。其实是可以直接查看的。
[root@yayundeng 3306]# cat /proc/meminfo |grep -i commit
CommitLimit: 70144396 kB 最大可用虚拟内存【就是说mysql的buffer_pool 最大差不多能分配这么多kB的内存空间】
Committed_AS: 135196 kB 已使用虚拟内存
通过查看可以得知在70G的样子。那么这个是如何计算的呢。
具体的70GB的计算方法如下：
最大可分配的虚拟内存(CommitLimit) = 总物理内存(MemTotal) × 百分比(vm.overcommit_ratio) + 交换分区大小(Swap)
对于我们上面这个环境来说，就是下面这个样子：
[root@yayundeng 3306]# cat /proc/meminfo | grep MemTotal
MemTotal: 132096808 kB 总物理内存大约125GB
[root@yayundeng 3306]# free -k
total used free shared buffers cached
Mem: 132096808 1583944 130512864 0 10240 133220
-/+ buffers/cache: 1440484 130656324
Swap: 4095992 0 4095992
[root@yayundeng 3306]# cat /proc/sys/vm/overcommit_ratio
50最大可分配的虚拟内存 = 132096808*50% + 4095992 = 70144396 kB 差不多在70GB ，稳妥的话，设置60GB的buffer_pool即可。
文中作者后来也说了，这台服务器之前跑的是其他服务，设置了vm.overcommit_memory=2，后来作为MySQL服务器使用时候，没有重装系统，直接拿来使用的。因此这种情况下，最好还是重装个干净的系统为好。