問題 1：性能工具版本太低，導(dǎo)致指標(biāo)不全

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

問題 2：使用 stress 命令，無法模擬 iowait 高的場(chǎng)景

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

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

這個(gè)問題是說，即使運(yùn)行了大量的線程，也無法模擬出重調(diào)度中斷 RES 升高的問題。其實(shí)我在 CPU 上下文切換的案例中已經(jīng)提到，重調(diào)度中斷是調(diào)度器用來分散任務(wù)到不同 CPU 的機(jī)制，也就是可以喚醒空閑狀態(tài)的 CPU ，來調(diào)度新任務(wù)運(yùn)行，而這通常借助處理器間中斷(Inter-Processor Interrupts，IPI)來實(shí)現(xiàn)。所以，這個(gè)中斷在單核(只有一個(gè)邏輯 CPU)的機(jī)器上當(dāng)然就沒有意義了，因?yàn)閴焊鶅壕筒粫?huì)發(fā)生重調(diào)度的情況。不過，正如留言所說，上下文切換的問題依然存在，所以你會(huì)看到， cs(context switch)從幾百增加到十幾萬，同時(shí) sysbench 線程的自愿上下文切換和非自愿上下文切換也都會(huì)大幅上升，特別是非自愿上下文切換，會(huì)上升到十幾萬。根據(jù)非自愿上下文的含義，我們都知道，這是過多的線程在爭(zhēng)搶 CPU。其實(shí)這個(gè)結(jié)論也可以從另一個(gè)角度獲得。比如，你可以在 pidstat 的選項(xiàng)中，加入 -u 和 -t 參數(shù)，輸出線程的 CPU 使用情況，你會(huì)看到下面的界面：$ 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 ...從這個(gè) pidstat 的輸出界面，你可以發(fā)現(xiàn)，每個(gè) stress 線程的 %wait 高達(dá) 70%，而 CPU 使用率只有不到 10%。換句話說， stress 線程大部分時(shí)間都消耗在了等待 CPU 上，這也表明，確實(shí)是過多的線程在爭(zhēng)搶 CPU。在這里順便提一下，留言中很常見的一個(gè)錯(cuò)誤。有些同學(xué)會(huì)拿 pidstat 中的 %wait 跟 top 中的 iowait% (縮寫為 wa)對(duì)比，其實(shí)這是沒有意義的，因?yàn)樗鼈兪峭耆幌嚓P(guān)的兩個(gè)指標(biāo)。pidstat 中， %wait 表示進(jìn)程等待 CPU 的時(shí)間百分比。top 中 ，iowait% 則表示等待 I/O 的 CPU 時(shí)間百分比。回憶一下我們學(xué)過的進(jìn)程狀態(tài)，你應(yīng)該記得，等待 CPU 的進(jìn)程已經(jīng)在 CPU 的就緒隊(duì)列中，處于運(yùn)行狀態(tài)；而等待 I/O 的進(jìn)程則處于不可中斷狀態(tài)。另外，不同版本的 sysbench 運(yùn)行參數(shù)也不是完全一樣的。比如，在案例 Ubuntu 18.04 中，運(yùn)行 sysbench 的格式為：$ sysbench --threads=10 --max-time=300 threads run而在 Ubuntu 16.04 中，運(yùn)行格式則為(感謝 Haku 留言分享的執(zhí)行命令)：$ sysbench --num-threads=10 --max-time=300 --test=threads run

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

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

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

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

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

這個(gè)問題主要是說，在執(zhí)行 vmstat 時(shí)，第一行數(shù)據(jù)跟其他行相比較，數(shù)值相差特別大。我相信不少同學(xué)都注意到了這個(gè)現(xiàn)象，這里我簡(jiǎn)單解釋一下。首先還是要記住，我總強(qiáng)調(diào)的那句話，在碰到直觀上解釋不了的現(xiàn)象時(shí)，要第一時(shí)間去查命令手冊(cè)。比如，運(yùn)行 man vmstat 命令，你可以在手冊(cè)中發(fā)現(xiàn)下面這句話：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.?也就是說，第一行數(shù)據(jù)是系統(tǒng)啟動(dòng)以來的平均值，其他行才是你在運(yùn)行 vmstat 命令時(shí)，設(shè)置的間隔時(shí)間的平均值。另外，進(jìn)程和內(nèi)存的報(bào)告內(nèi)容都是即時(shí)數(shù)值。你看，這并不是什么不得了的事故，但如果我們不清楚這一點(diǎn)，很可能卡住我們的思維，阻止我們進(jìn)一步的分析。這里我也不得不提一下，文檔的重要作用。授之以魚，不如授之以漁。我們專欄的學(xué)習(xí)核心，一定是教會(huì)你性能分析的原理和思路，性能工具只是我們的路徑和手段。所以，在提到各種性能工具時(shí)，我并沒有詳細(xì)解釋每個(gè)工具的各種命令行選項(xiàng)的作用，一方面是因?yàn)槟愫苋菀淄ㄟ^文檔查到這些，另一方面就是不同版本、不同系統(tǒng)中，個(gè)別選項(xiàng)的含義可能并不相同。所以，不管因?yàn)槟膫€(gè)因素，自己 man 一下，一定是最快速并且最準(zhǔn)確的方式。特別是，當(dāng)你發(fā)現(xiàn)某些工具的輸出不符合常識(shí)時(shí)，一定記住，第一時(shí)間查文檔弄明白。實(shí)在讀不懂文檔的話，再上網(wǎng)去搜，或者在專欄里向我提問。學(xué)習(xí)是一個(gè)“從薄到厚再變薄”的過程，我們從細(xì)節(jié)知識(shí)入手開始學(xué)習(xí)，積累到一定程度，需要整理成一個(gè)體系來記憶，這其中還要不斷地對(duì)這個(gè)體系進(jìn)行細(xì)節(jié)修補(bǔ)。有疑問、有反思才可以達(dá)到最佳的學(xué)習(xí)效果。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。