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

分析：內(nèi)存持續(xù)飆升，應(yīng)該是有大量?jī)?nèi)存一直沒有釋放，考慮僵尸對(duì)象，僵尸進(jìn)程，最簡(jiǎn)單的就是重啟服務(wù)器，但是就無法找到罪魁禍?zhǔn)琢恕?/p>

驗(yàn)證：top命令查看活躍進(jìn)程的資源使用情況。（top命令是linux下常用的性能分析工具，能夠?qū)崟r(shí)顯示系統(tǒng)中各個(gè)進(jìn)程的資源占用實(shí)況，類似于windows的任務(wù)管理器）

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

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

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

終極解決方案：

postdrop是由sendmail啟動(dòng)的，而sendmail又是由crond啟動(dòng)的。所以根在crond服務(wù)上。

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

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

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

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

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