亚洲熟女综合色一区二区三区,亚洲精品中文字幕无码蜜桃,亚洲va欧美va日韩va成人网,亚洲av无码国产一区二区三区,亚洲精品无码久久久久久久

Linux CPU 上下文切換的故障排查

在我的上一篇文章:《探討 Linux CPU 的上下文切換》中,我談到了 CPU 上下文切換的工作原理??焖倩仡櫼幌?,CPU 上下文切換是保證 Linux 系統(tǒng)正常運(yùn)行的核心功能??煞譃?strong>進(jìn)程上下文切換、線程上下文切換中斷上下文切換。

在本文中,我將進(jìn)一步討論如何分析 CPU 上下文切換問題。

檢查 CPU 的上下文切換

我們知道,過多的上下文切換會消耗 CPU 的時間來保存和恢復(fù)寄存器、程序計(jì)數(shù)器、內(nèi)核棧和虛擬內(nèi)存等數(shù)據(jù),從而導(dǎo)致系統(tǒng)性能顯著下降。

既然上下文切換對系統(tǒng)性能的影響如此之大,那么我們?nèi)绾螜z查它呢?好了,你可以使用?vmstat?工具來查詢你系統(tǒng)的上下文切換。

vmstat

vmstat?是一種常用的系統(tǒng)性能分析工具。主要用于分析內(nèi)存使用情況,也常用于分析 CPU 上下文切換和中斷的次數(shù)。

例如?vmstat 5(5 秒輸出間隔):

Linux CPU 上下文切換的故障排查

讓我們看一下輸出:

  • cs(context switch):每秒上下文切換的次數(shù)。
  • in(interrupt):每秒的中斷數(shù)。
  • r(running | runnable):就緒隊(duì)列的長度,即正在運(yùn)行和等待 CPU 的進(jìn)程數(shù)。
  • b(blocked):處于不間斷睡眠狀態(tài)的進(jìn)程數(shù)。

在上面的例子中,我們可以看到上下文切換次數(shù)為?33?次,系統(tǒng)中斷次數(shù)為?25?次,就緒隊(duì)列長度,不間斷狀態(tài)進(jìn)程數(shù)均為?0。

pidstat

vmstat?工具只給出了系統(tǒng)的整體上下文切換的信息。要查看每個進(jìn)程的詳細(xì)信息,您需要使用?pidstat。添加?-w?選項(xiàng),您可以看到每個進(jìn)程的上下文切換:

例如:

Linux CPU 上下文切換的故障排查

結(jié)果中有兩列需要我們注意:cswch?和?nvcswch。其中,cswch?表示每秒自愿上下文切換的次數(shù),nvcswch?表示每秒非自愿上下文切換的次數(shù)。

  • 自愿上下文切換:指進(jìn)程無法獲得所需資源而導(dǎo)致的上下文切換。例如,當(dāng) I/O 和內(nèi)存等系統(tǒng)資源不足時,就會發(fā)生自愿上下文切換。
  • 非自愿上下文切換:指進(jìn)程因時間片已過期而被系統(tǒng)強(qiáng)制重新調(diào)度時發(fā)生的上下文切換。例如,當(dāng)大量進(jìn)程競爭 CPU 時,很容易發(fā)生非自愿的上下文切換。

您必須牢記這兩個概念,因?yàn)樗鼈円馕吨煌男阅軉栴}。

案例分析

既然您知道如何查看這些指標(biāo),那么就會出現(xiàn)另一個問題,上下文切換頻率多久才是正常的呢?讓我們看一個示例案例。

