嗶前嗶言
- 始終踐行費曼學習法
- 理解系統知識原理
- 掌握性能分析工具
- 多實踐,多思考,多提問
- 僅記錄我的的學習記錄,歡迎指點糾正
一、進程狀態
- R[Running/Runnable]:正在運行或正在等待運行的進程
- D[Disk Sleep]:不可中斷狀態睡眠,通常表示,進程正在跟硬件交互,而且交互過程當中不容許被其餘進程或中斷打斷
- Z[Zombie]殭屍進程,也就是該進程已結束,父進程未將其資源回收
- S[Interruptible Sleep]可中斷狀態睡眠,表示進程因等待某個事件而被系統掛起。當進程等待事件發生時,會被喚醒並進入R狀態
- I[Idle]空閒狀態,用在不可中斷睡眠的內核線程上。D狀態會致使平均負載升高,I狀態的進程不會。
- T/t[Stopped/Traced]進程處於暫停或跟蹤狀態[跟蹤狀態--特殊暫停狀態]
- X[Dead]進程已消亡,top/ps命令沒法觀察到消亡的進程
二、不可中斷狀態
進程正在硬件進行交互時docker
- 正常狀況下:不可中斷短期內就會結束,此時短時的不可中斷狀態進程,咱們通常能夠忽略
- 系統/硬件發生故障:進程就會保持長久的不可中斷狀態,須要注意,系統是否發生I/O性能的問題
三、殭屍進程
- 正常狀況下:父進程建立子進程,而後經過系統調用等待子進程結束,回收子進程資源,且子進程結束時,向父進程發送sigChld信號,父進程註冊sigChld信號處理函數,異步回收資源
- 異常狀況下:父進程沒有處理子進程,或子進程執行快於父進程,就容易致使子進程變成殭屍進程
四、總結
4.一、大量不可中斷進程和殭屍進程的處理方法:app
- iowait 過高,致使平均負載升高,且負載達到系統cpu的個數
- 殭屍進程在不斷增多
4.二、分析iowait升高的緣由異步
- 用dstat 命令同時查看cpu和I/O對比狀況,經過結果查看發現iowait 升高時,磁盤讀請求升高
- 定位磁盤讀的進程,使用top命令查看不可中斷狀態的進程PID
- 查看對應進程的磁盤讀寫狀況,使用pidstat -d 查看I/O使用狀況,發現處於不可中斷狀態的進程都沒有進行磁盤讀寫
- 繼續使用pidstat 命令,查看全部進程的I/O狀況,能夠定位到磁盤讀寫的進程
- 使用strace 查看進程的系統調用strace -p <pid>
- ps aux | grep <pid> 發現進程處於Z狀態,已變成殭屍狀態
- 若top 和pidstat 都不能找出問題,使用事件記錄的動態追蹤工具 perf record & perf report
4.三、殭屍進程
殭屍進程產生是由於父進程沒有回收子進程的資源,因此能夠經過使用pstree 查看父進程,而後查看父進程的源碼檢查函數
案例實踐
一、運行案例應用工具
docker run --privileged --name=app -itd feisky/app:iowait
二、輸入Ps命令,查看案例是否正常啓動。命令:ps aux | grep /app
性能
- S 可中斷睡眠狀態
- D 不可中斷睡覺狀態
- Ss+ ,其中,s表示這個進程是一個會話領導進程 ;+表示前臺進程組
進程組:一組互相關聯的進程,好比每一個子進程都是父進程所在組的成員
會話:指共享同一個控制終端的一個或多個進程組學習
三、使用top命令,查看下進程狀況
spa
ioWait線程
pstat 1 10 #每1秒輸出10組
3d
top命令,觀察D狀態的進程
pidstat -d 輸出I/O使用狀況
因此,咱們從 pidstat 的輸出中拿到進程的 PID 號,好比 6082,而後在終端中運行 strace 命令,並用 -p 參數指定 PID 號:
$ strace -p 97741
strace: attach: ptrace(PTRACE_SEIZE, 97741``): Operation not permitted
這兒出現了一個奇怪的錯誤,strace 命令竟然失敗了,而且命令報出的錯誤是沒有權限。
按理來講,咱們全部操做都已是以 root 用戶運行了,爲何還會沒有權限呢?你也能夠先想一下,碰到這種狀況,你會怎麼處理呢?
通常遇到這種問題時,我會先檢查一下進程的狀態是否正常。
好比,繼續在終端中運行 ps 命令,並使用 grep 找出剛纔的 6082 號進程:
$ ps aux | grep 97741
root 97741 0.0 0.0 0 0 pts/0 Z+ 13:43 0:00 [app] <defunct>
使用perf record -g
perf report 查看記錄
pstress 命令,查找父進程