MySQL启动错误排查

通过查看可以得知在70G的样子。那么这个是如何计算的呢？这个就是上面提到的一个公式。swap+50%的RAM值，50%参数的设定是在overcommit_ratio中设定。

总虚拟内存 = 可用物理内存 × 百分比 + 交换分区

[root@yayundeng 3306]# cat /proc/meminfo | grep MemTotal
MemTotal:       132096808 kB
[root@yayundeng 3306]# 

[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
[root@yayundeng 3306]# 

总虚拟内存=132096808 * 50% + 4095992= 70144396 kB

那么最后的结果就是buffer pool不能超过70144396 kB - 135196 kB=70009200 KB=66G。实际上经过测试，buffer pool只能设置57G。

最后在看看总虚拟内存情况：

CommitLimit：最大可用虚拟内存

Committed_AS：已使用虚拟内存

[root@yayundeng 3306]# cat /proc/meminfo |grep -i commit
CommitLimit:    70144396 kB
Committed_AS:   65539208 kB

那么如果把内核参数vm.overcommit_memory恢复为默认值0，那么将不会受到约束。

echo 0 > /proc/sys/vm/overcommit_memory

参考资料：

http://serverfault.com/questions/606185/how-does-vm-overcommit-memory-work
http://linuxperf.com/?p=102 

总结：

说了这么多，那么为什么要修改内核参数vm.overcommit_memory的值呢？这个是因为这台服务器之前跑过GreenPlum数据库，拿到我手上的时候没有进行重装系统，那么还是建议如果拿到的机器之前跑过其他的业务，那么保险的方法还是重装一下系统，然后再部署自己的业务，不然真的会出现莫名其妙的问题。

MySQL启动错误排查

标签：com   linu   commit   alt   莫名其妙   yun   cat   sys   技术