我相信有一些人看到這篇文章的標題肯定有種不想看的感覺，因為這樣的內容實在被寫得太多太多了。操作系統分析嘛，無非就是 CPU 使用率、I/O 使用率、內存使用率、網絡使用率等各種使用率的描述。
然而因為視角的不同，在性能測試和分析中，這始終是我們繞不過去的分析點。我們得知道什么時候才需要去分析操作系統，以及要分析操作系統的什么內容。
首先，我們前面在性能分析方法中提到，性能分析要有起點，通常情況下，這個起點就是響應時間、TPS 等壓力工具給出來的信息。
我們判斷了有瓶頸之后，通過拆分響應時間就可以知道在哪個環節上出了問題，再去詳細分析這個操作系統。這就需要用到我們的分析決策樹了。
在分段分層確定了這個系統所運行的應用有問題之后，還要記起另一件事情，就是前面提到的“全局—定向”的監控思路。
既然說到了全局，我們得先知道操作系統中，都有哪些大的模塊。這里就到了幾乎所有性能測試人員看到就想吐的模塊了，CPU、I/O、Memory、Network…
沒辦法，誰讓操作系統就這么點東西呢。我先畫一個思維導圖給你看一下。
我很努力地把一些常見指標的相應關系都畫到了圖中，你是不是已經看暈了？看暈就對了，別着急。我們先要知道的是，面對這些大的模塊，到底要用什么的監控手段來實現對它們的監控呢？
要知道，在一篇文章中不可能詳盡地描述操作系統，我會盡量把我工作中經常使用到的一些和性能分析相關的、使用頻度高的知識點整理給你。
監控命令
我們經常用到的 Linux 監控命令大概有這些：top、atop、vmstat、iostat、iotop、dstat、sar等……
請你注意我這里列的監控命令是指可以監控到相應模塊的計數器，而不是說只能監控這個模塊，因為大部分命令都是綜合的工具集。
像這樣的監控工具還能列上一堆，但這並不是關鍵，關鍵的是我們在什么時候能想起來用這些工具，以及知道這些工具的局限性。
比如說 top，它能看 CPU、內存、Swap、線程列表等信息，也可以把 I/O 算進去，因為它有 CPU 的 wa 計數器，但是它看不了 Disk 和 Network，這就是明顯的局限性。之后出現的atop對很多內容做了整理，有了 Disk 和 Net 信息，但是呢，在一些 Linux 發行版中又不是默認安裝的。vmstat呢？它能看 CPU、內存、隊列、Disk、System、Swap 等信息，但是它又看不了線程列表和網絡信息。
像這樣的局限，我還能說上兩千字。當工具讓你眼花繚亂的時候，不要忘記最初的目標，我們要監控的是這幾大模塊：CPU、I/O、Memory、Network、System、Swap。
然后，我們再來對應前面提到的“全局—定向”監控的思路。如果你現在僅用命令來監控這個系統，你要執行哪幾個呢？
對應文章前面的思維導圖，我們做一個細致的表格。
你會發現，vmstat可以看 Swap，但它能看的是si和so，看不到其他的計數器，但是top可以看到這些計數器……像這樣的細節還有很多。
因為計數器非常多，又不是每個都常用。但是萬一某個時候就需要用了呢？這個時候如果你不知道的話，就無法繼續分析下去。
這里我主要想告訴你什么呢？就是用命令的時候，你要知道這個命令能干什么，不能干什么。你可能會說，有這些么多的計數器，還有這么多的命令，光學個 OS 我得學到啥時候去？
我要告訴你的是監控的思考邏輯。你要知道的是，正是因為你要監控 CPU 的某個計數器才執行了這個命令，而不是因為自己知道這個命令才去執行。這個關系我們一定要搞清楚。
那么邏輯就是這樣的：
比如說，我想看下 OS 各模塊的性能表現，所以執行 top 這個命令看了一些計數器，同時我又知道，網絡的信息在top中是看不到的，所以我要把 OS 大模塊看完，還要用netstat看網絡，以此類推。
如果你還是覺得這樣不能直接刺激到你的神經，懵懂不知道看哪些命令。那么在這里，我用上面的工具給你做一個表格。
命令模塊對照表：
有了這些命令墊底之后，下面我們來看常用的監控平台。
監控平台 Grafana+Prometheus+node_exporter
這是現在用得比較多的監控平台了。在微服務時代，再加上 Kubernetes+Docker 的盛行，這個監控套裝幾乎是干 IT 的都知道。我們來看一下常用的 Dashboard。
為了理解上的通用性，我這里都用默認的信息，不用自己定制的。Grafana.com 官方 ID：8919 的模板內容如下：
還記得我們要看系統的模塊是哪幾個嗎？
- CPU
- Memory
- I/O
- Network
- System
- Swap
你可以自己對一下，是不是大模塊都沒有漏掉？確實沒有。但是！上面的計數器你得理解。
我們先來看一下 CPU。
上圖中有了 System、User、I/O Wait、Total，還記得我們上面說 top 里有 8 個 CPU 計數器吧，這里就 4 個怎么辦？
Total 這個值的計算方式是這樣的：
1 - avg(irate(node_cpu_seconds_total{instance=~"$node",mode="idle"}[30m])) by (instance)
也就是說，它包括除了空閑 CPU 的其他所有 CPU 使用率，這其實就有 ni、hi、si、st、guest、gnice 的值。當我們在這個圖中看到 System、User、I/O Wait 都不高時，如果 Total 很高，那就是 ni、hi、si、st、guest、gnice 計數器中的某個值大了。這時你要想找問題，就得自己執行命令查看了。
看完 CPU 之后，再看一下 Network。
上圖中有網絡流量圖。可以看到只有“上傳下載”，這個值似乎容易理解，但是不夠細致。node_exportor 還提供了一個“網絡連接信息”圖。可以看到 Sockets_used、CurrEstab、TCP_alloc、TCP_tw、UDP_inuse 這些值，它們所代表的含義如下：
- Sockets_used：已使用的所有協議套接字總量
- CurrEstab：當前狀態為 ESTABLISHED 或 CLOSE-WAIT 的 TCP 連接數
- TCP_alloc：已分配（已建立、已申請到 sk_buff）的 TCP 套接字數量
- TCP_tw：等待關閉的 TCP 連接數
- UDP_inuse：正在使用的 UDP 套接字數量
這些值也可以通過查看“cat /proc/net/sockstat”知道。這是監控工具套裝給我們提供的便利，然后我們再來看下 Memory。
上圖中有總內存、可用內存、已用內存這三個值。如果從應用的角度來看，我們現在對內存的分析，就要和語言相關了。像 Java 語言，一般會去分析 JVM。我們對操作系統的物理內存的使用並不關注，在大部分場景下物理內存並沒有成為我們的瓶頸點，但這並不是說在內存上就沒有調優的空間了。
關於內存這一塊，我不想展開太多。因為展開之后內容太多了，如果你有興趣的話，可以找內存管理的資料來看看。其他幾個模塊我就不再一一列了，I/O、System、Swap 也都是有監控數據的。
從全局監控的角度上看，這些計數器也基本夠看。但是對於做性能分析、定位瓶頸來說，這些值顯然是不夠的。
還記得我在前面提到的“先全局監控再定向監控”找證據鏈的理念吧。像 node_exporter 這樣的監控套裝給我們提供的就是全局監控的數據，就是大面上覆蓋了，細節上仍然不夠。那怎么辦呢？
下面我就來一一拆解一下。
CPU
關於 CPU 的計數器，已經有很多的信息了。這里我再啰嗦一下。CPU 常見的計數器是 top 中的 8 個值，也就是下面這些：
%Cpu(s): 0.7 us, 0.5 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
含義我就不寫了，你搜一下就會知道。在 mpstat（Multi-Processor Statistics）中看到的是 10 個計數器：
[root@7dgroup3 ~]# mpstat -P ALL 3
Linux 3.10.0-957.21.3.el7.x86_64 (7dgroup3) 12/27/2019 _x86_64_ (2 CPU)
03:46:25 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
03:46:28 PM all 0.17 0.00 0.17 0.00 0.00 0.00 0.00 0.00 0.00 99.66
03:46:28 PM 0 0.33 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.67
03:46:28 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
這里多出來%guest、%gnice兩個值。他們的含義在 Linux man page 中有詳細的說明。
%guest ：Show the percentage of time spent by the CPU or CPUs to run a virtual processor.
%gnice：Show the percentage of time spent by the CPU or CPUs to run a niced guest.
你可以看到計數器的名字稍有不同，像top中的wa在mpstat中是%iowait，si是 mpstat 中的%soft。
在 Linux 中，這就是我們經常查看的 CPU 計數器了。在我的性能生涯中，常見的問題大部分都是體現在這么幾個計數器上（排名有先后）：
- us
- wa
- sy
- si
首先，為了確定看到 CPU 高之后，接着往下分析的方向是絕對沒有錯的，建議你用Perf top -g先看一下 CPU 熱點。
perf默認用的是cpu-clock事件。這一步只是為了確定方向對不對。
那么如何從這幾個計數器找到后續的證據鏈呢？下面就是我們定向監控分析的過程了。
us CPU 是用戶態進程消耗的 CPU 百分比。大家都知道怎么往下落。這個鏈就是下面這樣的：
當然不是只有這幾個命令可以用，你可以找到大把的工具用，我只是列出來常用的。你要是想炫技，可以自己寫些腳本來做。這個過程幾乎被寫爛了，所以，我就不多余舉例子了。
wa cpu是 I/O 讀寫等待消耗的 CPU 百分比。這個證據鏈怎么往下落呢？來看一下。
你看中間有一步跳躍，這就是 wa CPU 直接跳到線程了。為什么沒有進程了呢？那是因為 iotop 有直接到線程的能力。如果你想先看進程也可以，記得執行 iotop -P。
sy CPU 是內核消耗的 CPU 百分比。這個問題就有點復雜了，因為它並沒有一個固定的套路。但是它的分析鏈路仍然和 us CPU 高的分析鏈路差不多，只是這個進程可能不是應用的，而是系統自己的。但是，是什么導致內核進程占用 CPU 高呢。這可能和應用有關，當然也可能和配置有關。那么現在我們畫一個它的分析鏈路。
其實在實際的分析過程中，也是這樣的。如果我們看到一個系統的進程消耗了更多的資源，那就要去查一下這個進程是干嗎的，看它的運行邏輯和配置文件。
不一定所有情況都是配置的問題，但絕大多數情況是這個原因，只能說，在系統級別，我們遇到的內核進程本身有性能問題的情況還是很少的。大部分時候都只是配置問題。
si CPU 是軟中斷消耗的 CPU 百分比。什么是軟中斷呢？
簡單點來說，當出現異常或資源爭用時，它是用來管理秩序的。CPU 正在吭哧吭哧着干活呢，突然來了一個優先級高的，needs immediate attention，這時就會發一個中斷信號給 CPU。
作為一個干活的，CPU 誰的話都得聽，這時候就把手頭的工作現場保存一下，干這個優先級高的活。除非這個中斷是致命的，不然 CPU 會在干完這個活之后再回去干之前的活，這就是一次軟中斷。
個值，越多就越有問題，關鍵是它有多少才是有問題呢？這一點你從來沒有看過有人給建議值對不對？因為它根本沒有可以參考的值，在不同的應用和硬件環境中，si CPU 都會有很大差別。我見過軟中斷每秒幾萬多就有問題的，也見過軟中斷每秒 20 萬都沒有問題的。
下面我來照例畫個分析的圖看一下。
在這個判斷的鏈路中，就是要把 si 的中斷模塊找出來，然后再分析這個模塊的功能和配置。比如我們看網卡的中斷，這是常見的一種性能問題。我們要知道網絡是帶寬不夠？還是配置得不對？還是防火牆？還是啥啥啥別的原因？
如果是其他的模塊也是一樣的邏輯。好，在知道了上面這幾個常見的 CPU 計數器的分析證據鏈邏輯之后，我就不再詳細畫其他的 CPU 的計數器了。
ni 呢，在我職業生涯中就沒見過它高過；hi 倒是見過，不過是因為硬件壞了；st 呢，只有無良商家不斷超賣虛擬服務器才會出現。如果你在一個企業內部搭建的虛擬化基礎平台上也經常看見這種情況，那就是公司太窮了，硬件都不夠用。
總結
在操作系統的分析過程中，CPU 絕對是一個重點分析的對象，它的一舉一動都牽動着性能分析的人，所以我們需要在 CPU 的高低上花很多的時間去分析判斷。
幸運的是，當 CPU 使用率高的時候，我們可以有很多的手段來找到對應的根本原因。這個過程不僅分析思路完整，而且工具繁多。它不像網絡那么繞，也不像內存那么復雜，邏輯上還是很清楚的。