建站
咨詢
售后
建站咨詢
新聞中心
這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)-創(chuàng)新互聯(lián)
拖了好久了, 抽空補(bǔ)上 _(:з」∠)_
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
背景: 收到內(nèi)存報(bào)警的信息以后, 從監(jiān)控中發(fā)現(xiàn)MySQL服務(wù)器的內(nèi)存使用率在不斷的增長(zhǎng);
附圖:
雖然進(jìn)行了重啟, 但是內(nèi)存占用率依然會(huì)不停的增長(zhǎng), 大約在半個(gè)月左右的時(shí)間內(nèi)又把內(nèi)存消耗完畢;
場(chǎng)景: 未搭建場(chǎng)景, 數(shù)據(jù)庫(kù)版本 5.7.12
分析:
PS: 時(shí)間久遠(yuǎn), 截圖僅做分析/示例所用, 不一定是當(dāng)時(shí)候出問題時(shí)的數(shù)據(jù)
嘗試方向1:
首先考慮的是buffer相關(guān)的參數(shù)是否設(shè)置有誤, 畢竟當(dāng)初crash的時(shí)候曾經(jīng)出現(xiàn)過類似的問題(http://blog.itpub.net/29510932/viewspace-2123096/)
結(jié)果: 參數(shù)設(shè)置都沒什么明顯的問題;
嘗試方向2:
既然設(shè)置沒什么問題, 那就看一下內(nèi)存的占用情況吧~
使用pmap -d 看一下進(jìn)程的內(nèi)存情況; 部分信息截圖如下
anon代表進(jìn)程主動(dòng)申請(qǐng)的內(nèi)存, 當(dāng)時(shí)對(duì)有問題的機(jī)器進(jìn)行統(tǒng)計(jì)時(shí), 發(fā)現(xiàn)主動(dòng)申請(qǐng)的內(nèi)存占了進(jìn)程內(nèi)存的95%(當(dāng)然的..因?yàn)閎uffer都在這里面)
考慮到innodb_buffer_pool的大小只有總內(nèi)存的50%, 多出來的這些"已申請(qǐng)"的內(nèi)存實(shí)在是有點(diǎn)太多了, 是不是有什么線程申請(qǐng)了大量的內(nèi)存沒有釋放?
嘗試方向2--檢查線程的內(nèi)存使用:
MySQL5.7中對(duì)ps(performance_schema)進(jìn)行了拓展, 能統(tǒng)計(jì)更多的數(shù)據(jù)了, 這其中就包括了有關(guān)mem的信息;
由于默認(rèn)是關(guān)閉的, 所以現(xiàn)在要臨時(shí)打開這些統(tǒng)計(jì)數(shù)據(jù);
當(dāng)前題目：MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)-創(chuàng)新互聯(lián)
本文地址：http://fisionsoft.com.cn/article/dsdoic.html
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------
背景: 收到內(nèi)存報(bào)警的信息以后, 從監(jiān)控中發(fā)現(xiàn)MySQL服務(wù)器的內(nèi)存使用率在不斷的增長(zhǎng);
附圖:
雖然進(jìn)行了重啟, 但是內(nèi)存占用率依然會(huì)不停的增長(zhǎng), 大約在半個(gè)月左右的時(shí)間內(nèi)又把內(nèi)存消耗完畢;
場(chǎng)景: 未搭建場(chǎng)景, 數(shù)據(jù)庫(kù)版本 5.7.12
分析:
PS: 時(shí)間久遠(yuǎn), 截圖僅做分析/示例所用, 不一定是當(dāng)時(shí)候出問題時(shí)的數(shù)據(jù)
嘗試方向1:
首先考慮的是buffer相關(guān)的參數(shù)是否設(shè)置有誤, 畢竟當(dāng)初crash的時(shí)候曾經(jīng)出現(xiàn)過類似的問題(http://blog.itpub.net/29510932/viewspace-2123096/)
結(jié)果: 參數(shù)設(shè)置都沒什么明顯的問題;
嘗試方向2:
既然設(shè)置沒什么問題, 那就看一下內(nèi)存的占用情況吧~
使用pmap -d 看一下進(jìn)程的內(nèi)存情況; 部分信息截圖如下
anon代表進(jìn)程主動(dòng)申請(qǐng)的內(nèi)存, 當(dāng)時(shí)對(duì)有問題的機(jī)器進(jìn)行統(tǒng)計(jì)時(shí), 發(fā)現(xiàn)主動(dòng)申請(qǐng)的內(nèi)存占了進(jìn)程內(nèi)存的95%(當(dāng)然的..因?yàn)閎uffer都在這里面)
考慮到innodb_buffer_pool的大小只有總內(nèi)存的50%, 多出來的這些"已申請(qǐng)"的內(nèi)存實(shí)在是有點(diǎn)太多了, 是不是有什么線程申請(qǐng)了大量的內(nèi)存沒有釋放?
嘗試方向2--檢查線程的內(nèi)存使用:
MySQL5.7中對(duì)ps(performance_schema)進(jìn)行了拓展, 能統(tǒng)計(jì)更多的數(shù)據(jù)了, 這其中就包括了有關(guān)mem的信息;
由于默認(rèn)是關(guān)閉的, 所以現(xiàn)在要臨時(shí)打開這些統(tǒng)計(jì)數(shù)據(jù);
點(diǎn)擊(此處)折疊或打開
當(dāng)前題目：MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)-創(chuàng)新互聯(lián)
本文地址：http://fisionsoft.com.cn/article/dsdoic.html
