昨天一台开发服务器出现了很奇怪的问题，项目网站无法访问，ssh登录时非常慢，半分钟才进去，在命令行敲命令几乎没有反应，要耐心的等待
进去后用 top 查看系统状态，结果很吓人，平均负载值在360，Tasks数量超级大（具体值忘了），用VI编辑文件都有异常提示，系统几乎瘫痪
解决过程
决定先降低负载，好能正常操作，不然连输入命令都费劲，然后再找原因，从根解决
执行 top 时，在进程列表中看到了大量的postdrop 进程，很明显这个有问题
先把他停了，让系统有个喘气的机会
#ps -ef|grep postdrop | grep -v grep | awk '{print "kill -9 " $2}' |sh
看日志 找线索
/var/log 下，发下 maillog 文件很大、很新，和之前的嫌疑进程 postdrop 很符合
从 maillog 中发现大量的如下信息
Apr 21 16:56:13 AY140 postfix/postdrop[2377]: warning: mail_queue_enter: create file maildrop/157768.2377: No space left on device
可以看出大概，系统写邮件文件时失败，因为没空间了
查看磁盘空间信息
# df -h
系统盘的使用率是 94%，块空间没满
再看inode使用情况
# df -i
系统盘的Inodes使用率100%
没Inodes可用空间，自然干啥都有问题，现在最紧急的就是清理空间
是谁占用了大量空间？
从日志信息中可以知道，postfix 一直往 maildrop 目录下创建文件，现在失败，说明之前肯定成功创建了很多文件，postfix应该就是凶手
但这个maildrop目录具体在哪儿？搜索资料后，找到了他的绝对路径
/var/spool/postfix/maildrop
看下这个目录占用的空间大小
# du -sh .
4G 多，找对地方了，就是这里的大量文件占用的空间，删掉其中所有文件
# ls | xargs rm -f
又是漫长的等待，删完后，空间占用值直接就降下来了
到这，燃眉之急已经解决，系统能正常点的运行了，下面就要找问题的根本原因
是谁启动了那么多postdrop进程？
在删除 maildrop 文件之前，复制出来了几个文件，内容都是一个命令的报错信息
再查看进程树
# pstree
发现是cron启动了sendmail，sendmail启动了postdrop
对上了，那个报错的命令正是在cron中定时执行的一个任务，而且是个高频执行的任务
大概明白了问题的来源：
（1）定时任务执行的程序报错，输出错误信息
（2）系统要通过sendmail把错误信息发给管理员
（3）sendmail会使用postdrop程序将邮件存入postfix队列目录下的maildrop子目录
我对邮件这部分不熟悉，不知道怎么处理，想到的最简单办法就是不让定时任务出现错误信息，那么就不会发送邮件了
办法是让定时任务的程序输出重定向，在那条定时任务后面加上 " &>/dev/null"，相当于把任务执行的结果信息扔掉了
之后用 top 观察了一段时间，postdrop进程不再出现，系统负载恢复正常，问题解决，接下来就是分析定时任务执行的那个程序为什么报错，应该比较简单了
