7月14號下午，有一台aliyun服務器突然無法連接,系統無法登陸，死機狀態。
只好通過登錄阿里雲去看實例監控狀態，內存，cpu在下午5點后突然飆升爆滿了，逼近100%了
趕緊和阿里雲工程師聯系，看他們那里是否可以操作，阿里雲方反饋vnc 連接看系統卡死狀態無法登錄， 界面有日志輸出 oom 記錄，有大量計划任務進程運行
先操作了下命令 crontab -r 試着清空定時任務，但是輸入命令后是沒有反應的，需要等待了。
等待了好大一會，釋放出部分內存，系統可以正常操作，需要查詢內存跑高的原因
可以操作也用命令 echo 3 > /proc/sys/vm/drop_caches 進一步清緩存
自帶的top、ps以及htop等命令看不到占有內存高的進程
ps -aux --sort -pmem |less ##根據內存使用率來排序
ps -aux --sort -pcpu |less ##根據CPU使用率來升序排序
cat /var/log/messages 通過看系統日志分析：顯示內存使用率是從15:45之后開始持續升高的，查看系統日志，該時段開始一直在打印postdrop相關的錯誤信息，目前看系統中有3000多個postdrop進程在運行。
根據阿里雲提供的辦法和參考資料先把crond服務關掉，killall crond確實有效。
分析總結具體原因：crond在執行腳本時會將腳本輸出信息以郵件的形式發送給系統用戶，要調用sendmail，而sendmail又會調用postdrop發送郵件，但是系統的postfix服務沒有正常運行，那么郵件就會發送不成功，postdrop老是執行失敗，致使持續寫入日志到日志文件。日志文件增大的速率超過了logrotate的刪除頻率，所以導致資源耗盡。
查看報錯
tail -fn 123 /var/log/maillog 日志記錄也和/var/log/messages記錄的日志一樣
都是提示warning: mail_queue_enter: create file maildrop/217077.32757: No such file or directory
maildrop/下為空，不正常。
解決辦法：清空maillog文件，停止所有的sendmail,postdrop進程，修改/etc/crontab中MAILTO=root 為MAILTO=" "設置成空，crond仍然會調用sendmail發送郵件，再把crond執行的命令最后加上 &> /dev/null 2>&1 ，crond不再sendmail 是需要重啟下crond服務的
監控狀態CPU和內存使用率正常了
簡便的使用命令先降低內存的辦法：
echo 3 > /proc/sys/vm/drop_caches ##釋放內存
使用ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' #查看進程詳細信息，發現存在大量sendmail、postdrop進程
killall sendmail & killall postdrop #先殺掉進程，內存占用可以瞬間降低
