Linux性能優化實戰學習筆記：第十三講

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

解決方案1：

這是使用 CentOS 的同窗廣泛碰到的問題。在文章中，個人pidstat 輸出裏有一個 %wait 指標，表明進程等待 CPU 的時間百分比，

這是 systat 11.5.5 版本才引入的新指標，舊版本沒有這一項。而 CentOS 軟件庫裏的 sysstat 版本恰好比這個低，因此沒有這項指標。

解決方案2

查看proc文件系統，獲取本身想要的指標

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

一、分析過程：

使用 stress 沒法模擬 iowait 升高，可是卻看到sys 升高。這是由於案例中 的 stress -i 參數它表示經過系統調用 sync() 來模擬 I/O 的問題，但這種方法實際上並不可靠。

由於 sync() 的本意是刷新內存緩衝區的數據到磁盤中，以確保同步。若是緩衝區內原本就沒多少數據，那讀寫到磁盤中的，的數據也就很少，也就無法產生 I/O 壓力。

這一點，在使用 SSD 磁盤的環境中尤其明顯，極可能你的iowait老是 0，卻單純由於大量的系統調用，致使了系CPU 使用率 sys 升高。

二、解決方案：

使用 stress-ng 來代替 stress。

$ stress-ng -i 1 --hdd 1 --timeout 600

 -i 的含義仍是調用 sync，而—hdd 則表示讀寫臨時文件

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

 

 中斷在單核（只有一個邏輯 CPU）的機器上固然就沒有意義了，由於壓根兒就不會發生重調度的狀況。

一、過多的線程爭搶CPU

根據非自願上下文的含義，咱們都知道，這是過多的線程在爭搶 CPU致使的，其實這個結論也能夠從另外一個角度得到

pidstat -u -t 1

14: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% 沒有可比性

有些同窗會拿 pidstat 中的 %wait 跟 top 中的 iowait% （縮寫爲 wa）對比，其實這是沒有意義的，由於它們是徹底不相關的兩個指標。

pidstat 中， %wait 表示進程等待 CPU的時間百分比
top 中 ，iowait% 則表示等待 I/O 的 CPU的時間百分比

三、不一樣版本的 sysbench 運行參數也不是徹底同樣的

Ubuntu 18.04
sysbench --threads=10 --max-time=300 threads run

Ubuntu 16.04
sysbench --num-threads=10 --max-time=300 --test=threads run

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

 

 

一、磁盤性能差別

更是由於磁盤的巨大差別。好比，機械磁盤（HDD）、低端固態磁盤（SSD）與高端固態磁盤相比，性能差別可能達到數倍到數十倍

二、磁盤前綴差別

因爲我在案例中只查找了 /dev/xvd 和 /dev/sd前綴的磁盤，而沒有考慮到使用其餘前綴，磁盤（好比 /dev/nvme）的同窗。若是你正好用的是其餘
前綴，你可能會碰到跟 Vicky 相似的問題，也就是 app啓動後又很快退出，變成 exited 狀態。

因此，在最新的案例中，我爲 app 應用增長了三個選項。

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

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）輸出中，第一行數據跟其餘行差異巨大

[root@luoahong ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 7541212      0 151572    0    0   296   720   90  121  0  3 97  0  0
 0  0      0 7541212      0 151576    0    0     0     0   54  108  0  0 100  0  0
 0  0      0 7541212      0 151576    0    0     0     0   45   79  0  0 100  0  0
 0  0      0 7541212      0 151576    0    0     0     0   54   94  0  1 100  0  0

一、man vmstat

DESCRIPTION
vmstat reports information about processes, memory, paging, block IO, traps, disks and cpu activity.

The first report produced gives averages since the last reboot. Additional reports give information on a sampling period of length delay. The
process and memory reports are instantaneous in either case.

第一行數據是系統啓動以來的平均值其餘行纔是你在運行 vmstat 命令時設置的間隔時間的平均值。另外，進程和內存的報告內容都是即時數數據

 

學習是一個「從薄到厚再變薄」的過程，咱們從細節知識入手開始學習，積累到必定程度，須要整理成一個體系來記憶，這其中還要不斷地對這個體系進行細節修補，

有疑問、有反思才能夠達到最佳的學習效果。