問題 1：性能工具版本太低，導致指標不全

這是使用 CentOS 的同學普遍碰到的問題。在文章中，我的 pidstat 輸出里有一個 %wait 指標，代表進程等待 CPU 的時間百分比，這是 systat 11.5.5 版本才引入的新指標，舊版本沒有這一項。而 CentOS 軟件庫里的 sysstat 版本剛好比這個低，所以沒有這項指標。不過，你也不用擔心。前面我就強調過，工具只是查找分析的手段，指標才是我們重點分析的對象。如果你的 pidstat 里沒有顯示，自然還有其他手段能找到這個指標。比如說，在講解系統原理和性能工具時，我一般會介紹一些 proc 文件系統的知識，教你看懂 proc 文件系統提供的各項指標。之所以這么做，一方面，當然是為了讓你更直觀地理解系統的工作原理；另一方面，其實是想給你展示，性能工具上能看到的各項性能指標的原始數據來源。這樣，在實際生產環境中，即使你很可能需要運行老版本的操作系統，還沒有權限安裝新的軟件包，你也可以查看 proc 文件系統，獲取自己想要的指標。但是，性能分析的學習，我還是建議你要用最新的性能工具來學。新工具有更全面的指標，讓你更容易上手分析。這個絕對的優勢，可以讓你更直觀地得到想要的數據，也不容易讓你打退堂鼓。當然，初學時，你最好試著去理解性能工具的原理，或者熟悉了使用方法后，再回過頭重新學習原理。這樣，即使是在無法安裝新工具的環境中，你仍然可以從 proc 文件系統或者其他地方，獲得同樣的指標，進行有效的分析。

問題 2：使用 stress 命令，無法模擬 iowait 高的場景

使用 stress 無法模擬 iowait 升高，但是卻看到了 sys 升高。這是因為案例中 的 stress -i 參數，它表示通過系統調用 sync() 來模擬 I/O 的問題，但這種方法實際上并不可靠。因為 sync() 的本意是刷新內存緩沖區的數據到磁盤中，以確保同步。如果緩沖區內本來就沒多少數據，那讀寫到磁盤中的數據也就不多，也就沒法產生 I/O 壓力。這一點，在使用 SSD 磁盤的環境中尤為明顯，很可能你的 iowait 總是 0，卻單純因為大量的系統調用，導致了系統 CPU 使用率 sys 升高。這種情況，我在留言中也回復過，推薦使用 stress-ng 來代替 stress。擔心你沒有看到留言，所以這里我再強調一遍。你可以運行下面的命令，來模擬 iowait 的問題。# -i 的含義還是調用 sync，而—hdd 則表示讀寫臨時文件 $ stress-ng -i 1 --hdd 1 --timeout 600

問題 3：無法模擬出 RES 中斷的問題

這個問題是說，即使運行了大量的線程，也無法模擬出重調度中斷 RES 升高的問題。其實我在 CPU 上下文切換的案例中已經提到，重調度中斷是調度器用來分散任務到不同 CPU 的機制，也就是可以喚醒空閑狀態的 CPU ，來調度新任務運行，而這通常借助處理器間中斷(Inter-Processor Interrupts，IPI)來實現。所以，這個中斷在單核(只有一個邏輯 CPU)的機器上當然就沒有意義了，因為壓根兒就不會發生重調度的情況。不過，正如留言所說，上下文切換的問題依然存在，所以你會看到， cs(context switch)從幾百增加到十幾萬，同時 sysbench 線程的自愿上下文切換和非自愿上下文切換也都會大幅上升，特別是非自愿上下文切換，會上升到十幾萬。根據非自愿上下文的含義，我們都知道，這是過多的線程在爭搶 CPU。其實這個結論也可以從另一個角度獲得。比如，你可以在 pidstat 的選項中，加入 -u 和 -t 參數，輸出線程的 CPU 使用情況，你會看到下面的界面：$ pidstat -u -t 114:24:03 UID TGID TID %usr %system %guest %wait %CPU CPU Command 14:24:04 0 - 2472 0.99 8.91 0.00 77.23 9.90 0 |__sysbench 14:24:04 0 - 2473 0.99 8.91 0.00 68.32 9.90 0 |__sysbench 14:24:04 0 - 2474 0.99 7.92 0.00 75.25 8.91 0 |__sysbench 14:24:04 0 - 2475 2.97 6.93 0.00 70.30 9.90 0 |__sysbench 14:24:04 0 - 2476 2.97 6.93 0.00 68.32 9.90 0 |__sysbench ...從這個 pidstat 的輸出界面，你可以發現，每個 stress 線程的 %wait 高達 70%，而 CPU 使用率只有不到 10%。換句話說， stress 線程大部分時間都消耗在了等待 CPU 上，這也表明，確實是過多的線程在爭搶 CPU。在這里順便提一下，留言中很常見的一個錯誤。有些同學會拿 pidstat 中的 %wait 跟 top 中的 iowait% (縮寫為 wa)對比，其實這是沒有意義的，因為它們是完全不相關的兩個指標。pidstat 中， %wait 表示進程等待 CPU 的時間百分比。top 中 ，iowait% 則表示等待 I/O 的 CPU 時間百分比?；貞浺幌挛覀儗W過的進程狀態，你應該記得，等待 CPU 的進程已經在 CPU 的就緒隊列中，處于運行狀態；而等待 I/O 的進程則處于不可中斷狀態。另外，不同版本的 sysbench 運行參數也不是完全一樣的。比如，在案例 Ubuntu 18.04 中，運行 sysbench 的格式為：$ sysbench --threads=10 --max-time=300 threads run而在 Ubuntu 16.04 中，運行格式則為(感謝 Haku 留言分享的執行命令)：$ sysbench --num-threads=10 --max-time=300 --test=threads run

