網(wǎng)盤索引時，發(fā)現(xiàn)數(shù)據(jù)庫報錯網(wǎng)頁加載不進去. 于是去服務器后臺看了下服務器的運行情況. 發(fā)現(xiàn)服務器的儲存空間爆滿了一點空間都沒有，數(shù)據(jù)庫等等的運行不下去都自動掉了，可能是由于長期的緩存和日志文件吧空間擠滿了吧. 所以我去查看了寶塔的日志文件和數(shù)據(jù)庫的二進制文件. 查看下來發(fā)現(xiàn)并沒有問題.采取進一步的排查工作了. 當時的想是級一級的查看每個目錄都占用了多少空間.

分析：內(nèi)存持續(xù)飆升，應該是有大量內(nèi)存一直沒有釋放，考慮僵尸對象，僵尸進程，最簡單的就是重啟服務器，但是就無法找到罪魁禍首了。

驗證：top命令查看活躍進程的資源使用情況。（top命令是linux下常用的性能分析工具，能夠實時顯示系統(tǒng)中各個進程的資源占用實況，類似于windows的任務管理器）

顯然活躍進程占用的內(nèi)存并不多，造成內(nèi)存爆滿的另有它因。

ps -aux 查看當前系統(tǒng)的進程狀態(tài)?？吹接写罅康膒ostdrop和sendmail

順藤摸瓜，就找到了sendmail和postdrop上，通過重啟postfix，內(nèi)存使用立馬斷崖式下跌。問題暫時得到解決。如下圖所示

終極解決方案：

postdrop是由sendmail啟動的，而sendmail又是由crond啟動的。所以根在crond服務上。

問題成因：crond在執(zhí)行腳本時會將腳本輸出信息以郵件的形式發(fā)送給系統(tǒng)用戶，所以必然要調(diào)用sendmail，而sendmail又會調(diào)用postdrop發(fā)送郵件，但是如果系統(tǒng)的postfix服務沒有正常運行，那么郵件就會發(fā)送不成功，造成sendmail、postdrop、crond進程就無法正常退出，形成大量的僵尸進程

解決辦法：先把僵尸進程都干掉ps -ef | egrep “sendmail|postdrop” | grep -v grep |xargs kill，讓內(nèi)存降下來，其實我一開始就是將postfix服務重啟了一下，問題就解決了，觀察了一段時間，僵尸進程并沒有再次出現(xiàn)。

為防以后postfix掛了再出現(xiàn)類似問題，可以進行如下配置，將crond的郵件通知關閉：

將/etc/crontab和/etc/cron.d/0hourly里的MAILTO=root修改為MAILTO=””

crontab -e第一行增加一段MAILTO=””