文章對 Linux 系統下進程的幾種狀態進行介紹，并對系統出現大量僵尸進程和不可中斷進程的場景進行分析，使用常用的幾種工具進行問題分析定位。

1、進程狀態

top 和 ps 是最常用的查看進程狀態的工具，下面是 top 命令輸出的示例，S 列(也就是 Status 列)表示進程的狀態。

上面數據的 S 列可以看到 R、D、S、I 、Z 幾個狀態，下面對進程的這幾種狀態進行介紹。

R 狀態：R 是 Running 或 Runnable 的縮寫，表示進程在 CPU 的就緒隊列中，正在運行或者正在等待運行。

D 狀態：D 是 Disk Sleep 的縮寫，也就是不可中斷狀態睡眠(Uninterruptible Sleep)，一般表示進程正在跟硬件交互，并且交互過程不允許被其他進程或中斷打斷。

Z 狀態：Z 是 Zombie 的縮寫，它表示僵尸進程，也就是進程實際上已經結束了，但是父進程還沒有回收它的資源(比如進程的描述符、PID 等)。

S 狀態：S 是 Interruptible Sleep 的縮寫，也就是可中斷狀態睡眠，表示進程因為等待某個事件而被系統掛起。當進程等待的事件發生時，它會被喚醒并進入 R 狀態。

I 狀態：I 是 Idle 的縮寫，也就是空閑狀態，用在不可中斷睡眠的內核線程上。硬件交互導致的不可中斷進程用 D 表示，但對某些內核線程來說，它們有可能實際上并沒有任何負載，用 Idle 正是為了區分這種情況。要注意，D 狀態的進程會導致平均負載升高， I 狀態的進程卻不會。

進程的狀態除了上面的狀態之外，還有 T 和 t 狀態，這兩種狀態都表示進程處于停止狀態，但使得進程停止的原因有所差異，如下所示。

T 狀態：由信號觸發的停止狀態，比如向一個進程發送 SIGSTOP 信號，它就會因響應這個信號變成暫停狀態(Stopped);再向它發送 SIGCONT 信號，進程又會恢復運行(如果進程是終端里直接啟動的，則需要你用 fg 命令，恢復到前臺運行)。

t 狀態：由調試跟蹤觸發的停止狀態，當使用調試器(如 gdb)調試一個進程時，在使用斷點中斷進程后，進程就會變成跟蹤狀態，這其實也是一種特殊的暫停狀態，只不過可以用調試器來跟蹤并按需要控制進程的運行。

2、案例分析

本案例模擬多進程對磁盤進行讀取，使用相關的性能分析工具對例程出現的性能問題進行分析，案例源碼在文章后面，編譯出的可執行程序名稱為 app。

2.1 異常信息分析

在 Ubuntu 系統中打開一個終端，執行 app 進程，打開第二個終端，使用 top 命令查看進程運行狀態，如下所示。

對上面圖片中的信息進行分析，找出系統可能存在的異常情況。

第一行中過去 15 分鐘、5 分鐘、1 分鐘的平均負載依次升高，說明平均負載正在升高，過去 1 分鐘的平均負載已經快接近 CPU 的個數，說明系統可能已經出現了性能瓶頸。

第二行中存在較多的僵尸進程，說明子進程退出時沒有被回收。

查看 CPU 信息，用戶 CPU 使用率較低，系統 CPU 使用率和 iowait 有所上升。

查看每個進程的信息，當前運行 app 進程的 CPU 使用率為 20% 左右，且這兩個進程的狀態為 D 狀態，說明該進程有可能正在等待 I/O。

對以上分析進行總結，得出以下兩點結論。

系統中僵尸進程在不斷增加，說明程序沒有正確回收子進程的資源。

系統平均負載在升高，CPU 使用率和 iowait 有所上升，說明平均負載的升高可能是 iowait 引起的，iowait 與系統調用有關。

2.2 iowait 分析

