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

1、進程狀態(tài)

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

上面數(shù)據(jù)的 S 列可以看到 R、D、S、I 、Z 幾個狀態(tài)，下面對進程的這幾種狀態(tài)進行介紹。

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

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

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

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

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

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

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

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

2、案例分析

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

2.1 異常信息分析

在 Ubuntu 系統(tǒng)中打開一個終端，執(zhí)行 app 進程，打開第二個終端，使用 top 命令查看進程運行狀態(tài)，如下所示。

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

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

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

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

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

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

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

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

2.2 iowait 分析

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

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

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

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

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

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

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

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

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

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

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

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

2.3 僵尸進程問題分析

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

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

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

2.4 例程源碼