上一節(jié)，我給你講了 CPU 上下文切換的工作原理。簡(jiǎn)單回顧一下，CPU 上下文切換是保證 Linux 系統(tǒng)正常工作的一個(gè)核心功能，按照不同場(chǎng)景，可以分為進(jìn)程上下文切換、線程上下文切換和中斷上下文切換。具體的概念和區(qū)別，你也要在腦海中過(guò)一遍，忘了的話及時(shí)查看上一篇。今天我們就接著來(lái)看，究竟怎么分析 CPU 上下文切換的問(wèn)題。

怎么查看系統(tǒng)的上下文切換情況

通過(guò)前面學(xué)習(xí)我們知道，過(guò)多的上下文切換，會(huì)把 CPU 時(shí)間消耗在寄存器、內(nèi)核棧以及虛擬內(nèi)存等數(shù)據(jù)的保存和恢復(fù)上，縮短進(jìn)程真正運(yùn)行的時(shí)間，成了系統(tǒng)性能大幅下降的一個(gè)元兇。既然上下文切換對(duì)系統(tǒng)性能影響那么大，你肯定迫不及待想知道，到底要怎么查看上下文切換呢？在這里，我們可以使用 vmstat 這個(gè)工具，來(lái)查詢系統(tǒng)的上下文切換情況。vmstat 是一個(gè)常用的系統(tǒng)性能分析工具，主要用來(lái)分析系統(tǒng)的內(nèi)存使用情況，也常用來(lái)分析 CPU 上下文切換和中斷的次數(shù)。比如，下面就是一個(gè) vmstat 的使用示例：# 每隔 5 秒輸出 1 組數(shù)據(jù) $ vmstat 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st0 0 0 7005360 91564 818900 0 0 0 0 25 33 0 0 100 0 0我們一起來(lái)看這個(gè)結(jié)果，你可以先試著自己解讀每列的含義。在這里，我重點(diǎn)強(qiáng)調(diào)下，需要特別關(guān)注的四列內(nèi)容：

• cs(context switch)是每秒上下文切換的次數(shù)。
• in(interrupt)則是每秒中斷的次數(shù)。
• r(Running or Runnable)是就緒隊(duì)列的長(zhǎng)度，也就是正在運(yùn)行和等待 CPU 的進(jìn)程數(shù)。
• b(Blocked)則是處于不可中斷睡眠狀態(tài)的進(jìn)程數(shù)。

可以看到，這個(gè)例子中的上下文切換次數(shù) cs 是 33 次，而系統(tǒng)中斷次數(shù) in 則是 25 次，而就緒隊(duì)列長(zhǎng)度 r 和不可中斷狀態(tài)進(jìn)程數(shù) b 都是 0。vmstat 只給出了系統(tǒng)總體的上下文切換情況，要想查看每個(gè)進(jìn)程的詳細(xì)情況，就需要使用我們前面提到過(guò)的 pidstat 了。給它加上 -w 選項(xiàng)，你就可以查看每個(gè)進(jìn)程上下文切換的情況了。比如說(shuō)：# 每隔 5 秒輸出 1 組數(shù)據(jù) $ pidstat -w 5 Linux 4.15.0 (ubuntu) 09/23/18 _x86_64_ (2 CPU)08:18:26 UID PID cswch/s nvcswch/s Command 08:18:31 0 1 0.20 0.00 systemd 08:18:31 0 8 5.40 0.00 rcu_sched ...這個(gè)結(jié)果中有兩列內(nèi)容是我們的重點(diǎn)關(guān)注對(duì)象。一個(gè)是 cswch ，表示每秒自愿上下文切換(voluntary context switches)的次數(shù)，另一個(gè)則是 nvcswch ，表示每秒非自愿上下文切換(non voluntary context switches)的次數(shù)。這兩個(gè)概念你一定要牢牢記住，因?yàn)樗鼈円馕吨煌男阅軉?wèn)題：

• 所謂自愿上下文切換，是指進(jìn)程無(wú)法獲取所需資源，導(dǎo)致的上下文切換。比如說(shuō)， I/O、內(nèi)存等系統(tǒng)資源不足時(shí)，就會(huì)發(fā)生自愿上下文切換。
• 而非自愿上下文切換，則是指進(jìn)程由于時(shí)間片已到等原因，被系統(tǒng)強(qiáng)制調(diào)度，進(jìn)而發(fā)生的上下文切換。比如說(shuō)，大量進(jìn)程都在爭(zhēng)搶 CPU 時(shí)，就容易發(fā)生非自愿上下文切換。

案例分析

