[root@zwlbs3 ~]# top
i. 發現有個進程CPU使用率竟然700%,COMMAND 是一些隨機的字符串組成,完了~ 中標了;第一想到就是「沙雕」它,kill 命令給我上。服務器
[root@zwlbs3 ~]# kill -9 "PID"
ii. 可是發現 kill 該進程平靜一會後又啓動了。oracle
注:老圖複用,PID、COMMAND 都有變化。spa
[root@zwlbs3 ~]# cd /proc/748/ [root@zwlbs3 748]# ls -ial # "748"是該進程的 PID,根據你的 PID 來查看便可。
如圖:線程
發現該進程是在 /dev/shm 目錄下的,/dev/shm 是一個什麼目錄呢?3d
1) 首先能夠看出來/dev/shm是一個設備文件, 能夠把/dev/shm看做是系統內存的入口, 能夠把它看作是一塊物理存儲設備,一個tmp filesystem, 你能夠經過這個設備向內存中讀寫文件, 以加快某些I/O高的操做,好比對一個大型文件頻繁的open, write, read。日誌
2) 聽說oracle就利用了/dev/shm(shitou沒用過oracle), 能夠經過mount命令列出當前的/dev/shm的掛載的文件系統。code
3) 既然是基於內存的文件系統,系統重啓後/dev/shm下的文件就不存在了。Linux默認(CentOS)/dev/shm分區的大小是系統物理內存的50%, 雖然說使用/dev/shm對文件操做的效率會高不少。可是目前各發行軟件中卻不多有使用它的(除了前面提到的Oracle), 能夠經過ls /dev/shm查看下面是否有文件, 若是沒有就說明當前系統並無使用該設備。blog
[root@zwlbs3 ~]# ls -a /dev/shm/ . .. # 沒有任何相關的文件,奇怪了。
i. 查看某個進程內部線程佔用狀況分析進程
[root@zwlbs3 ~]# top -H -p "PID"
ii. 原來有這麼多相關的進程,所有 kill 掉crontab
iii. 過來幾分鐘再次檢查,發現系統負載恢復正常
本覺得解決了,結果過了幾個小時檢查發現又出現了,該死的。
因爲生產環境不方便重啓服務器,被逼無奈狀況下只好試試 重啓大法 了。
重啓服務器後一個小時,再次檢查已經恢復正常了,仍是 重啓大法 好使。