主頁 > 知識(shí)庫 > MySQL啟動(dòng)錯(cuò)誤解決方法

MySQL啟動(dòng)錯(cuò)誤解決方法

熱門標(biāo)簽:沈陽智能外呼系統(tǒng)供應(yīng)商 桂林云電銷機(jī)器人收費(fèi) 如何選擇優(yōu)質(zhì)的外呼系統(tǒng) 谷歌地圖標(biāo)注位置圖解 地圖簡圖標(biāo)注 東莞外呼企業(yè)管理系統(tǒng) 手機(jī)外呼系統(tǒng)違法嗎 清遠(yuǎn)申請400電話 南通電銷外呼系統(tǒng)哪家強(qiáng)

一般情況下mysql的啟動(dòng)錯(cuò)誤還是很容易排查的,但是今天我們就來說一下不一般的情況。拿到一臺(tái)服務(wù)器,安裝完mysql后進(jìn)行啟動(dòng),啟動(dòng)錯(cuò)誤如下:

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

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

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

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

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

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

3. 又把文件拷貝到另外一臺(tái)機(jī)器,,另外一臺(tái)服務(wù)器可以正常啟動(dòng)(2臺(tái)機(jī)器硬件配置一致)。

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

復(fù)制代碼 代碼如下:
vm.overcommit_memory

mysql啟動(dòng)正常的服務(wù)器改參數(shù)的值是0,而mysql啟動(dòng)錯(cuò)誤的這臺(tái)服務(wù)器該值是2。

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

vm.overcommit_memory

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


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


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

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

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

通過查看可以得知在70G的樣子。那么這個(gè)是如何計(jì)算的呢?這個(gè)就是上面提到的一個(gè)公式。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。實(shí)際上經(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,那么將不會(huì)受到約束。

復(fù)制代碼 代碼如下:
echo 0 > /proc/sys/vm/overcommit_memory

 參考資料:

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

 總結(jié):

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

您可能感興趣的文章:
  • Mysql主從同步Last_IO_Errno:1236錯(cuò)誤解決方法
  • MySQL Daemon failed to start錯(cuò)誤解決辦法
  • mysql “ Every derived table must have its own alias”出現(xiàn)錯(cuò)誤解決辦法
  • 解決MySQL server has gone away錯(cuò)誤的方案

標(biāo)簽:貴州 成都 天津 重慶 常德 湖州 內(nèi)蒙古 臨沂

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MySQL啟動(dòng)錯(cuò)誤解決方法》,本文關(guān)鍵詞  MySQL,啟動(dòng),錯(cuò)誤,解決,方法,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《MySQL啟動(dòng)錯(cuò)誤解決方法》相關(guān)的同類信息!
  • 本頁收集關(guān)于MySQL啟動(dòng)錯(cuò)誤解決方法的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章