前几天的时候，有个同事问我一个问题，大体的意思是突然收到报警，服务器的进程数翻了好几倍，其实那个服务器也没有任何操作。所以想让我帮忙看看。
他自己也做了一些简单的分析，可以看出，里面含有大量的CRONTD进程，sendmail进程等，大概占用了近4000的进程。
$ ps -ef|grep sendmail |wc
-l
1317
$ ps -ef|grep postdrop|wc
-l
1317
$ ps -ef|grep CROND|wc -l
1315
登录到服务器，我简单看了下，发现确实已经是4000多进程了。如果这是一个繁忙异常的OLTP业务可能会放松我的警惕，但是这是一个业务很少的备库，突然就提高了警觉。
top命令的结果如下：
top - 11:41:25 up 559 days, 16:52, 1 user, load average: 0.10, 0.10, 0.10
Tasks: 4288 total, 1 running, 4287 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32862536k total, 31871784k used, 990752k free, 629660k buffers
Swap: 16777200k total, 0k used, 16777200k free, 16914428k cached
可以从以上信息看到，一共4288的进程，4287在sleep状态，服务器负载也不高，iowait很低，CPU使用率也很低。
看起来一切太平啊。
查看磁盘空间 df-h发现空间还富余不少。所以这个问题就有些奇怪了。
我静了静，这个问题似乎之前碰到过类似的，那是因为存在NFS的挂载点失效导致CROND执行失败，结果累计了大量的后台进程。这次的环境问题似乎还有所不同。
查看CROND的属主，是root，但是查看root下的crontab的设置，只有ntpdate同步时间的crontab
10 * * * * /usr/sbin/ntpdate -s xxxx ;/sbin/clock -w
10 * * * * /usr/sbin/ntpdate -s xxxx ;/sbin/clock -w
看这个crontab是每个小时的第10分钟开始同步时间，应该不会有这么大的影响。
当然在分析问题的时候，脑子里也在飞快的搜索着，突然想起很久以前是处理过一个类似的案例，而问题的根源就是Inode满了。可以参见很久以前的一篇文章。http://blog.itpub.net/23718752/viewspace-1812698/
这次的问题是否是同样的原因呢，df -i查看，发现竟然如出一辙，还是套路，原来就是Inode满了。
这个时候我没有急于去清理这些进程，而是打算先清理inode，在/var目录下查看在/var/spool/postfix/maildrop下面存在大量的文件。
当然仔细查看了部分文件之后，确认是可以删除的，这个时候就得分批删除，要不直接删除肯定会抛出句柄相关的错误来。
分批删除大概持续了20多秒，删除之后inode马上就释放了。
# time ls |xargs -n 10 rm
real 0m22.791s
user 0m2.053s
sys 0m6.490s
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 262144 3381 258763 2% /var
而再次使用top查看，4000多的进程瞬间降了下来，只有不到400进程。
top - 12:04:54 up 559 days, 17:16, 3 users, load average: 0.16, 0.23, 0.17
Tasks: 328 total, 1 running, 327 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32862536k total, 28072444k used, 4790092k free, 638572k buffers
Swap: 16777200k total, 0k used, 16777200k free, 16739416k cached
通过zabbix的监控图我看到了如下的结果，这个图刚开始看的时候还有些疑惑，以为这个问题已经持续了很就，但是如此来看，是一个爆发式的增长过程。
其实解释明白就很容易理解了，我查看了系统的日志，在问题发生的时间段，确实没有其它的操作，而就是在某一个特定的时间，因为inode溢出导致sendmail,maildrop的进程阻塞，
结果大量的进程都堆积下来了。如此来看问题在释放inode之后似乎是引刃而解了。
我查看了一下/var/spool/postfix/maildrop目录下的文件，发现了一个奇怪的情况。
-rwxr--r-- 1 root postdrop 641 Aug 27 23:10 CEADC52C
-rwxr--r-- 1 root postdrop 497 Aug 27 23:10 CEB7352D
-rwxr--r-- 1 root postdrop 516 Aug 27 23:10 E62A552E
-rwxr--r-- 1 root postdrop 632 Aug 27 23:20 CCF8F530
-rwxr--r-- 1 root postdrop 506 Aug 27 23:20 CCDD852F
-rwxr--r-- 1 root postdrop 516 Aug 27 23:20 E395C531
这个目录下的文件生成时间似乎有些问题，案例是每个小时生成一次，每次不应该是3个文件。这个是什么原因呢 ，经过一番排查，发现原来是另外一个配置在作怪。
配置信息如下：
# vi /etc/cron.d/ntpdate
###################################################
*/10 * * * * root (/usr/sbin/ntpdate xxxx;/sbin/clock -w)
*/10 * * * * root (/usr/sbin/ntpdate xxxx;/sbin/clock -w)
*/10 * * * * root (/usr/bin/rdate -s xxxx;/sbin/clock -w)
如此来看问题就很容易理解了，这样导致了没10分钟一次循环调用，所以修复了问题以后，文件的生成频率大大降低。