知道了怎么查看這些指標(biāo)，另一個(gè)問(wèn)題又來(lái)了，上下文切換頻率是多少次才算正常呢？別急著要答案，同樣的，我們先來(lái)看一個(gè)上下文切換的案例。通過(guò)案例實(shí)戰(zhàn)演練，你自己就可以分析并找出這個(gè)標(biāo)準(zhǔn)了。

你的準(zhǔn)備

今天的案例，我們將使用 sysbench 來(lái)模擬系統(tǒng)多線程調(diào)度切換的情況。sysbench 是一個(gè)多線程的基準(zhǔn)測(cè)試工具，一般用來(lái)評(píng)估不同系統(tǒng)參數(shù)下的數(shù)據(jù)庫(kù)負(fù)載情況。當(dāng)然，在這次案例中，我們只把它當(dāng)成一個(gè)異常進(jìn)程來(lái)看，作用是模擬上下文切換過(guò)多的問(wèn)題。下面的案例基于 Ubuntu 18.04，當(dāng)然，其他的 Linux 系統(tǒng)同樣適用。我使用的案例環(huán)境如下所示：機(jī)器配置：2 CPU，8GB 內(nèi)存預(yù)先安裝 sysbench 和 sysstat 包，如 apt install sysbench sysstat正式操作開始前，你需要打開三個(gè)終端，登錄到同一臺(tái) Linux 機(jī)器中，并安裝好上面提到的兩個(gè)軟件包。包的安裝，可以先 Google 一下自行解決，如果仍然有問(wèn)題的，在留言區(qū)寫下你的情況。另外注意，下面所有命令，都默認(rèn)以 root 用戶運(yùn)行。所以，如果你是用普通用戶登陸的系統(tǒng)，記住先運(yùn)行 sudo su root 命令切換到 root 用戶。安裝完成后，你可以先用 vmstat 看一下空閑系統(tǒng)的上下文切換次數(shù)：# 間隔 1 秒后輸出 1 組數(shù)據(jù) $ vmstat 1 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st0 0 0 6984064 92668 830896 0 0 2 19 19 35 1 0 99 0 0這里你可以看到，現(xiàn)在的上下文切換次數(shù) cs 是 35，而中斷次數(shù) in 是 19，r 和 b 都是 0。因?yàn)檫@會(huì)兒我并沒(méi)有運(yùn)行其他任務(wù)，所以它們就是空閑系統(tǒng)的上下文切換次數(shù)。

操作和分析

接下來(lái)，我們正式進(jìn)入實(shí)戰(zhàn)操作。首先，在第一個(gè)終端里運(yùn)行 sysbench ，模擬系統(tǒng)多線程調(diào)度的瓶頸：# 以 10 個(gè)線程運(yùn)行 5 分鐘的基準(zhǔn)測(cè)試，模擬多線程切換的問(wèn)題 $ sysbench --threads=10 --max-time=300 threads run 接著，在第二個(gè)終端運(yùn)行 vmstat ，觀察上下文切換情況：# 每隔 1 秒輸出 1 組數(shù)據(jù)(需要 Ctrl+C 才結(jié)束) $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st6 0 0 6487428 118240 1292772 0 0 0 0 9019 1398830 16 84 0 0 08 0 0 6487428 118240 1292772 0 0 0 0 10191 1392312 16 84 0 0 0你應(yīng)該可以發(fā)現(xiàn)，cs 列的上下文切換次數(shù)從之前的 35 驟然上升到了 139 萬(wàn)。同時(shí)，注意觀察其他幾個(gè)指標(biāo)：

• r 列：就緒隊(duì)列的長(zhǎng)度已經(jīng)到了 8，遠(yuǎn)遠(yuǎn)超過(guò)了系統(tǒng) CPU 的個(gè)數(shù) 2，所以肯定會(huì)有大量的 CPU 競(jìng)爭(zhēng)。
• us(user)和 sy(system)列：這兩列的 CPU 使用率加起來(lái)上升到了 100%，其中系統(tǒng) CPU 使用率，也就是 sy 列高達(dá) 84%，說(shuō)明 CPU 主要是被內(nèi)核占用了。
• in 列：中斷次數(shù)也上升到了 1 萬(wàn)左右，說(shuō)明中斷處理也是個(gè)潛在的問(wèn)題。

