公司有几台空闲服务器,最近打算用他们来做一系列dockercompose搭建各种中间件集群教程然后zabbix发现这几台服务器cpu全部占用100%。

那就选其中一台上去看看什么情况。

上到服务器,先top查看一下有什么进程在跑。大写M排个序看看

果然,有个kthreaddk的东西没见过而且占用资源应该kthreaddi的变种吧,之前也处理过。那这次也按照步骤处理吧,pid看一下是3106

首先,先确认一下处理思路直接kill概率是会重新又跑出来的,我们就先检查服务器看看有什么地方是和平常不一样的或者没见过的,如果不确定可以进程复制出来去百度一下,一般有用的都能百度出来的。所以我先systemctl status 3106 查看一下是不是有什么守护进程在跑。

仔细看Loaded配置文件位置开机启动disabled代表启用);Active表示正在运行;那我们cd进去/run/systemd/system看一下里面有什么吧。

发现一堆从来没见过的东西,暂时先不动,再检查一下其他地方。

进去/ect里面检查一下cron.dailycron.hourlycron.monthlycron.weekly这几个定时器文件夹里面有没有什么奇怪的东西。

再看一眼crontab -l看看有什么定时任务其实这个命令查看内容对应的是/var/spool/cron/这个文件夹对应用户名文件内容,也可以直接进去修改或者删掉这个文件

这个时候问题来了,看了几遍,发现每次这个qfigfc文件路径都不一样,那看来是有什么地方一直在修改这个文件。我先找到他最后一次位置cat一下看看里面是什么。

cat发现全是乱码,那没办法了。

因为刚才有提到,可能有某个地方一直在修改crontab里面的内容,所以我再跑一下netstat -ltnp看看是不是有什么进程监听端口

现有一个nkokya,好像没见过。那待会也把它处理了。

至此,检查的步骤都做完了,开始该删除删除,该killkill就好了。看看都弄好之后,top一下看看kthreaddk这个东西还会不会重新出来,如果没有了,那就弄好了,还有回头记得检查一下安全组等策略是不是有没设置好的,没用的端口就关掉。

最后处理好之后,cpu就降下来了,观察一段时间好像也没有重新再出来了,那应该就是处理好了。

最后总结一下整个思路吧:

先检查:

  1. top查看进程,看一下有没有没见过的,没印象的进程占用了较多资源

  1. 拿到pidsystemctl status [pid] 查看一下有没有守护进程;

  1. 如果有守护进程,进入守护进程的位置看一下有什么奇怪的文件

  1. 进入/etc/文件夹下,分别查看cron.dailycron.hourlycron.monthlycron.weekly这几个定时器文件夹里面有没有什么奇怪的文件

  1. crontab -l看看有什么定时任务

  1. 跑一下netstat -ltnp看看是不是有什么进程在监听端口。

再处理:

  1. 把在监听端口的进程kill掉,因为有可能是这个进程一直在写入我们定时任务;

  1. 跑一下crontabe把内容删掉,这个时候先等一段时间,看看还会不会重新写入,如果没有重新写入,那等于一步的那个一直写入定时器的进程我们是猜对了;如果还在继续写入,那还得继续找。

  1. killkthreaddk这个进程;

  1. 守护进程里面奇怪的文件也删掉;

最后观察:

  1. 观察crontab还有没有一直被覆盖写入

  1. 观察kthreaddk进程有没有再重复出现

附:

kthreadd是Linux的2号进程,是root用户的,检查进程的时候要看清楚名字,这个不是病毒进程哦。

原文地址:https://blog.csdn.net/HoZanDung/article/details/129704999

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任

如若转载,请注明出处:http://www.7code.cn/show_34848.html

如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱suwngjj01@126.com进行投诉反馈,一经查实,立即删除

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注