一般情況下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 commit CommitLimit: 70144396 kB Committed_AS: 135196 kB [root@yayundeng 3306]#
通過查看可以得知在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數據庫,拿到我手上的時候沒有進行重裝系統,那麼還是建議如果拿到的機器之前跑過其他的業務,那麼保險的方法還是重裝一下系統,然後再部署自己的業務,不然真的會出現莫名其妙的問題。