解决问题
当时首先想到的是中病毒了,先不管那么多,第一步是找到那些耗cpu的进程杀死。使用top命令,查看耗cpu的进程有哪些。一看就明白了,都是bzip2搞得鬼。
杀进程的过程发现一个问题,就是这些进程杀死了,过一会又出现了。这种现象,我知道肯定要找到他们的父进程,擒贼先擒王。
# ps -lA | grep bzip2 0 R 0 1965 1964 44 80 0 - 3435 - ? 00:01:43 bzip2 0 S 0 1981 1980 33 80 0 - 3435 pipe_w ? 00:00:56 bzip2 0 R 0 1997 1996 30 80 0 - 3435 - ? 00:00:31 bzip2 0 R 0 2013 2012 27 80 0 - 3435 - ? 00:00:07 bzip2 0 R 0 2024 2023 15 80 0 - 3435 - ? 00:00:00 bzip2
但是发现他们的ppid不是同一个,这就让我很疑惑了。我打算用进程树看看
pstree -up
这时候,我就知道了,原来是自己的定时脚本有问题。那么我需要做以下几件事:
关闭crond服务
crontab -e 将weekly.sh去掉
杀掉那些耗cpu的进程
# 关闭 [root@iz8vb626ci0aehwsivxaydz ~]# kill 1622 [root@iz8vb626ci0aehwsivxaydz ~]# systemctl status crond ● crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2019-11-12 10:44:32 CST; 10s ago Main PID: 1622 (code=exited, status=0/SUCCESS) # 修改crontab -e # 杀掉耗cpu进程,下面的命令执行了好几遍,才将所有耗cpu进程全部杀掉了 ps -lA | grep bzip2 | awk '{print $4}' | xargs -n 10 kill -9
问题原因与思考
刚开始,我以为是自己的shell脚本有问题,出现死循环导致问题出现。但是查看脚本,发现没有问题,没有死循环的情况出现。一时间,百思不得姐。
#!/bin/bash # 每周备份脚本 export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin export backdir=/backup/weekly # 备份目录 [ -z "$backdir" ] || mkdir -p $backdir dirs=(/etc /home /root /usr /var/spool/cron /var/spool/at) # 需要备份的目录 for dir in ${dirs[@]} do if [ ! -d $dir ];then continue fi cd $backdir tar -jcpf $(basename $dir)_$(date +%Y%m%d).tar.bz2 $dir done # 删除mtime大于30天的文件 find $backdir -mtime +30 -name *.tar.bz2 -exec rm -f {} \;
过了很长时间,终于找到了原因所在,原来是自己的定时任务写法有问题
* 3 * * 1 /root/bin/weekly.sh 1>/dev/null 2>&1
我原本的想法是每周1凌晨3点执行一次备份脚本,但是这样写的结果是每周一凌晨3点的每分钟都会执行该脚本一次。正确的写法应该如下:
# 每周一凌晨三点零一分执行该脚本 1 3 * * 1 /root/bin/weekly.sh 1>/dev/null 2>&1
以上就是记一次服务器CPU跑满事件的详细内容,更多请关注亿速云其它相关文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。