背景

上周一個(gè)業(yè)務(wù)排查處理死鎖的時(shí)候的時(shí)候，先tail -n200 mysql-error.log，處理過(guò)
死鎖的小伙伴都知道，show engine innodb status\G只能看到最近一次的死鎖信息，
而對(duì)于歷史的死鎖信息需要開(kāi)啟innodb_print_all_deadlocks_output這個(gè)參數(shù)，
一旦數(shù)據(jù)庫(kù)開(kāi)啟了這個(gè)參數(shù)，就會(huì)將所有的歷史死鎖信息輸出到MySQL的error log。
而一條死鎖如果鎖定的行數(shù)或者記錄很多的話，一條死鎖記錄可能就會(huì)幾百行，
所以當(dāng)時(shí)一直看不到想要的信息，就直接vim打開(kāi)查看了一下，結(jié)果直接就卡住了，
（后來(lái)恢復(fù)了,看了一下當(dāng)時(shí)的那個(gè)error log居然18GB）緊接著就收到報(bào)警信息，主庫(kù)MySQL進(jìn)程時(shí)間運(yùn)行少于10min，然后就從庫(kù)也報(bào)警IO
線程停掉了。

解決排查過(guò)程

1.遇到報(bào)警第一瞬間上去修復(fù)主從復(fù)制，還好該庫(kù)不是一個(gè)核心業(yè)務(wù)而且是在業(yè)務(wù)低峰期，
qps非常低，所以主從自己重新連接上，恢復(fù)正常。
2.查看數(shù)據(jù)情況，數(shù)據(jù)
3接下來(lái)進(jìn)入問(wèn)題排查過(guò)程，查看監(jiān)控，監(jiān)控如下：

可以看到監(jiān)控圖內(nèi)存使用率到一個(gè)點(diǎn)掉了下來(lái)，看起來(lái)是OOM導(dǎo)致的問(wèn)題，
4.查看系統(tǒng)日志，查找元兇。

這里可以看到確實(shí)發(fā)生了OOM,但是可以看到是因?yàn)?code>filebeat導(dǎo)致的，思考一下，肯定是因?yàn)?br />當(dāng)時(shí)vim的時(shí)已經(jīng)出發(fā)到邊界了，但是filebeat剛好在臨界值又去tail slow log剛好到達(dá)了OOM的觸發(fā)條件，引發(fā)了OOM
繼續(xù)往下看發(fā)現(xiàn)了問(wèn)題：

可以看到這里kernel選擇殺死了分?jǐn)?shù)最高的mysqld進(jìn)程

PS: 這里說(shuō)一下為什么,在OOM的時(shí)候，kernal殺掉了mysqld進(jìn)程，在OOM的情況下，系統(tǒng)會(huì)有一個(gè)打分策略，會(huì)kill掉分?jǐn)?shù)最高的進(jìn)程、

#關(guān)于OOM
linux OOM是由系統(tǒng)參數(shù)vm.overcommit_memory控制的.
#查看方式：
$ sysctl -a| grep vm.overcommit
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50

#vm.overcommit_memory的取值
#簡(jiǎn)單總結(jié)
0--用之前先申請(qǐng)，申請(qǐng)不到足夠空間拋出OOM（默認(rèn)值）
1--不申請(qǐng)直接使用，過(guò)載使用內(nèi)存，不觸發(fā)OOM
2--不允許過(guò)載使用內(nèi)存，不觸發(fā)OOM

#kernel score如何計(jì)算的，主要是通過(guò)下面值計(jì)算出來(lái)的
oom_score
oom_score_adj
#就是下面這兩個(gè)文件/proc/進(jìn)程號(hào)/下
$ ls -l /proc/197543/oom_score*
-r--r--r-- 1 mysql mysql 0 9月  15 18:40 /proc/197543/oom_score
-rw-r--r-- 1 mysql mysql 0 9月  15 18:40 /proc/197543/oom_score_adj

感興趣的可以繼續(xù)深入研究

所以可以看到我們?cè)?code>OOM并不是內(nèi)存使用率達(dá)到100%的時(shí)候才會(huì)拋出OOM異常，像我們監(jiān)控的時(shí)候95%就OOM了
5萬(wàn)幸的是這次掛掉的是一個(gè)qps非常低的非核心業(yè)務(wù)庫(kù)，由于重啟速度也很快，在1s之內(nèi)完成，所以業(yè)務(wù)幾乎無(wú)任何影響

后續(xù)改進(jìn)措施

既然問(wèn)題發(fā)生了，解決了，那么作為一個(gè)合格的DBA，接下來(lái)就應(yīng)該去考慮如何去做優(yōu)化，以及避免這種問(wèn)題發(fā)生：
針對(duì)這次的問(wèn)題，整理了以下的措施：

1. 優(yōu)化告警策略，明明平常內(nèi)存使用已經(jīng)很高了，但是沒(méi)有報(bào)警提示
2. vim的時(shí)候注意，vim的時(shí)候一定要注意文件大小
3. 定時(shí)歸檔日志文件，定時(shí)分割拆分清理錯(cuò)誤日志，慢查詢?nèi)罩?/li>
4. 合理分配數(shù)據(jù)庫(kù)使用buffer，如果這臺(tái)機(jī)器還有其他業(yè)務(wù)，比如canal，filebeat考慮調(diào)小buffer pool size大小
5. 重要進(jìn)程保證不會(huì)被oom-killer kill掉，實(shí)現(xiàn)方式，可以把對(duì)應(yīng)進(jìn)程的oom_score_adj文件內(nèi)容調(diào)成一個(gè)比較小的負(fù)數(shù)，注意會(huì)有范圍的，在范圍之內(nèi)調(diào)小，然后使其在OOM的時(shí)候拿到一個(gè)比較低的分?jǐn)?shù)，避免被kill掉。

到此這篇關(guān)于vim引發(fā)的MySQL進(jìn)程掛掉的問(wèn)題解決的文章就介紹到這了,更多相關(guān)MySQL進(jìn)程掛掉內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！