服务器cpu_记一次服务器CPU跑满事件

博主发现自己的博客网站无法访问且服务器远程连接受阻,经排查发现CPU满载由bzip2进程引起。通过进程树分析,定位到问题源于一个每周执行的备份脚本。原来,cron任务的配置错误导致脚本每分钟执行一次而非预期的一次。修复方法是正确设置cron表达式,并优化定时任务。最后,博主计划编写服务器资源监控脚本以防止类似问题再次发生。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

6f37e5dbae8ce7797a84b622752723de.png

php中文网最新课程

每日17点准时技术干货分享

53995ca138bd2e86a4eaf21db5c988ce.png

b1f1068be2ebf2a5670adc7ddde9392d.gif

本文为php中文网认证作者:“齐天大圣”投稿,欢迎加入php中文网有偿投稿计划!

事情经过

昨天早上,打开电脑发现自己的博客网站打开不了,准备远程登录服务器查看问题,发现服务器远程不上。没办法,登录阿里云后台,重启服务器。重启完成后,网站能正常打开,所以当时就不以为然,以为阿里云那边是不是出了什么毛病。

到了下午的时候,发现网站又打不开了,而且又远程连接不了服务器。进入阿里云控制台,查看监控发现cpu跑满了。只能再重启服务器,等重启完成后再远程连接上去,这次需要好好排查问题。

9daf8ff2282989e8bf4659bd464db8be.png

解决问题

当时首先想到的是中病毒了,先不管那么多,第一步是找到那些耗cpu的进程杀死。使用top命令,查看耗cpu的进程有哪些。一看就明白了,都是bzip2搞得鬼。

626d191cb2177a3d1ee5dd3e7fbb465f.png

杀进程的过程发现一个问题,就是这些进程杀死了,过一会又出现了。这种现象,我知道肯定要找到他们的父进程,擒贼先擒王。

# ps -lA | grep bzip20 R     0  1965  1964 44  80   0 -  3435 -      ?        00:01:43 bzip20 S     0  1981  1980 33  80   0 -  3435 pipe_w ?        00:00:56 bzip20 R     0  1997  1996 30  80   0 -  3435 -      ?        00:00:31 bzip20 R     0  2013  2012 27  80   0 -  3435 -      ?        00:00:07 bzip20 R     0  2024  2023 15  80   0 -  3435 -      ?        00:00:00 bzip2

但是发现他们的ppid不是同一个,这就让我很疑惑了。我打算用进程树看看

pstree -up

64dd71d9ece557d9fe61be1146e67ba9.png

这时候,我就知道了,原来是自己的定时脚本有问题。那么我需要做以下几件事:

关闭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/binexportbackdir=/backup/weekly # 备份目录[ -z "$backdir" ] || mkdir -p $backdirdirs=(/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 $dirdone# 删除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

问题解决了,原因也找到了。自己该写一个服务器资源监控脚本了。

3df78dfb2e1ac1db8f175ae47abd07c5.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值