案例:系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

chenlixin發表於2020-01-21

記錄《Linux效能最佳化》課程實踐過程。(可點選右方檢視目錄)

前言

等待 I/O 的 CPU 使用率(以下簡稱為 iowait)升高,也是最常見的一個伺服器效能問題。當 iowait 升高時,程式很可能因為得不到硬體的響應,而長時間處於不可中斷狀態。從 ps 或者 top 命令的輸出中,你可以發現它們都處於 D 狀態,也就是不可中斷狀態(Uninterruptible Sleep)。

程式狀態

top 和 ps 是最常用的檢視程式狀態的工具。如下:
【筆記】系統中出現大量不可中斷程式和殭屍程式怎麼辦?(上)

常見的程式狀態有哪些?

  • R 是 Running 或 Runnable 的縮寫,表示程式在 CPU 的就緒佇列中,正在執行或者正在等待執行。
  • D 是 Disk Sleep 的縮寫,也就是不可中斷狀態睡眠(Uninterruptible Sleep),一般表示程式正在跟硬體互動,並且互動過程不允許被其他程式或中斷打斷。
  • Z 是 Zombie 的縮寫,它表示殭屍程式,也就是程式實際上已經結束了,但是父程式還沒有回收它的資源(比如程式的描述符、PID 等)。
  • S 是 Interruptible Sleep 的縮寫,也就是可中斷狀態睡眠,表示程式因為等待某個事件而被系統掛起。當程式等待的事件發生時,它會被喚醒並進入 R 狀態。
  • I 是 Idle 的縮寫,也就是空閒狀態,用在不可中斷睡眠的核心執行緒上。前面說了,硬體互動導致的不可中斷程式用 D 表示,但對某些核心執行緒來說,它們有可能實際上並沒有任何負載,用 Idle 正是為了區分這種情況。要注意,D 狀態的程式會導致平均負載升高, I 狀態的程式卻不會。

除了以上 5 個狀態,程式還包括下面這 2 個狀態。

  • 第一個是 T 或者 t,也就是 Stopped 或 Traced 的縮寫,表示程式處於暫停或者跟蹤狀態。
  • 另一個是 X,也就是 Dead 的縮寫,表示程式已經消亡,所以你不會在 top 或者 ps 命令中看到它。

可以透過 man ps 檢視詳細解釋,如圖:
【筆記】系統中出現大量不可中斷程式和殭屍程式怎麼辦?

案例一

本案例是一個基於C開發的多程式應用,用來分析大量不可中斷狀態和殭屍狀態程式的問題。由於它的編譯和執行步驟比較麻煩,課程提供了 Docker 映象,只需要執行容器,就可以得到模擬環境。

環境準備

  • 虛擬機器(Ubuntu 18.04)
  • 機器配置:2 CPU,8GB 記憶體
  • 預先安裝 docker、sysstat、dstat 等工具,如 apt install docker.io dstat sysstat

開啟終端,SSH 登入到機器上,並安裝上面提到的工具。
預設以 root 使用者執行所有命令,先執行 sudo su root 命令切換到 root 使用者。

執行docker環境

docker run --privileged --name=app -itd feisky/app:iowait

下載過程可能比較緩慢… 下載完成後,執行 docker ps -a ,如圖:
【筆記】系統中出現大量不可中斷程式和殭屍程式怎麼辦?

輸入 ps 命令,確認案例應用是否已正常啟動。如下:

$ ps aux | grep /app

【筆記】系統中出現大量不可中斷程式和殭屍程式怎麼辦?

圖中,S 表示可中斷睡眠狀態,D 表示不可中斷睡眠狀態。關於 s 和 +,s 表示該程式是一個會話的領導程式,而 + 表示前臺程式組,可以透過 man ps 檢視詳細解釋。
【筆記】系統中出現大量不可中斷程式和殭屍程式怎麼辦?

關於程式組和會話,它們是用來管理一組相互關聯的程式。

  • 程式組表示一組相互關聯的程式,比如每個子程式都是父程式所在組的成員;
  • 而會話是指共享同一個控制終端的一個或多個程式組。

應用啟動前後的CPU狀態

可以執行命令 docker stop app,停止應用。執行命令 top(按下數字 1 切換到所有 CPU 的使用情況),如圖:
【筆記】系統中出現大量不可中斷程式和殭屍程式怎麼辦?

執行命令 docker start app,然後 top,最好是觀察5分鐘以上,如圖:
【筆記】系統中出現大量不可中斷程式和殭屍程式怎麼辦?

