MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)

發(fā)布時(shí)間：2020-08-07 20:11:49 來(lái)源：ITPUB博客閱讀：370 作者：wangwenan6 欄目：MySQL數(shù)據(jù)庫(kù)

拖了好久了, 抽空補(bǔ)上 _(:з」∠)_
-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------

背景: 收到內(nèi)存報(bào)警的信息以后, 從監(jiān)控中發(fā)現(xiàn)MySQL 服務(wù)器的內(nèi)存使用率在不斷的增長(zhǎng);
附圖:
MySQL案例-內(nèi)存使用率無(wú)限增長(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í)候出問(wèn)題時(shí)的數(shù)據(jù)

嘗試方向1:
首先考慮的是buffer相關(guān)的參數(shù)是否設(shè)置有誤, 畢竟當(dāng)初crash的時(shí)候曾經(jīng)出現(xiàn)過(guò)類(lèi)似的問(wèn)題(http://blog.itpub.net/29510932/viewspace-2123096/)
結(jié)果: 參數(shù)設(shè)置都沒(méi)什么明顯的問(wèn)題;

嘗試方向2:
既然設(shè)置沒(méi)什么問(wèn)題, 那就看一下內(nèi)存的占用情況吧~
使用pmap -d 看一下進(jìn)程的內(nèi)存情況; 部分信息截圖如下
MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)

anon代表進(jìn)程主動(dòng)申請(qǐng)的內(nèi)存, 當(dāng)時(shí)對(duì)有問(wèn)題的機(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%, 多出來(lái)的這些"已申請(qǐng)"的內(nèi)存實(shí)在是有點(diǎn)太多了, 是不是有什么線程申請(qǐng)了大量的內(nèi)存沒(mé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í)打開(kāi)這些統(tǒng)計(jì)數(shù)據(jù);

點(diǎn)擊(此處)折疊或打開(kāi)

update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%'

執(zhí)行上述語(yǔ)句之后, 在ps里面就能在mem相關(guān)的表里面看到相關(guān)的統(tǒng)計(jì)信息了; 如下圖:
MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)

其中CURRENT_NUMBER_OF_BYTES_USED可以近似的當(dāng)成目前占用的內(nèi)存總數(shù);
PS: 由于這個(gè)統(tǒng)計(jì)信息并不會(huì)區(qū)分共享內(nèi)存, 所以有可能會(huì)出現(xiàn)占用內(nèi)存為負(fù)數(shù), 或者各個(gè)項(xiàng)的總和大于實(shí)際占用內(nèi)存總數(shù);

由于是懷疑線程, 所以用CURRENT_NUMBER_OF_BYTES_USED倒序, 查詢(xún)Thread相關(guān)的表; 結(jié)果類(lèi)似下圖:
MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)

當(dāng)時(shí)有問(wèn)題的實(shí)例中, 查詢(xún)結(jié)果結(jié)合ps.thread表數(shù)據(jù),顯示thread/sql/slave_sql和thread/sql/one_connection(monitor用戶(hù))的內(nèi)存占用非常高~

嘗試方向2--分析線程:
thread/sql/slave_sql是同步中的SQL線程, 負(fù)責(zé)復(fù)現(xiàn)主庫(kù)binlog中的事務(wù), 這個(gè)線程占用大量?jī)?nèi)存卻不進(jìn)行釋放的現(xiàn)象, 第一反應(yīng)不是我們自己的問(wèn)題;
在mysql bug上面找了一圈,發(fā)現(xiàn)以前有人提交了類(lèi)似的bug(https://bugs.mysql.com/bug.php?id=71197), 狀態(tài)為close;
官方給出的解決方案是關(guān)閉并行復(fù)制, 并且把rpl相關(guān)的信息存在file里面, 而不是table;
MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)

PS: Nice! 那5.7弄個(gè)并行復(fù)制不是坑自己么...... _(:з」∠)_

thread/sql/one_connection(monitor用戶(hù))是由用戶(hù)創(chuàng)建的, 可以發(fā)現(xiàn)是monitor用戶(hù)保持的連接, 主要用于自維護(hù)的監(jiān)控插件獲取信息的;
這個(gè)至少是能想辦法解決的, 那么看一下monitor線程的詳細(xì)信息:
MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)

查看以后發(fā)現(xiàn)memory/sql/String::value占用的內(nèi)存數(shù)最多;
從字面意思理解, 似乎是執(zhí)行的SQL有點(diǎn)問(wèn)題, 保存了大量的結(jié)果沒(méi)有釋放?

聯(lián)系了插件的編寫(xiě)人員, 找到插件的代碼, 仔細(xì)看了一圈, 發(fā)現(xiàn)代碼在使用cursor執(zhí)行SQL以后, 沒(méi)有close......

對(duì)代碼進(jìn)行fix及推送以后, 內(nèi)存使用率的增長(zhǎng)速度大幅度降低了;

處理結(jié)果:
把這個(gè)沒(méi)有close的經(jīng)典問(wèn)題掛到了內(nèi)部的文檔里面作為反例.......
然后由于一些原因, SQL線程無(wú)法釋放已占用內(nèi)存的問(wèn)題無(wú)法解決, 好在增長(zhǎng)的速度并不快, 還在可接受的范圍之內(nèi), 暫時(shí)做好定期維護(hù)(重啟)的準(zhǔn)備;
PS: 到目前為止, 出問(wèn)題的個(gè)別實(shí)例都沒(méi)有再增長(zhǎng)到非常高的地步, 目測(cè)需要兩個(gè)多月才可能會(huì)維護(hù)(重啟)一次;

向AI問(wèn)一下細(xì)節(jié)

MySQL案例-內(nèi)存使用率無(wú)限增長(zhǎng)

猜你喜歡

最新資訊

相關(guān)推薦

相關(guān)標(biāo)簽