MySQL啟動錯誤解決方案_Mysql

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

有同學會說，哥們兒你是不是buffer pool設定太大了，設定了96G記憶體。這明顯提示無法分配記憶體嘛。如果真是這樣也就不在這裡進行分享了，哈哈。

我的伺服器記憶體是128G。如下圖：

伺服器記憶體使用量情況：

那麼問題來了，既然還剩如此多的記憶體，為什麼提示無法分配記憶體？？。各位童鞋怎麼看？

1. 首先想到會不會是有幾條記憶體壞了？於是營運的同學進行了檢查，給我的反饋是硬體一切正常。

2. 把mysql配置參數又檢查了一遍，沒有發現什麼問題，線上一直就是使用這些參數。

3. 又把檔案拷貝到另外一台機器，，另外一台伺服器可以正常啟動（2台機器硬體設定一致）。

那麼如果排除硬體問題，mysql配置問題，那麼剩下的就只有作業系統的核心參數配置了。於是把兩台伺服器進行了對比，最終發現了一個核心參數不一致。

複製代碼 代碼如下:

vm.overcommit_memory

mysql啟動正常的伺服器改參數的值是0，而mysql啟動錯誤的這台伺服器該值是2。

那麼問題來了，這個參數到底是什麼鬼？竟然會讓mysql分配記憶體失敗，最後導致無法啟動。經過查詢資料知道了vm.overcommit_memory是什麼鬼。

vm.overcommit_memory

預設值為：0
從核心文檔裡得知，該參數有三個值，分別是：
0：當使用者空間請求更多的的記憶體時，核心嘗試估算出剩餘可用的記憶體。
1：當設這個參數值為1時，核心允許超量使用記憶體直到用完為止，主要用於科學計算.
2：當設這個參數值為2時，核心會使用一個決不過量使用記憶體的演算法，即系統整個記憶體位址空間不能超過swap+50%的RAM值，50%參數的設定是在overcommit_ratio中設定。

vm.overcommit_ratio
預設值為：50

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

那麼我們來看一下總的記憶體位址不能超過多少。其實是可以直接查看的。

[root@yayundeng 3306]# cat /proc/meminfo |grep -i commitCommitLimit:  70144396 kBCommitted_AS:   135196 kB[root@yayundeng 3306]# 

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

總虛擬記憶體 = 可用實體記憶體 × 百分比 + 交換分區

[root@yayundeng 3306]# cat /proc/meminfo | grep MemTotalMemTotal:    132096808 kB[root@yayundeng 3306]# [root@yayundeng 3306]# free -k       total    used    free   shared  buffers   cachedMem:   132096808  1583944 130512864     0   10240   133220-/+ buffers/cache:  1440484 130656324Swap:   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 commitCommitLimit:  70144396 kBCommitted_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資料庫，拿到我手上的時候沒有進行重裝系統，那麼還是建議如果拿到的機器之前跑過其他的業務，那麼保險的方法還是重裝一下系統，然後再部署自己的業務，不然真的會出現莫名其妙的問題。