我們將使用?sysbench?(https://github.com/akopytov/sysbenc),一個多線程的基準(zhǔn)測試工具通過生成負(fù)載來模擬上下文切換過多的問題。假設(shè)您已經(jīng)在 Linux 系統(tǒng)上安裝了?sysbench?和?sysstat

在我們模擬負(fù)載之前,讓我們在一個終端中運(yùn)行一下?vmstat

Linux CPU 上下文切換的故障排查

在這里可以看到當(dāng)前的上下文切換次數(shù)?cs?是?35,中斷次數(shù)?in?是?19,r?和?b?都是?0。由于我目前沒有其他任務(wù)在運(yùn)行,因此它們是空閑系統(tǒng)中的上下文切換數(shù)量。

現(xiàn)在讓我們運(yùn)行?sysbench?來模擬多線程調(diào)度系統(tǒng)的瓶頸:

Linux CPU 上下文切換的故障排查

現(xiàn)在,您應(yīng)該會看到?vmstat?輸出了與上面不同的結(jié)果:

Linux CPU 上下文切換的故障排查

應(yīng)該可以發(fā)現(xiàn)?cs?欄的上下文切換次數(shù)從之前的?35?次突增到?139?萬次。同時,注意觀察其他幾個指標(biāo):

  • r:就緒隊(duì)列的長度已達(dá)到?8
  • us?和?syus?和?sy?的 CPU 使用率加起來是?100%,系統(tǒng) CPU 使用率是?84%,說明 CPU 主要被內(nèi)核占用。
  • in:中斷數(shù)也上升到了?10000,說明中斷處理也是一個潛在的問題。

結(jié)合這些指標(biāo)我們可以知道系統(tǒng)的就緒隊(duì)列太長了,也就是有太多的進(jìn)程在運(yùn)行等待 CPU,導(dǎo)致大量的上下文切換,而大量的上下文切換導(dǎo)致了系統(tǒng) CPU 使用率的增長。

那么是什么過程導(dǎo)致了這些問題呢?

我們繼續(xù)分析,同時在第三個終端使用?pidstat,看看 CPU 和進(jìn)程上下文切換的情況:

Linux CPU 上下文切換的故障排查

從?pidstat?的輸出可以發(fā)現(xiàn),CPU 使用率的增加確實(shí)是?sysbench?造成的,它的 CPU 使用率已經(jīng)達(dá)到了?100%。但上下文切換來自其他進(jìn)程,包括非自愿上下文切換頻率最高的?pidstat,以及自愿上下文切換頻率最高的內(nèi)核線程?kworker?和?sshd。

注意:默認(rèn)情況下?pidstat?只顯示進(jìn)程的上下文切換,如果要查看實(shí)際線程的上下文切換,請?zhí)砑?-t?選項(xiàng)。

中斷

要找出中斷數(shù)量也很高的原因所在,您可以檢查?/proc/interrupts?文件。該文件會提供一個只讀的中斷使用情況。

Linux CPU 上下文切換的故障排查

觀察一段時間后,可以發(fā)現(xiàn)變化最快的是重新調(diào)度中斷(RES, REScheduling interrupt)。這種中斷類型表明處于空閑狀態(tài)的 CPU 被喚醒以調(diào)度新的任務(wù)運(yùn)行。所以這里的中斷增加是因?yàn)樘嗟娜蝿?wù)調(diào)度問題,這和前面上下文切換次數(shù)的分析結(jié)果是一致的

現(xiàn)在回到最初的問題,每秒多少次上下文切換是正常的?

這個值實(shí)際上取決于系統(tǒng)本身的 CPU 性能。在我看來,如果系統(tǒng)的上下文切換次數(shù)比較穩(wěn)定的話,幾百到一萬應(yīng)該是正常的。但是,當(dāng)上下文切換次數(shù)超過?10000,或者切換次數(shù)快速增加時,很可能是出現(xiàn)了性能問題。

結(jié)論

此時,你應(yīng)該可以根據(jù)上下文切換的類型做一些具體的分析了。

  • 自愿上下文切換較多,說明進(jìn)程在等待資源,可能會出現(xiàn) I/O 飽和等其他問題。
  • 非自愿上下文切換較多,說明進(jìn)程正在被強(qiáng)制調(diào)度,也就是都在爭搶 CPU,說明 CPU 確實(shí)產(chǎn)生了瓶頸。
  • 中斷次數(shù)增多,說明 CPU 被中斷處理程序占用,需要通過查看?/proc/interrupts?文件來分析具體的中斷類型。

鏈接:https://blog.devgenius.io/linux-cpu-context-switch-troubleshooting-bda45883e59e

(版權(quán)歸原作者所有,侵刪)

相關(guān)新聞

歷經(jīng)多年發(fā)展,已成為國內(nèi)好評如潮的Linux云計(jì)算運(yùn)維、SRE、Devops、網(wǎng)絡(luò)安全、云原生、Go、Python開發(fā)專業(yè)人才培訓(xùn)機(jī)構(gòu)!