1. 問題發(fā)現(xiàn)

[root@zwlbs3 ~]# top

i. 發(fā)現(xiàn)有個(gè)進(jìn)程CPU使用率居然700%，COMMAND 是一些隨機(jī)的字符串組成，完了~ 中標(biāo)了；第一想到就是“沙雕”它，kill 命令給我上。

[root@zwlbs3 ~]# kill -9 "PID"

ii. 但是發(fā)現(xiàn) kill 該進(jìn)程平靜一會(huì)后又啟動(dòng)了。

注：老圖復(fù)用，PID、COMMAND 都有變化。

2. 查看進(jìn)程的詳細(xì)信息

[root@zwlbs3 ~]# cd /proc/748/
[root@zwlbs3 748]# ls -ial

# "748"是該進(jìn)程的 PID，根據(jù)你的 PID 來查看即可。

如圖：

發(fā)現(xiàn)該進(jìn)程是在 /dev/shm 目錄下的，/dev/shm 是一個(gè)什么目錄呢？

從網(wǎng)上摘下來一段我們解一下 /dev/shm

1) 首先可以看出來/dev/shm是一個(gè)設(shè)備文件, 可以把/dev/shm看作是系統(tǒng)內(nèi)存的入口, 可以把它看做是一塊物理存儲(chǔ)設(shè)備，一個(gè)tmp filesystem, 你可以通過這個(gè)設(shè)備向內(nèi)存中讀寫文件, 以加快某些I/O高的操作，比如對(duì)一個(gè)大型文件頻繁的open, write, read。

2) 據(jù)說oracle就利用了/dev/shm(shitou沒用過oracle), 可以通過mount命令列出當(dāng)前的/dev/shm的掛載的文件系統(tǒng)。

3) 既然是基于內(nèi)存的文件系統(tǒng)，系統(tǒng)重啟后/dev/shm下的文件就不存在了。Linux默認(rèn)(CentOS)/dev/shm分區(qū)的大小是系統(tǒng)物理內(nèi)存的50%, 雖說使用/dev/shm對(duì)文件操作的效率會(huì)高很多。但是目前各發(fā)行軟件中卻很少有使用它的(除了前面提到的Oracle), 可以通過ls /dev/shm查看下面是否有文件, 如果沒有就說明當(dāng)前系統(tǒng)并沒有使用該設(shè)備。

查看 /dev/shm 目錄的有沒有相關(guān)文件

[root@zwlbs3 ~]# ls -a /dev/shm/
. ..

# 沒有任何相關(guān)的文件，奇怪了。

• crontab 也沒有相關(guān)計(jì)劃任務(wù)。
• 使用 which 命令也沒有找到相關(guān)的文件。
• 查看系統(tǒng)日志也是正常，非常奇怪。
• 幾乎沒有找到該進(jìn)程相關(guān)的文件。

3. 解決辦法

i. 查看某個(gè)進(jìn)程內(nèi)部線程占用情況分析

[root@zwlbs3 ~]# top -H -p "PID"

ii. 原來有這么多相關(guān)的進(jìn)程，全部 kill 掉

iii. 過來幾分鐘再次檢查，發(fā)現(xiàn)系統(tǒng)負(fù)載恢復(fù)正常

本以為解決了，結(jié)果過了幾個(gè)小時(shí)檢查發(fā)現(xiàn)又出現(xiàn)了，該死的。

由于生產(chǎn)環(huán)境不方便重啟服務(wù)器，被逼無(wú)奈情況下只好試試 重啟大法 了。

4. 重啟大法

重啟服務(wù)器后一個(gè)小時(shí)，再次檢查已經(jīng)恢復(fù)正常了，還是 重啟大法 好使。

該惡意程序有什么作用？為何只消耗CPU資源？由于未找到相關(guān)文件信息，原因也暫時(shí)未清楚。

知道的大佬麻煩告訴我一下，非常感謝！

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。