操作系統作為所有程序的載體，對應用的性能影響是非常重要的。然而計算機各個組件之間的速度，是非常不均衡的。拿CPU和硬盤的速度來說，比兔子和烏龜的速度差別還要大。

下面將簡單的介紹CPU、內存、I/O的一些基本知識，以及一些如何評估它們性能的命令。

1.CPU

首先介紹計算機中最重要的計算組件：中央處理器。一般我們可以通過top命令來觀測它的性能。

1.1 top命令

top命令可用于觀測CPU的一些運行指標。如圖，進入top命令之后，按1鍵即可看到每核CPU的詳細狀況。

CPU的使用有多個維度的指標，以下分別說明一下：

us用戶態所占用的CPU百分比。

sy內核態所占用的CPU百分比。如果這個值過高，需要配合vmstat命令，查看是否是上下文切換是否頻繁。

ni高優先級應用所占用的CPU百分比。

wa等待I/O設備所占用的CPU百分比。如果這個值非常高，輸入輸出設備可能存在非常明顯的瓶頸。

hi硬件中斷所占用的CPU百分比。

si軟中斷所占用的CPU百分比。

st這個一般發生在虛擬機上，指的是虛擬CPU等待實際CPU時間的百分比。如果這個值過大，則你的宿主機壓力可能過大。如果你是云主機，則你的服務商可能存在超賣。

id空閑CPU百分比。

一般的，我們比較關注空閑CPU的百分比，它可以從整體上體現CPU的利用情況。

1.2 什么是負載

我們還要評估CPU任務執行的排隊情況，這些值就是負載(load)。top命令，顯示的CPU負載，分別是最近1分鐘、5分鐘、15分鐘的數值。

如圖，以單核操作系統為例，將CPU資源抽象成一條單向行駛的馬路。則會發生三種情況：

馬路上的車只有4輛，車輛暢通無阻，load大約是0.5。

馬路上的車有8輛，正好能首尾相接安全通過，此時load大約為1。

馬路上的車有12輛，除了在馬路上的8輛車，還有4輛等在馬路外面，需要排隊。此時load大約為1.5。

那load為1代表的是啥？針對這個問題，誤解還是比較多的。

很多同學認為，load達到1，系統就到了瓶頸，這不完全正確。load的值和cpu核數息息相關。舉例如下：

單核的負載達到1，總load的值約1。

雙核的每核負載都達到1，總load約2。

四核的每核負載都達到1，總load約為4。

所以，對于一個load到了10，卻是16核的機器，你的系統還遠沒有達到負載極限。通過uptime命令，同樣能夠看到負載情況。

1.3 vmstat

要看CPU的繁忙程度，還可以通過vmstat命令。下面是vmstat命令的一些輸出信息。

我們比較關注的有下面幾列：

b存在于等待隊列的內核線程數目，比如等待I/O等。數字過大則cpu太忙。

cs代表上下文切換的數量。如果頻繁的進行上下文切換，就需要考慮是否是線程數開的過多。

si/so顯示了交換分區的一些使用情況，交換分區對性能的影響比較大，需要格外關注。

$vmstat1
procs---------memory-------------swap-------io-----system--------cpu-----
rbswpdfreebuffcachesisobiboincsussyidwast
3400200889792737085918280005610961300
320020088992073708591860000592132844282981100
320020089011273708591860000095012154991000
32002008895687371259185600048119002459990000
3200200890208737125918600000158984840981100
^C

2.內存

2.1 觀測命令

要想了解內存對性能的一些影響，就需要從操作系統層面來看一下內存的分布。

我們在平常寫完代碼后，比如寫了一個C++程序，如果去查看它的匯編，可以看到其中的內存地址，并不是實際的物理內存地址。

那么應用程序所使用的，就是邏輯內存，這個學過計算機組成結構的同學都有了解。

邏輯地址可以映射到物理內存和虛擬內存上。比如你的物理內存是8GB，分配了16GB的SWAP分區，那么應用可用的總內存就是24GB。

從top命令可以看到幾列數據，注意方塊括起來的三個區域，解釋如下：

VIRT這里就是虛擬內存，一般比較大，不用做過多關注。

RES我們平常關注的就是這一列的數值，它代表了進程實際占用的內存。平常在做監控時，也主要是監控這個數值。

SHR指的是共享內存，比如可以復用的一些so文件等。

2.2 CPU緩存

由于CPU核內存之間的速度差異是非常大的，解決方式就是加入高速緩存。其實，這些高速緩存，往往會有多層，如下圖。

Java有大部分知識點是圍繞多線程的，那是因為，如果一個線程的時間片跨越了多個CPU，那么就會存在同步問題。

在Java中，最典型的和CPU緩存相關的知識點，就是并發編程中，針對Cache line的偽共享（false sharing）問題。

偽共享是指：在這些高速緩存中，是以緩存行為單位進行存儲的。哪怕你修改了緩存行中一個很小很小的數據，它都會整個的刷新。所以，當多線程修改一些變量的值時，如果這些變量在同一個緩存行里，就會造成頻繁刷新，無意中影響彼此的性能。

通過以下命令即可看到當前操作系統的緩存行大小。

cat/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size

通過以下命令可以看到不同層次的緩存大小。

[root@localhost~]#cat/sys/devices/system/cpu/cpu0/cache/index1/size
32K
[root@localhost~]#cat/sys/devices/system/cpu/cpu0/cache/index2/size
256K
[root@localhost~]#cat/sys/devices/system/cpu/cpu0/cache/index3/size
20480K