根據上面得出的結論，系統平均負載的上升可能是由于 iowait 引起的，這里推薦一個查看系統 I/O 情況的工具，dstat 可以同時查看 CPU 和 I/O 這兩種資源的使用情況，便于對比分析，以 1 秒為間隔，連續輸出10組數據，如下所示。

從 dstat 的輸出可以看到，當 iowait(wai)高時，磁盤的讀請求(read)都會很大。這說明 iowait 的升高跟磁盤的讀請求有關，很可能就是磁盤讀導致的。

接下來，需要找出讀取磁盤的進程，上面 top 的輸出中，進程 id 為 6758 和 6759 的進程處于 D 狀態，使用 pidstat 查看這兩個進程的情況，-d 參數可以顯示 I/O 的使用情況，如下所示。

上圖進程 ID 為 6758 和 6759 的進程 kB_rd/s 數據值為 0，說明不是這兩個進程在讀取磁盤數據，繼續使用 pidstat 查看所有進程的 I/O 使用情況，如下所示(以 1 秒為間隔，輸出 3 組數據)。

上圖中 app 進程的 kB_rd/s 的值較大，最大達到 211MB/s，說明 iowait 升高就是 app 進程在讀取數據導致的。進程分為用戶態和內核態，進程想要訪問磁盤，就必須使用系統調用，這也是通過 top 查看時，系統 CPU 和 iowait 一起升高的原因，接下來的重點就是找出 app 進程的系統調用。

strace 工具可以查看進程的系統調用棧，指定 pid 查看進程的系統調用棧，如下所示。

上圖操作顯示無權限，但是當前終端權限已經為 root，檢查一下進程的狀態是否正常，如下所示。

根據圖片信息可以看到，當前進程 ID 為 6945 的 app 進程狀態為僵尸狀態，僵尸進程是已經退出的進程，所以就沒法兒繼續分析它的系統調用。

之前提到的 perf 工具，也可以查看進程的調用關系，使用"perf record -g"命令記錄調用關系，等待 10 秒左右，使用"perf report"命令報告調用關系，展開 app 進程的調用關系，如下所示。

app 通過系統調用 sys_read() 讀取數據，從 new_sync_read 和 blkdev_direct_IO 可以看出，進程正在對磁盤進行直接讀，也就是繞過了系統緩存，每個讀請求都會從磁盤直接讀，這其實就是導致 iowait 升高的原因，查看 app.c 中磁盤的打開方式，如下所示。

直接讀寫磁盤，是直接控制磁盤的讀寫，不借助系統緩存的優化進行操作，這會導致讀寫性能受到 I/O 瓶頸的限制，一般直接讀寫只應用于對 I/O 敏感型的場景，比如數據庫系統。但在大部分情況下，最好還是通過系統緩存來優化磁盤 I/O，在例程中刪除 O_DIRECT 這個選項。

修改后啟動 app 進程，然后使用 top 工具查看系統信息，如下所示，當前平均負載、CPU 使用率和 iowait 已經非常低了，說明剛才的改動已經成功修復了 iowait 高導致系統平均負載升高的問題。

2.3 僵尸進程問題分析

僵尸進程是因為父進程沒有回收子進程的資源造成的，因此，要解決僵尸進程的問題，就要找出父進程，然后在父進程里等待回收子進程，可以通過 pstree 找出子進程對應的父進程，如下所示(-a 表示顯示命令行選項，p表PID，s表示指定進程的父進程)。

通過上面圖片看到，進程 id 為 3574 進程的父進程是 3571，還是 app 進程，接下來查看 app 應用程序的代碼，分析子進程結束的處理是否正確，比如有沒有調用 wait() 或 waitpid() ，抑或是，有沒有注冊 SIGCHLD 信號的處理函數。app 應用程序對子進程的創建和清理代碼如下。

這段代碼雖然看起來調用了 wait() 函數等待子進程結束，但卻錯誤地把 wait() 放到了 for 死循環的外面，wait() 函數實際上并沒被調用到，把它挪到 for 循環的里面就可以了。修改后，可以使用 top 命令檢查一下，發現系統的僵尸進程數量一直為 0。

2.4 例程源碼