MySQL啟動錯誤解決方法

一般情況下mysql的啟動錯誤還是很容易排查的，但是今天我們就來說一下不一般的情況。拿到一臺服務(wù)器，安裝完mysql后進行啟動，啟動錯誤如下：

有同學(xué)會說，哥們兒你是不是buffer pool設(shè)置太大了，設(shè)置了96G內(nèi)存。這明顯提示無法分配內(nèi)存嘛。如果真是這樣也就不在這里進行分享了，哈哈。

我的服務(wù)器內(nèi)存是128G。如下圖：

服務(wù)器內(nèi)存使用情況：

那么問題來了，既然還剩如此多的內(nèi)存，為什么提示無法分配內(nèi)存？？。各位童鞋怎么看？

1. 首先想到會不會是有幾條內(nèi)存壞了？于是運維的同學(xué)進行了檢查，給我的反饋是硬件一切正常。

2. 把mysql配置參數(shù)又檢查了一遍，沒有發(fā)現(xiàn)什么問題，線上一直就是使用這些參數(shù)。

3. 又把文件拷貝到另外一臺機器，，另外一臺服務(wù)器可以正常啟動（2臺機器硬件配置一致）。

那么如果排除硬件問題，mysql配置問題，那么剩下的就只有操作系統(tǒng)的內(nèi)核參數(shù)配置了。于是把兩臺服務(wù)器進行了對比，最終發(fā)現(xiàn)了一個內(nèi)核參數(shù)不一致。

mysql啟動正常的服務(wù)器改參數(shù)的值是0，而mysql啟動錯誤的這臺服務(wù)器該值是2。

那么問題來了，這個參數(shù)到底是什么鬼？竟然會讓mysql分配內(nèi)存失敗，最后導(dǎo)致無法啟動。經(jīng)過查詢資料知道了vm.overcommit_memory是什么鬼。

vm.overcommit_memory

默認(rèn)值為：0
從內(nèi)核文檔里得知，該參數(shù)有三個值，分別是：
0：當(dāng)用戶空間請求更多的的內(nèi)存時，內(nèi)核嘗試估算出剩余可用的內(nèi)存。
1：當(dāng)設(shè)這個參數(shù)值為1時，內(nèi)核允許超量使用內(nèi)存直到用完為止，主要用于科學(xué)計算.
2：當(dāng)設(shè)這個參數(shù)值為2時，內(nèi)核會使用一個決不過量使用內(nèi)存的算法，即系統(tǒng)整個內(nèi)存地址空間不能超過swap+50%的RAM值，50%參數(shù)的設(shè)定是在overcommit_ratio中設(shè)定。

vm.overcommit_ratio
默認(rèn)值為：50

這個參數(shù)值只有在vm.overcommit_memory=2的情況下，這個參數(shù)才會生效。

那么我們來看一下總的內(nèi)存地址不能超過多少。其實是可以直接查看的。

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

通過查看可以得知在70G的樣子。那么這個是如何計算的呢？這個就是上面提到的一個公式。swap+50%的RAM值，50%參數(shù)的設(shè)定是在overcommit_ratio中設(shè)定。

總虛擬內(nèi)存 = 可用物理內(nèi)存 × 百分比 + 交換分區(qū)

[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]# 

總虛擬內(nèi)存=132096808 * 50% + 4095992= 70144396 kB

那么最后的結(jié)果就是buffer pool不能超過70144396 kB - 135196 kB=70009200 KB=66G。實際上經(jīng)過測試，buffer pool只能設(shè)置57G。

最后在看看總虛擬內(nèi)存情況：

CommitLimit：最大可用虛擬內(nèi)存

Committed_AS：已使用虛擬內(nèi)存

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

那么如果把內(nèi)核參數(shù)vm.overcommit_memory恢復(fù)為默認(rèn)值0，那么將不會受到約束。

 參考資料：

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

 總結(jié)：

說了這么多，那么為什么要修改內(nèi)核參數(shù)vm.overcommit_memory的值呢？這個是因為這臺服務(wù)器之前跑過GreenPlum數(shù)據(jù)庫，拿到我手上的時候沒有進行重裝系統(tǒng)，那么還是建議如果拿到的機器之前跑過其他的業(yè)務(wù)，那么保險的方法還是重裝一下系統(tǒng)，然后再部署自己的業(yè)務(wù)，不然真的會出現(xiàn)莫名其妙的問題。