在JDK8以上的版本，通過開啟參數-XX:-RestrictContended，就可以使用注解@sun.misc.Contended進行補齊，來避免偽共享的問題。在并發優化中，我們再詳細講解。

2.3 HugePage

回頭看我們最長的那副圖，上面有一個叫做TLB的組件，它的速度雖然高，但容量也是有限的。這就意味著，如果物理內存很大，那么映射表的條目將會非常多，會影響CPU的檢索效率。

默認內存是以4K的page來管理的。如圖，為了減少映射表的條目，可采取的辦法只有增加頁的尺寸。像這種將Page Size加大的技術，就是Huge Page。

HugePage有一些副作用，比如競爭加劇，Redis還有專門的研究（https://redis.io/topics/latency） ，但在一些大內存的機器上，開啟后會一定程度上增加性能。

2.4 預先加載

另外，一些程序的默認行為，也會對性能有所影響。比如JVM的-XX:+AlwaysPreTouch參數。默認情況下，JVM雖然配置了Xmx、Xms等參數，但它的內存在真正用到時，才會分配。

但如果加上這個參數，JVM就會在啟動的時候，把所有的內存預先分配。這樣，啟動時雖然慢了些，但運行時的性能會增加。

3.I/O

3.1 觀測命令

I/O設備可能是計算機里速度最差的組件了。它指的不僅僅是硬盤，還包括外圍的所有設備。

硬盤有多慢呢？我們不去探究不同設備的實現細節，直接看它的寫入速度（數據未經過嚴格測試，僅作參考）。

可以看到普通磁盤的隨機寫和順序寫相差是非常大的。而隨機寫完全和cpu內存不在一個數量級。

緩沖區依然是解決速度差異的唯一工具，在極端情況比如斷電等，就產生了太多的不確定性。這些緩沖區，都容易丟。

最能體現I/O繁忙程度的，就是top命令和vmstat命令中的wa%。如果你的應用，寫了大量的日志，I/O wait就可能非常的高。

對于硬盤來說，可以使用iostat命令來查看具體的硬件使用情況。只要%util超過了80%，你的系統基本上就跑不動了。

詳細介紹如下：

%util最重要的判斷參數。一般地，如果該參數是100%表示設備已經接近滿負荷運行了

Device表示發生在哪塊硬盤。如果你有多快，則會顯示多行

avgqu-sz這個值是請求隊列的飽和度，也就是平均請求隊列的長度。毫無疑問，隊列長度越短越好。

await響應時間應該低于5ms，如果大于10ms就比較大了。這個時間包括了隊列時間和服務時間

svctm 表示平均每次設備I/O操作的服務時間。如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，如果await的值遠高于svctm的值，則表示I/O隊列等待太長，系統上運行的應用程序將變慢。

3.2 零拷貝

kafka比較快的一個原因就是使用了zero copy。所謂的Zero copy，就是在操作數據時, 不需要將數據buffer從一個內存區域拷貝到另一個內存區域。因為少了一次內存的拷貝, CPU的效率就得到提升。

我們來看一下它們之間的區別：

要想將一個文件的內容通過socket發送出去，傳統的方式需要經過以下步驟：

將文件內容拷貝到內核空間。

將內核空間的內容拷貝到用戶空間內存，比如Java應用。

用戶空間將內容寫入到內核空間的緩存中。

socket讀取內核緩存中的內容，發送出去。

零拷貝又多種模式，我們拿sendfile來說明。如上圖，在內核的支持下，零拷貝少了一個步驟，那就是內核緩存向用戶空間的拷貝。即節省了內存，也節省了CPU的調度時間，效率很高。

4.網絡

除了iotop、iostat這些命令外，sar命令可以方便的看到網絡運行狀況，下面是一個簡單的示例，用于描述入網流量和出網流量。

$sar-nDEV1
Linux3.13.0-49-generic(titanclusters-xxxxx)07/14/2015_x86_64_(32CPU)

1248AMIFACErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s%ifutil
1249AMeth018763.005032.0020686.42478.300.000.000.000.00
1249AMlo14.0014.001.361.360.000.000.000.00
1249AMdocker00.000.000.000.000.000.000.000.00

1249AMIFACErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s%ifutil
1250AMeth019763.005101.0021999.10482.560.000.000.000.00
1250AMlo20.0020.003.253.250.000.000.000.00
1250AMdocker00.000.000.000.000.000.000.000.00
^C

當然，我們可以選擇性的只看TCP的一些狀態。

$sar-nTCP,ETCP1
Linux3.13.0-49-generic(titanclusters-xxxxx)07/14/2015_x86_64_(32CPU)

1219AMactive/spassive/siseg/soseg/s
1220AM1.000.0010233.0018846.00

1219AMatmptf/sestres/sretrans/sisegerr/sorsts/s
1220AM0.000.000.000.000.00

1220AMactive/spassive/siseg/soseg/s
1221AM1.000.008359.006039.00

1220AMatmptf/sestres/sretrans/sisegerr/sorsts/s
1221AM0.000.000.000.000.00
^C

5.End

不要寄希望于這些指標，能夠立刻幫助我們定位性能問題。這些工具，只能夠幫我們大體猜測發生問題的地方，它對性能問題的定位，只是起到輔助作用。想要分析這些bottleneck，需要收集更多的信息。

想要獲取更多的性能數據，就不得不借助更加專業的工具，比如基于eBPF的BCC工具，這些牛x的工具我們將在其他文章里展開。讀完本文，希望你能夠快速的了解Linux的運行狀態，對你的系統多一些掌控。

審核編輯：劉清