1. 问题发现
[root@zwlbs3 ~]# top
i. 发现有个进程 CPU 使用率居然 700%,COMMAND 是一些随机的字符串组成, 完了~ 中标了; 第一想到就是 "沙雕" 它, kill 命令给我上.
[root@zwlbs3 ~]# kill -9 "PID"
ii. 但是发现 kill 该进程平静一会后又启动了.
注: 老图复用, PID,COMMAND 都有变化.
2. 查看进程的详细信息
- [root@zwlbs3 ~]# cd /proc/748/
- [root@zwlbs3 748]# ls -ial
- # "748" 是该进程的 PID, 根据你的 PID 来查看即可.
如图:
发现该进程是在 /dev/shm 目录下的,/dev/shm 是一个什么目录呢?
从网上摘下来一段我们解一下 /dev/shm
1) 首先可以看出来 / dev/shm 是一个设备文件, 可以把 / dev/shm 看作是系统内存的入口, 可以把它看做是一块物理存储设备, 一个 tmp filesystem, 你可以通过这个设备向内存中读写文件, 以加快某些 I/O 高的操作, 比如对一个大型文件频繁的 open, write, read.
2) 据说 oracle 就利用了 / dev/shm(shitou 没用过 oracle), 可以通过 mount 命令列出当前的 / dev/shm 的挂载的文件系统.
3) 既然是基于内存的文件系统, 系统重启后 / dev/shm 下的文件就不存在了. Linux 默认 (CentOS)/dev/shm 分区的大小是系统物理内存的 50%, 虽说使用 / dev/shm 对文件操作的效率会高很多. 但是目前各发行软件中却很少有使用它的 (除了前面提到的 Oracle), 可以通过 ls /dev/shm 查看下面是否有文件, 如果没有就说明当前系统并没有使用该设备.
查看 /dev/shm 目录的有没有相关文件
- [root@zwlbs3 ~]# ls -a /dev/shm/
- . ..
- # 没有任何相关的文件, 奇怪了.
crontab 也没有相关计划任务.
使用 which 命令也没有找到相关的文件.
查看系统日志也是正常, 非常奇怪.
几乎没有找到该进程相关的文件.
3. 解决办法
i. 查看某个进程内部线程占用情况分析
[root@zwlbs3 ~]# top -H -p "PID"
ii. 原来有这么多相关的进程, 全部 kill 掉
iii. 过来几分钟再次检查, 发现系统负载恢复正常
本以为解决了, 结果过了几个小时检查发现又出现了, 该死的.
由于生产环境不方便重启服务器, 被逼无奈情况下只好试试 重启大法 了.
4. 重启大法
重启服务器后一个小时, 再次检查已经恢复正常了, 还是 重启大法好使.
该恶意程序有什么作用? 为何只消耗 CPU 资源? 由于未找到相关文件信息, 原因也暂时未清楚.
知道的大佬麻烦告诉我一下, 非常感谢!
来源: https://www.cnblogs.com/l-hh/p/11358038.html