前言
上周四，服務器突然掛了，SSH都連接不上，日常的小程式后臺直接down掉，小程式每日大概3K左右訪問量，于是乎就開啟了，排查之后，
排查階段
什么先別說，先把服務恢復再說，重啟阿里云服務器，SSH連接，開啟nginx，redis，mysql，java服務，一系列操作，先把服務先啟動了，
服務器安裝了CloudMonitor(云監控)，非常建議安裝，對排查問題，查看CPU，記憶體非常的有幫助，
查看CPU，記憶體如下：
我們先從最后一幅圖看起，可以明顯的看到9.30左右的時候，網路的流入流出速率立馬飆升了，因此初步可以斷定，CPU，記憶體飆升，可能跟網路有關，
9.30分左右的時候，服務器大概運行了以下幾個跟網路有關的應用：
- mysql
- redis
- ngxin
- java服務（osc，sign等等）
- docker
很明顯前三個是日常的應用，基本上不會有什么問題，首先排除，剩下的就是Java相關的服務和Docker了，
第一個想法是不是Java的訪問量突然增大，然后服務器資源不夠，然后把服務給打死了，然后去看了Java服務的相關日志，發覺9.30分并無例外，跟平常的訪問流量無多大變化，故排除，
那么就是docker服務了，
docker我每天會有一個定時任務，用來刷題的，基本上每天九點多就會start，然后11點stop掉，遂查看docker日志：
可以明顯的看到9.23分的時候，docker開啟，開始刷題，可以斷定就是docker的鍋了，此時把docker kill掉，定時任務關掉，至此沒在出現過問題了，
問題在現
為確定是否是docker的問題，于是過了幾天，我又開啟了docker的定時任務，查看服務器資源如下：
問題重新復現出來了，很明顯，這就是docker的鍋，至于為什么開啟docker的這個服務，記憶體就飆升，CPU飆升，導致服務器直接down掉，這個原因就要問這個image的作者了，
個人初步猜想，記憶體泄露了，
我們可以仔細觀察下記憶體的圖片，約9.30的時候docker服務啟動，記憶體上升至70%左右，這都是非常的合理的，
在大概10點左右的時候，任務跑完了(通過查看日志），但服務并沒有stop，
從10點開始，記憶體一路飆升，飆升至95%，最終我kill掉了docker，記憶體回歸正常，
這是很明顯的記憶體泄露，因為此鏡像為私人鏡像，并且不開源，具體代碼無從查起，也是沒有辦法的了，
不過已向改倉庫提了issue，https://github.com/fuck-xuexiqiangguo/docker/issues/20
總結
從這次服務器掛掉，有以下幾點感想，
- 日志很重要，無論是什么服務，一定要記得把日志排在首位
- 服務器一定要有監控，并且要有監控預警，超過多少，發短信，電話通知，
- 問題思路排查要有理有據，一步一步來，不能瞎子抓鬮似的，
- 服務掛掉，首先要恢復服務，比如重啟等操作
這次服務器宕機并沒有任何影響，畢竟沒啥用戶，不過感覺對問題的排查更加深刻了，業務推動技術，這點是毋庸置疑的了，
而且業務上線后，慢慢也會出現很多問題，一個一個解決，也能學習到很多東西，
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/150667.html
標籤：Linux