一般情况下mysql的启动错误还是很容易排查的,但是今天我们就来说一下不一般的情况。拿到一台服务器,安装完mysql后进行启动,启动错误如下:
[img]http://files.jb51.net/file_images/article/201612/2016120416003431.png[/img]
有同学会说,哥们儿你是不是buffer pool设置太大了,设置了96G内存。这明显提示无法分配内存嘛。如果真是这样也就不在这里进行分享了,哈哈。
我的服务器内存是128G。如下图:
[img]http://files.jb51.net/file_images/article/201612/2016120416003432.png[/img]
服务器内存使用情况:
[img]http://files.jb51.net/file_images/article/201612/2016120416003433.png[/img]
那么问题来了,既然还剩如此多的内存,为什么提示无法分配内存??。各位童鞋怎么看?
1. 首先想到会不会是有几条内存坏了?于是运维的同学进行了检查,给我的反馈是硬件一切正常。
2. 把mysql配置参数又检查了一遍,没有发现什么问题,线上一直就是使用这些参数。
3. 又把文件拷贝到另外一台机器,,另外一台服务器可以正常启动(2台机器硬件配置一致)。
那么如果排除硬件问题,mysql配置问题,那么剩下的就只有操作系统的内核参数配置了。于是把两台服务器进行了对比,最终发现了一个内核参数不一致。
[url=http://serverfault.com/questions/606185/how-does-vm-overcommit-memory-work]http://serverfault.com/questions/606185/how-does-vm-overcommit-memory-work[/url]
[url=http://linuxperf.com/?p=102]http://linuxperf.com/?p=102[/url]
总结:
说了这么多,那么为什么要修改内核参数vm.overcommit_memory的值呢?这个是因为这台服务器之前跑过GreenPlum数据库,拿到我手上的时候没有进行重装系统,那么还是建议如果拿到的机器之前跑过其他的业务,那么保险的方法还是重装一下系统,然后再部署自己的业务,不然真的会出现莫名其妙的问题。