kali在運行某程序後卡死了,在這裏做個排查筆記,確定哪個進程造成的,其他Linux應該也通用。
查看內存佔用
free -m
- 當物理內存快被耗盡時,系統並沒有崩潰,而是拿swap做臨時內存,當兩者都耗盡,系統就掛了
- 物理內存到達峯值,系統中可能一些不常用的進程內存佔用被挪用到swap區
- 當Mem區的資源進行釋放時,被挪到swap的內存並不會立即恢復
- Swap是內存不夠時虛擬出來的內存,處理速度不高
獲取佔用內存資源最多的10個進程
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +4|head
查看CPU佔用
top
#q退出
參數解讀
top - 02:55:05 /*當前時間*/ up 7 days,19:38, /*系統運行時間*/ 1 user, /*當前登錄用戶數*/ load average: 0.06, 1.57, 2.26 /*系統負載,即任務隊列的平均長度。三個數值分別爲 1分鐘、5分鐘、15分鐘前到現在的平均值*/
Tasks: 172 total, 1 running, 171 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.1 us, 0.8 sy, 0.0 ni, 97.8 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
/*第三、四行
total 進程總數
running 正在運行的進程數
sleeping 睡眠的進程數
stopped 停止的進程數
zombie 殭屍進程數
Cpu(s):
1.1% us 用戶空間佔用CPU百分比
0.8% sy 內核空間佔用CPU百分比
0.0% ni 用戶進程空間內改變過優先級的進程佔用CPU百分比
97.8% id 空閒CPU百分比
0.3% wa 等待輸入輸出的CPU時間百分比
0.0%hi:硬件CPU中斷佔用百分比
0.0%si:軟中斷佔用百分比
0.0%st:虛擬機佔用百分比*/
MiB Mem : 1992.1 total, 742.9 free, 760.1 used, 489.0 buff/cache
MiB Swap: 2045.0 total, 1340.2 free, 704.8 used. 1028.8 avail Mem
/*
Mem:
191272k total 物理內存總量
173656k used 使用的物理內存總量
17616k free 空閒內存總量
22052k buffers 用作內核緩存的內存量
Swap:
192772k total 交換區總量
0k used 使用的交換區總量
192772k free 空閒交換區總量
123988k cached 緩衝的交換區總量,內存中的內容被換出到交換區,而後又被換入到內存,但使用過的交換區尚未被覆蓋,該數值即爲這些內容已存在於內存中的交換區的大小,相應的內存再次被換出時可不必再對交換區寫入*/
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
76762 root 20 0 8104 4748 3188 S 0.0 0.2 0:00.01 bash
序號 列名 含義
a PID 進程id
b PPID 父進程id
c RUSER Real user name
d UID 進程所有者的用戶id
e USER 進程所有者的用戶名
f GROUP 進程所有者的組名
g TTY 啓動進程的終端名。不是從終端啓動的進程則顯示爲 ?
h PR 優先級
i NI nice值。負值表示高優先級,正值表示低優先級
j P 最後使用的CPU,僅在多CPU環境下有意義
k %CPU 上次更新到現在的CPU時間佔用百分比
l TIME 進程使用的CPU時間總計,單位秒
m TIME+ 進程使用的CPU時間總計,單位1/100秒
n %MEM 進程使用的物理內存百分比
o VIRT 進程使用的虛擬內存總量,單位kb。VIRT=SWAP+RES
p SWAP 進程使用的虛擬內存中,被換出的大小,單位kb。
q RES 進程使用的、未被換出的物理內存大小,單位kb。RES=CODE+DATA
r CODE 可執行代碼佔用的物理內存大小,單位kb
s DATA 可執行代碼以外的部分(數據段+棧)佔用的物理內存大小,單位kb
t SHR 共享內存大小,單位kb
u nFLT 頁面錯誤次數
v nDRT 最後一次寫入到現在,被修改過的頁面數。
w S 進程狀態(D=不可中斷的睡眠狀態,R=運行,S=睡眠,T=跟蹤/停止,Z=殭屍進程)
x COMMAND 命令名/命令行
y WCHAN 若該進程在睡眠,則顯示睡眠中的系統函數名
z Flags 任務標誌,參考 sched.h
獲取佔用CPU資源最多的10個進程:
ps aux|head -1;ps aux|grep -v PID|sort -rn -k +3|head
此外的一種場景就是遇到服務器挖礦型勒索病毒,也可以通過這種方法定位CPU異常的進程,確定病毒位置rm -rf
順便檢查定時任務目錄,防止死灰復燃/var/spool/cron
crontabs