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 #先杀掉进程，内存占用可以瞬间降低