綜合這幾個(gè)指標(biāo)，我們可以知道，系統(tǒng)的就緒隊(duì)列過(guò)長(zhǎng)，也就是正在運(yùn)行和等待 CPU 的進(jìn)程數(shù)過(guò)多，導(dǎo)致了大量的上下文切換，而上下文切換又導(dǎo)致了系統(tǒng) CPU 的占用率升高。那么到底是什么進(jìn)程導(dǎo)致了這些問(wèn)題呢？我們繼續(xù)分析，在第三個(gè)終端再用 pidstat 來(lái)看一下， CPU 和進(jìn)程上下文切換的情況：# 每隔 1 秒輸出 1 組數(shù)據(jù)(需要 Ctrl+C 才結(jié)束) # -w 參數(shù)表示輸出進(jìn)程切換指標(biāo)，而 -u 參數(shù)則表示輸出 CPU 使用指標(biāo) $ pidstat -w -u 1 08:06:33 UID PID %usr %system %guest %wait %CPU CPU Command 08:06:34 0 10488 30.00 100.00 0.00 0.00 100.00 0 sysbench 08:06:34 0 26326 0.00 1.00 0.00 0.00 1.00 0 kworker/u4:208:06:33 UID PID cswch/s nvcswch/s Command 08:06:34 0 8 11.00 0.00 rcu_sched 08:06:34 0 16 1.00 0.00 ksoftirqd/1 08:06:34 0 471 1.00 0.00 hv_balloon 08:06:34 0 1230 1.00 0.00 iscsid 08:06:34 0 4089 1.00 0.00 kworker/1:5 08:06:34 0 4333 1.00 0.00 kworker/0:3 08:06:34 0 10499 1.00 224.00 pidstat 08:06:34 0 26326 236.00 0.00 kworker/u4:2 08:06:34 1000 26784 223.00 0.00 sshd從 pidstat 的輸出你可以發(fā)現(xiàn)，CPU 使用率的升高果然是 sysbench 導(dǎo)致的，它的 CPU 使用率已經(jīng)達(dá)到了 100%。但上下文切換則是來(lái)自其他進(jìn)程，包括非自愿上下文切換頻率最高的 pidstat ，以及自愿上下文切換頻率最高的內(nèi)核線程 kworker 和 sshd。不過(guò)，細(xì)心的你肯定也發(fā)現(xiàn)了一個(gè)怪異的事兒：pidstat 輸出的上下文切換次數(shù)，加起來(lái)也就幾百，比 vmstat 的 139 萬(wàn)明顯小了太多。這是怎么回事呢？難道是工具本身出了錯(cuò)嗎？別著急，在懷疑工具之前，我們?cè)賮?lái)回想一下，前面講到的幾種上下文切換場(chǎng)景。其中有一點(diǎn)提到， Linux 調(diào)度的基本單位實(shí)際上是線程，而我們的場(chǎng)景 sysbench 模擬的也是線程的調(diào)度問(wèn)題，那么，是不是 pidstat 忽略了線程的數(shù)據(jù)呢？通過(guò)運(yùn)行 man pidstat ，你會(huì)發(fā)現(xiàn)，pidstat 默認(rèn)顯示進(jìn)程的指標(biāo)數(shù)據(jù)，加上 -t 參數(shù)后，才會(huì)輸出線程的指標(biāo)。所以，我們可以在第三個(gè)終端里， Ctrl+C 停止剛才的 pidstat 命令，再加上 -t 參數(shù)，重試一下看看：# 每隔 1 秒輸出一組數(shù)據(jù)(需要 Ctrl+C 才結(jié)束) # -wt 參數(shù)表示輸出線程的上下文切換指標(biāo) $ pidstat -wt 1 08:14:05 UID TGID TID cswch/s nvcswch/s Command ... 08:14:05 0 10551 - 6.00 0.00 sysbench 08:14:05 0 - 10551 6.00 0.00 |__sysbench 08:14:05 0 - 10552 18911.00 103740.00 |__sysbench 08:14:05 0 - 10553 18915.00 100955.00 |__sysbench 08:14:05 0 - 10554 18827.00 103954.00 |__sysbench ...現(xiàn)在你就能看到了，雖然 sysbench 進(jìn)程(也就是主線程)的上下文切換次數(shù)看起來(lái)并不多，但它的子線程的上下文切換次數(shù)卻有很多。看來(lái)，上下文切換罪魁禍?zhǔn)?#xff0c;還是過(guò)多的 sysbench 線程。我們已經(jīng)找到了上下文切換次數(shù)增多的根源，那是不是到這兒就可以結(jié)束了呢？當(dāng)然不是。不知道你還記不記得，前面在觀察系統(tǒng)指標(biāo)時(shí)，除了上下文切換頻率驟然升高，還有一個(gè)指標(biāo)也有很大的變化。是的，正是中斷次數(shù)。中斷次數(shù)也上升到了 1 萬(wàn)，但到底是什么類型的中斷上升了，現(xiàn)在還不清楚。我們接下來(lái)繼續(xù)抽絲剝繭找源頭。既然是中斷，我們都知道，它只發(fā)生在內(nèi)核態(tài)，而 pidstat 只是一個(gè)進(jìn)程的性能分析工具，并不提供任何關(guān)于中斷的詳細(xì)信息，怎樣才能知道中斷發(fā)生的類型呢？沒(méi)錯(cuò)，那就是從 /proc/interrupts 這個(gè)只讀文件中讀取。/proc 實(shí)際上是 Linux 的一個(gè)虛擬文件系統(tǒng)，用于內(nèi)核空間與用戶空間之間的通信。/proc/interrupts 就是這種通信機(jī)制的一部分，提供了一個(gè)只讀的中斷使用情況。我們還是在第三個(gè)終端里， Ctrl+C 停止剛才的 pidstat 命令，然后運(yùn)行下面的命令，觀察中斷的變化情況：# -d 參數(shù)表示高亮顯示變化的區(qū)域 $ watch -d cat /proc/interruptsCPU0 CPU1 ... RES: 2450431 5279697 Rescheduling interrupts ...觀察一段時(shí)間，你可以發(fā)現(xiàn)，變化速度最快的是重調(diào)度中斷(RES)，這個(gè)中斷類型表示，喚醒空閑狀態(tài)的 CPU 來(lái)調(diào)度新的任務(wù)運(yùn)行。這是多處理器系統(tǒng)(SMP)中，調(diào)度器用來(lái)分散任務(wù)到不同 CPU 的機(jī)制，通常也被稱為處理器間中斷(Inter-Processor Interrupts，IPI)。所以，這里的中斷升高還是因?yàn)檫^(guò)多任務(wù)的調(diào)度問(wèn)題，跟前面上下文切換次數(shù)的分析結(jié)果是一致的。通過(guò)這個(gè)案例，你應(yīng)該也發(fā)現(xiàn)了多工具、多方面指標(biāo)對(duì)比觀測(cè)的好處。如果最開始時(shí)，我們只用了 pidstat 觀測(cè)，這些很嚴(yán)重的上下文切換線程，壓根兒就發(fā)現(xiàn)不了了。現(xiàn)在再回到最初的問(wèn)題，每秒上下文切換多少次才算正常呢？這個(gè)數(shù)值其實(shí)取決于系統(tǒng)本身的 CPU 性能。在我看來(lái)，如果系統(tǒng)的上下文切換次數(shù)比較穩(wěn)定，那么從數(shù)百到一萬(wàn)以內(nèi)，都應(yīng)該算是正常的。但當(dāng)上下文切換次數(shù)超過(guò)一萬(wàn)次，或者切換次數(shù)出現(xiàn)數(shù)量級(jí)的增長(zhǎng)時(shí)，就很可能已經(jīng)出現(xiàn)了性能問(wèn)題。這時(shí)，你還需要根據(jù)上下文切換的類型，再做具體分析。比方說(shuō)：

