ITPub博客

首页 > 数据库 > Oracle > crontab设置导致的服务器进程异常问题

crontab设置导致的服务器进程异常问题

原创 Oracle 作者:jeanron100 时间:2016-08-27 23:46:35 0 删除 编辑

前几天的时候,有个同事问我一个问题,大体的意思是突然收到报警,服务器的进程数翻了好几倍,其实那个服务器也没有任何操作。所以想让我帮忙看看。
他自己也做了一些简单的分析,可以看出,里面含有大量的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分钟一次循环调用,所以修复了问题以后,文件的生成频率大大降低。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-2124115/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 人性的参考
请登录后发表评论 登录
全部评论
技术文章每天更新,阵地已转移到微信公众号端。 公众号:jianrong-notes

注册时间:2012-05-14

  • 博文量
    1498
  • 访问量
    14432599