61秒，摸透Linux的健康狀態！
- WBOY轉載
- 2024-02-14 10:45:021246瀏覽
作業系統作為所有程式的基礎，對應用程式的效能有著重要的影響。然而，計算機各個組件之間的速度差異非常大。例如，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显示了交换分区的一些使用情况，交换分区对性能的影响比较大，需要格外关注。
$ 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 34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0 32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0 32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0 32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0 32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0 ^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 -n DEV 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00 12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00 12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil 12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00 12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00 12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 ^C
当然，我们可以选择性的只看TCP的一些状态。
$ sar -n TCP,ETCP 1 Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU) 12:17:19 AM active/s passive/s iseg/s oseg/s 12:17:20 AM 1.00 0.00 10233.00 18846.00 12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:20 AM 0.00 0.00 0.00 0.00 0.00 12:17:20 AM active/s passive/s iseg/s oseg/s 12:17:21 AM 1.00 0.00 8359.00 6039.00 12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s 12:17:21 AM 0.00 0.00 0.00 0.00 0.00 ^C
5.End
不要寄希望于这些指标，能够立刻帮助我们定位性能问题。这些工具，只能够帮我们大体猜测发生问题的地方，它对性能问题的定位，只是起到辅助作用。想要分析这些bottleneck，需要收集更多的信息。
想要获取更多的性能数据，就不得不借助更加专业的工具，比如基于eBPF的BCC工具，这些牛x的工具我们将在其他文章里展开。读完本文，希望你能够快速的了解Linux的运行状态，对你的系统多一些掌控。
以上是61秒，摸透Linux的健康狀態！的詳細內容。更多資訊請關注PHP中文網其他相關文章！