• 自愿上下文切換變多了，說(shuō)明進(jìn)程都在等待資源，有可能發(fā)生了 I/O 等其他問(wèn)題；
• 非自愿上下文切換變多了，說(shuō)明進(jìn)程都在被強(qiáng)制調(diào)度，也就是都在爭(zhēng)搶 CPU，說(shuō)明 CPU 的確成了瓶頸；
• 中斷次數(shù)變多了，說(shuō)明 CPU 被中斷處理程序占用，還需要通過(guò)查看 /proc/interrupts 文件來(lái)分析具體的中斷類型。

小結(jié)

今天，我通過(guò)一個(gè) sysbench 的案例，給你講了上下文切換問(wèn)題的分析思路。碰到上下文切換次數(shù)過(guò)多的問(wèn)題時(shí)，我們可以借助 vmstat 、 pidstat 和 /proc/interrupts 等工具，來(lái)輔助排查性能問(wèn)題的根源。

思考

最后，我想請(qǐng)你一起來(lái)聊聊，你之前是怎么分析和排查上下文切換問(wèn)題的。你可以結(jié)合這兩節(jié)的內(nèi)容和你自己的實(shí)際操作，來(lái)總結(jié)自己的思路。歡迎在留言區(qū)和我討論，也歡迎把這篇文章分享給你的同事、朋友。我們一起在實(shí)戰(zhàn)中演練，在交流中學(xué)習(xí)。 與50位技術(shù)專家面對(duì)面20年技術(shù)見(jiàn)證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的04 | 基础篇：经常说的 CPU 上下文切换是什么意思？（下）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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