背景

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

解決排查過程

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

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

這里可以看到確實發(fā)生了OOM,但是可以看到是因為filebeat導致的，思考一下，肯定是因為
當時vim的時已經出發(fā)到邊界了，但是filebeat剛好在臨界值又去tail slow log剛好到達了OOM的觸發(fā)條件，引發(fā)了OOM
繼續(xù)往下看發(fā)現了問題：

可以看到這里kernel選擇殺死了分數最高的mysqld進程

PS: 這里說一下為什么,在OOM的時候，kernal殺掉了mysqld進程，在OOM的情況下，系統(tǒng)會有一個打分策略，會kill掉分數最高的進程、

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

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

#kernel score如何計算的，主要是通過下面值計算出來的
oom_score
oom_score_adj
#就是下面這兩個文件/proc/進程號/下
$ 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ù)深入研究

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

后續(xù)改進措施

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

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

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

最新評論