可以觀察到,我的機器出現了一些變化:

  • Load Average:過去 1 分鐘、5 分鐘和 15 分鐘內的平均負載在依次減小,說明平均負載正在升高;而 1 分鐘內的平均負載(2.18)已經達到系統的 CPU 個數,說明系統很可能已經有了效能瓶頸。
  • Tasks:有 1 個正在執行的程式,但殭屍程式比較多(114),而且還在不停增加,說明有子程式在退出時沒被清理。
  • 接下來看兩個 CPU 的使用率情況,使用者 CPU 使用率(us)不高,但系統CPU使用率(sy)和 iowait 有明顯的升高。
  • 最後再看每個程式的情況, CPU 使用率最高的程式是兩個(Z)程式,高達30%多;觀察過程中發現,在演變成 Z 狀態之前,app 是處於 D 狀態的,它們可能在等待 I/O,但光憑這裡並不能確定是它們導致了 iowait 升高。

彙總上述情況:

  • 第一點,啟動 app 應用程式後,iowait 確實升高了,系統的平均負載升高,甚至達到了系統 CPU 的個數。
  • 第二點,殭屍程式在不斷增多,說明有程式沒能正確清理子程式的資源。

注意,一開始我的虛擬機器只有 1 CPU,發現觀察不到任何情況。於是,我重新安裝虛擬機器,併為其分配了 2 CPU。

案例二

案例一發現了一些負載問題,但具體根源是什麼?還得繼續分析。

環境準備

與案例一保持一致。

執行docker環境

如下:

# 先刪除上次啟動的案例
$ docker rm -f app
# 重新執行案例
$ docker run --privileged --name=app -itd feisky/app:iowait

Ⅰ. iowait 分析

先來看一下 iowait 升高的問題。

1. dstat 檢視系統I/O

那麼什麼工具可以查詢系統的 I/O 情況呢?這裡推薦使用 dstat ,它的好處是,可以同時檢視 CPU 和 I/O 這兩種資源的使用情況,便於對比分析。

# 間隔1秒輸出10組資料
$ dstat 1 10

可以使用 docker stop/start app,觀察應用啟動前後的變化,如圖:
系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

可以看到,每當 iowait 升高(wai)時,對應的磁碟的讀請求(read)都會很大。這說明 iowait 的升高跟磁碟的讀請求有關,很可能就是磁碟讀導致的。

那到底是哪個程式在讀磁碟呢?再次關閉並重啟應用,top 觀察下輸出情況。
系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

重點關注下 D 狀態的程式,因為它們可能在等待I/O。

2. pidstat 檢視程式磁碟讀寫

使用 pidstat 檢視這些程式的磁碟讀寫情況,如下:

# -d 展示 I/O 統計資料,-p 指定程式號,間隔 1 秒輸出 3 組資料
$ pidstat -d -p XXX 1 3

系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

可以看到,這兩個程式目前並沒有任何磁碟讀寫。那要怎麼知道,到底是哪個程式在進行磁碟讀寫呢?

繼續使用 pidstat,這次觀察所有程式的 I/O 使用情況,如下:

# 間隔 1 秒輸出多組資料 (這裡是 20 組)
$ pidstat -d 1 20

如圖:

系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

可以發現,的確是 app 程式在進行磁碟讀,並且每秒讀的資料有 320 MB,看來就是 app 的問題。

不過,app 程式到底在執行啥 I/O 操作呢?這裡,注意程式使用者態和核心態的區別,程式想要訪問磁碟,就必須使用系統呼叫。

接著,嘗試找出 app 程式的系統呼叫。

3. strace 跟蹤程式系統呼叫

strace 是常用的跟蹤程式系統呼叫的工具。可以用 -p 引數指定 PID 號:

$ strace -p 6680

系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

圖中,提示 strace 命令執行失敗,沒有許可權。其實本身就處於 root 使用者,不應該沒有許可權的。

一般遇到這種問題時,先檢查一下程式的狀態是否正常。

$ ps aux | grep 6680

如圖:
系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

可以看到,程式 6680 已經變成了 Z 狀態,也就是殭屍程式。殭屍程式都是已經退出的程式,所以就沒法繼續分析它的系統呼叫。

至此,發現 top、pidstat 工具無法給出更多資訊。這時,可以求助那些基於事件記錄的動態追蹤工具,比如 perf。

4. perf 分析系統 CPU 時鐘事件

如下:

# 記錄效能事件,等待大約15秒後按 Ctrl+C 退出
$ perf record -g