問題 4：無法模擬出 I/O 性能瓶頸，以及 I/O 壓力過大的問題

這個問題可以看成是上一個問題的延伸，只是把 stress 命令換成了一個在容器中運行的 app 應用。事實上，在 I/O 瓶頸案例中，除了上面這個模擬不成功的留言，還有更多留言的內容剛好相反，說的是案例 I/O 壓力過大，導致自己的機器出各種問題，甚至連系統都沒響應了。之所以這樣，其實還是因為每個人的機器配置不同，既包括了 CPU 和內存配置的不同，更是因為磁盤的巨大差異。比如，機械磁盤(HDD)、低端固態磁盤(SSD)與高端固態磁盤相比，性能差異可能達到數倍到數十倍。其實，我自己所用的案例機器也只是低端的 SSD，比機械磁盤稍微好一些，但跟高端固態磁盤還是比不了的。所以，相同操作下，我的機器上剛好出現 I/O 瓶頸，但換成一臺使用機械磁盤的機器，可能磁盤 I/O 就被壓死了(表現為使用率長時間 100%)，而換上好一些的 SSD 磁盤，可能又無法產生足夠的 I/O 壓力。另外，由于我在案例中只查找了 /dev/xvd 和 /dev/sd 前綴的磁盤，而沒有考慮到使用其他前綴磁盤(比如 /dev/nvme)的同學。如果你正好用的是其他前綴，你可能會碰到跟 Vicky 類似的問題，也就是 app 啟動后又很快退出，變成 exited 狀態。在這里，berryfl 同學提供了一個不錯的建議：可以在案例中增加一個參數指定塊設備，這樣有需要的同學就不用自己編譯和打包案例應用了。所以，在最新的案例中，我為 app 應用增加了三個選項。

• -d 設置要讀取的磁盤，默認前綴為 /dev/sd 或者 /dev/xvd 的磁盤。
• -s 設置每次讀取的數據量大小，單位為字節，默認為 67108864(也就是 64MB)。
• -c 設置每個子進程讀取的次數，默認為 20 次，也就是說，讀取 20*64MB 數據后，子進程退出。

你可以點擊 Github 查看它的源碼，使用方法我寫在了這里：$ docker run --privileged --name=app -itd feisky/app:iowait /app -d /dev/sdb -s 67108864 -c 20案例運行后，你可以執行 docker logs 查看它的日志。正常情況下，你可以看到下面的輸出：$ docker logs app Reading data from disk /dev/sdb with buffer size 67108864 and count 20

問題 5：性能工具(如 vmstat)輸出中，第一行數據跟其他行差別巨大

這個問題主要是說，在執行 vmstat 時，第一行數據跟其他行相比較，數值相差特別大。我相信不少同學都注意到了這個現象，這里我簡單解釋一下。首先還是要記住，我總強調的那句話，在碰到直觀上解釋不了的現象時，要第一時間去查命令手冊。比如，運行 man vmstat 命令，你可以在手冊中發現下面這句話：The first report produced gives averages since the last reboot.? Additional reports give information on a sam‐?pling period of length delay.? The process and memory reports are instantaneous in either case.?也就是說，第一行數據是系統啟動以來的平均值，其他行才是你在運行 vmstat 命令時，設置的間隔時間的平均值。另外，進程和內存的報告內容都是即時數值。你看，這并不是什么不得了的事故，但如果我們不清楚這一點，很可能卡住我們的思維，阻止我們進一步的分析。這里我也不得不提一下，文檔的重要作用。授之以魚，不如授之以漁。我們專欄的學習核心，一定是教會你性能分析的原理和思路，性能工具只是我們的路徑和手段。所以，在提到各種性能工具時，我并沒有詳細解釋每個工具的各種命令行選項的作用，一方面是因為你很容易通過文檔查到這些，另一方面就是不同版本、不同系統中，個別選項的含義可能并不相同。所以，不管因為哪個因素，自己 man 一下，一定是最快速并且最準確的方式。特別是，當你發現某些工具的輸出不符合常識時，一定記住，第一時間查文檔弄明白。實在讀不懂文檔的話，再上網去搜，或者在專欄里向我提問。學習是一個“從薄到厚再變薄”的過程，我們從細節知識入手開始學習，積累到一定程度，需要整理成一個體系來記憶，這其中還要不斷地對這個體系進行細節修補。有疑問、有反思才可以達到最佳的學習效果。

總結

以上是生活随笔為你收集整理的13 | 答疑（一）：无法模拟出 RES 中断的问题，怎么办？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。