一般情況下mysql的啟動(dòng)錯(cuò)誤還是很容易排查的,但是今天我們就來(lái)說(shuō)一下不一般的情況。拿到一臺(tái)服務(wù)器,安裝完mysql后進(jìn)行啟動(dòng),啟動(dòng)錯(cuò)誤如下:
有同學(xué)會(huì)說(shuō),哥們兒你是不是buffer pool設(shè)置太大了,設(shè)置了96G內(nèi)存。這明顯提示無(wú)法分配內(nèi)存嘛。如果真是這樣也就不在這里進(jìn)行分享了,哈哈。
我的服務(wù)器內(nèi)存是128G。如下圖:
服務(wù)器內(nèi)存使用情況:
那么問(wèn)題來(lái)了,既然還剩如此多的內(nèi)存,為什么提示無(wú)法分配內(nèi)存??。各位童鞋怎么看?
1. 首先想到會(huì)不會(huì)是有幾條內(nèi)存壞了?于是運(yùn)維的同學(xué)進(jìn)行了檢查,給我的反饋是硬件一切正常。
2. 把mysql配置參數(shù)又檢查了一遍,沒(méi)有發(fā)現(xiàn)什么問(wèn)題,線上一直就是使用這些參數(shù)。
3. 又把文件拷貝到另外一臺(tái)機(jī)器,,另外一臺(tái)服務(wù)器可以正常啟動(dòng)(2臺(tái)機(jī)器硬件配置一致)。
那么如果排除硬件問(wèn)題,mysql配置問(wèn)題,那么剩下的就只有操作系統(tǒng)的內(nèi)核參數(shù)配置了。于是把兩臺(tái)服務(wù)器進(jìn)行了對(duì)比,最終發(fā)現(xiàn)了一個(gè)內(nèi)核參數(shù)不一致。
vm.overcommit_memory
mysql啟動(dòng)正常的服務(wù)器改參數(shù)的值是0,而mysql啟動(dòng)錯(cuò)誤的這臺(tái)服務(wù)器該值是2。
那么問(wèn)題來(lái)了,這個(gè)參數(shù)到底是什么鬼?竟然會(huì)讓mysql分配內(nèi)存失敗,最后導(dǎo)致無(wú)法啟動(dòng)。經(jīng)過(guò)查詢資料知道了vm.overcommit_memory是什么鬼。
vm.overcommit_memory
默認(rèn)值為:0
從內(nèi)核文檔里得知,該參數(shù)有三個(gè)值,分別是:
0:當(dāng)用戶空間請(qǐ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è)決不過(guò)量使用內(nèi)存的算法,即系統(tǒng)整個(gè)內(nèi)存地址空間不能超過(guò)swap+50%的RAM值,50%參數(shù)的設(shè)定是在overcommit_ratio中設(shè)定。
vm.overcommit_ratio
默認(rèn)值為:50
這個(gè)參數(shù)值只有在vm.overcommit_memory=2的情況下,這個(gè)參數(shù)才會(huì)生效。
那么我們來(lái)看一下總的內(nèi)存地址不能超過(guò)多少。其實(shí)是可以直接查看的。
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動(dòng)安全 [無(wú)線安全]玩轉(zhuǎn)無(wú)線電——不安全的藍(lán)牙鎖 2017-07-26
- 消息隊(duì)列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標(biāo)分割】 2017-07-26
- 詞向量-LRWE模型-更好地識(shí)別反義詞同義詞 2017-07-26
- 從棧不平衡問(wèn)題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實(shí)現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動(dòng)安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來(lái)看看(二) 2017-07-26