cpu负载4800，根目录磁盘100%，问题排查和解决

cpu负载4800，根目录磁盘100%，问题排查和解决

猛地一看像不像机器中病毒了呢，对于一个cpu只有16c的服务器，如果出现了上面的这个情况，那么第一直觉就是，完犊子了，这个服务器中马了，但是万事还是要往好处想，是吧，其实出现这种情况还有另外的一种可能，请细看

背景介绍

就在昨天下午3点的时候，接到机房的电话，说有一台服务器根目录100%了，当时第一反应就是，靠，谁又往根目录上面放文件了，安排处理下就ok了，但是后来机房又曝出来一个猛料，当前机器的LOAD值已经4000+了，那就不得了了，这一点不科学呀，赶紧操作起来看看怎么回事。

排查步骤

1、查看top

呜呜，图片没了

通过top来看基本上没有什么进程占用了大量的cpu资源，这个就很奇怪，是不是很像马子，一查看他就消失，但实际上cpu的load还是那么高，于是想着是不是top命令被人篡改了呢，当然这种情况也好小

查看定时任务，无异常定时任务，查看用户登录记录也是细碎的那么几个跳板机的地址，见鬼，检查passwd文件，时间也是之前改密码的时间，也没变动过，也没可疑的新增的用户。

这就奇怪了，哈

2、找异常进程

通过命令

# ps -ef

发现了有一丝的头绪了，因为在这个里面发现了有几个重复的sendmail相关的进程，其他的倒是没有发现什么异常

3、清理磁盘

首要任务需要恢复系统的性能，先将磁盘清理出来

# find / -mount -type f -size +10M 2>/dev/null  | xargs -n1 -i  du -sm {} | sort -rn | head -30

14259 /var/log/maillog
211	/nohup.out
108	/var/adm/messages
95	/usr/lib/locale/locale-archive
79	XXXXXXXX.log
79	XXXXXXXX.zip
73	XXXXXXXX.tar

通过查询可以发现maillog日志已经占用根目录14G之多了，我的天呢，什么邮箱日志要这么大

4、清理maillog日志

通过命令tail看看这些日志里面都写入了什么

# tail -f /var/log/maillog
******No space to ***
******No space to ***
******No space to ***【全是这种报错】

同时也结合上面ps -ef查看的重复的sendmail进程，大概也就知道了原因了

5、实施步骤

联系业务人员，确认sendmail有无用处【当然我们知道这个是没用的，但是还是的需要确认下，万一有用呢，是不是\坏笑，当前前提是要走变更流程哈】，通过业务和研发的确认没有用到这个mail服务

（1）、对mail日志进行备份，通过scp进行备份
（2）、清理mail日志

# echo "" > /var/log/maillog   能不用rm就不要用rm，当然你也的有权限

（3）、清理sendmail和postdrop进程

1、清理mail进程
#  kill -9 `ps -ef | grep -i "sendmail" | egrep -v "grep"  | awk '{print $2}'`
建议执行这个命令前先通过ps -ef | grep -i "sendmail" | egrep -v "grep"  来看看是不是要kill掉的进程。
2、清理postdrop进程
#  kill -9 `ps -ef | grep -i "postdrop" | egrep -v "grep"  | awk '{print $2}'`
建议执行这个命令前先通过ps -ef | grep -i "postdrop" | egrep -v "grep"  来看看是不是要kill掉的进程。

为什么要清理这两个进程呢？其实这个跟crontab定时任务有关系。
crond在执行脚本时会将脚本输出信息以邮件的形式发送给系统用户，如果当前用户在线会屏幕输出给用户，如果用户不在线就会调用sendmail，而sendmail又会调用postdrop发送邮件，此时服务器上面有没有部署邮箱服务，例如像postfix服务之类，那么邮件就会发送不成功，sendmail、postdrop、crond进程就一直会卡在那里，并持续向/var/log/mailog里面写入相关日志，因为一直有排队的任务在等待cpu，但是前面个的一直在占用cpu不释放，排队的任务越来越多，这样就会导致cpu的LOAD值居高不下，也就会发生cpu负载居高，磁盘也写满了

（4）、观察服务器状态

磁盘恢复状态，cpu负载降到了正常范围

6、解决办法

我看了网上有好多的解决办法，好多都是让你修改crontab的配置的，但是建议不要这样搞，万一影响了crontab正常运行了，得不偿失

其实造成这个主要原因有一下几点:
1、定时任务书写不规范，使用了出现有回显信息的定时任务，也就是说脚本或定时任务执行完，不要有屏幕输出的信息出来，
2、监控没有第一时间预警，给自己造成了被动的局面

7、结束语

工作就是积累这些一点一滴，努力加奋斗成就辉煌

当天解决后，第二天就发现了新的问题，还请大家继续看下小编的下一个博客
原来都是crontab惹的祸，服务器系统差点重置了/呜呜呜