# 檢視報告
$ perf report

保持 app 正常啟動狀態,執行以上命令。(如果提示命令 not found,按提示安裝即可)

如圖:

系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

圖中的 swapper 是核心中的排程程式,可以先忽略掉。

可以發現, app 的確在透過系統呼叫 sys_read() 讀取資料。並且從 new_sync_read 和 blkdev_direct_IO 能看出,程式正在對磁碟進行直接讀,也就是繞過了系統快取,每個讀請求都會從磁碟直接讀,這就可以解釋我們觀察到的 iowait 升高了。

關於 blkdev_direct_IO 可能會有點疑惑,可以查閱相關資料瞭解一下:

找到了問題的根源,那麼可以從程式碼層面,看是否能找到 直接I/O 的操作?

由於 app 是經過編譯後的 C 應用程式,所以還是直接看下課程提供的 C 原始碼 ,具體呼叫位置如下:

// O_DIRECT 選項開啟磁碟,於是繞過了系統快取,直接對磁碟進行讀寫。
int fd = open(disk, O_RDONLY | O_DIRECT | O_LARGEFILE, 0755);

5. 最佳化 iowait 問題

直接讀寫磁碟,對 I/O 敏感型應用(比如資料庫系統)是很友好的,因為你可以在應用中,直接控制磁碟的讀寫。但在大部分情況下,我們最好還是透過系統快取來最佳化磁碟 I/O,換句話說,刪除 O_DIRECT 這個選項就是了。

重新下載並啟動最佳化後的映象,如下:

# 首先刪除原來的應用
$ docker rm -f app
# 執行新的應用
$ docker run --privileged --name=app -itd feisky/app:iowait-fix1

重新 top 檢視最新輸出情況,如圖:
系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

可以發現,sy、iowait 確實有明顯的下降。不過,zombie 程式的數量還是在不斷上升的。

Ⅱ. 殭屍程式

接下來,處理殭屍程式的問題。既然殭屍程式是因為父程式沒有回收子程式的資源而出現的,那麼,要解決掉它們,就要找到它們的根兒,也就是找出父程式,然後在父程式裡解決。

1. pstree 分析程式呼叫關係

# -a 表示輸出命令列選項 -p 表PID -s 表示指定程式的父程式
$ pstree -aps XXX

嘗試找下 PID 5638 的父程式,如圖:

系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

執行完,你會發現 5638 號程式的父程式是 5630,也就是 app 應用。

所以,我們接著檢視 app 應用程式的程式碼,看看子程式結束的處理是否正確,比如有沒有呼叫 wait() 或 waitpid() ,抑或是,有沒有註冊 SIGCHLD 訊號的處理函式。

關於 父程式、子程式 可能會有點疑惑,可以查閱相關資料瞭解一下:

2. 檢視原始碼

檢視修復 iowait 後的原始碼檔案 app-fix1.c ,找到子程式的建立和清理的地方:

int status = 0;
// 死迴圈
for (;;) {
    for (i = 0; i < 2; i++) {
        if (fork() == 0) {
            sub_process(disk, buffer_size, buffer_count);
        }
    }
    sleep(5);
}

while (wait(&status) > 0);

很明顯,wait() 被放到了 for 死迴圈的外面,也就是說,wait() 函式實際上並沒被呼叫到。

3. 最佳化原始碼

修復程式碼,如下:

int status = 0;
// 死迴圈
for (;;) {
    for (i = 0; i < 2; i++) {
        if (fork() == 0) {
            sub_process(disk, buffer_size, buffer_count);
        }
    }
    while (wait(&status) > 0);
    sleep(5);
}

4. 檢視最佳化效果

# 先停止產生殭屍程式的 app
$ docker rm -f app
# 然後啟動新的 app
$ docker run --privileged --name=app -itd feisky/app:iowait-fix2

重新 top 檢視最新輸出情況,如圖:

系統中出現大量不可中斷程式(D)和殭屍程式(Z)怎麼辦?

可以看到,已經不再有殭屍程式堆積了。

結語

雖然本文案例是基於 C 語言,但我認為,解決問題的思路都是通用的。如果其他語言的應用遇到了類似問題,比如 PHP應用、Java應用,是不是也可以類似地去解決呢?

理論結合實踐,更能加深對知識的理解。如果有不明白的,也可以在評論區留言。

同時,我會把更多實踐案例歸納在 Linux 效能最佳化筆記 文章底部,歡迎閱讀。:smile:

本作品採用《CC 協議》,轉載必須註明作者和本文連結

相關文章