性能分析之系統資源飽和度

前言

CPU 資源

內存資源

磁盤資源

網絡資源

總結

前言

CPU 資源

內存資源

磁盤資源

網絡資源

總結

前言

在做性能分析的時候，我們不可避免地判斷資源到底夠不夠用？哪里不夠？為什么不夠？證據是什么？

能回復得了這些問題并不容易。

今天就來聊聊一下操作系統資源飽和度應該如何衡量？

現在 k8s 盛行，所以這里來借用 k8s 中部署的 Prometheus+Grafana 來直觀的看圖。

CPU 資源

先看一個圖：

一邊是 CPU 使用率，一邊是 CPU 飽和度。

飽和度如何來算的呢？

看它的 Query 是什么樣的：

node:node_cpu_saturation_load1:{cluster="$cluster"} / scalar(sum(min(kube_pod_info{cluster="$cluster"}) by (node)))

即是 node_cpu_saturation_load1 來計算的，那這個 node_cpu_saturation_load1 的基礎數據是什么？再來它的來源：

sum by (node) ( node_load1{job="node-exporter"} * on (namespace, pod) group_left(node) node_namespace_pod:kube_pod_info: ) / node:node_num_cpu:sum record: 'node:node_cpu_saturation_load1:'

load average 1min 內的數據，node_exporter 同時也實現了 node_load5/node_load15。分別來對應我們常見的 Linux 中的 load average 的 1 分鐘、5 分鐘、15 分鐘。

而這個 load average 從哪里來，在之前的文章中有過描述，同時也說了這個值用來判斷系統負載的局限性。這里就不展開了。

知道了這個 CPU 飽和度的來源之后，我們再來看上面的圖。即是說，我們在判斷 CPU 是否夠用的時候，不僅是要看 CPU 使用率，還要看 CPU 飽和度才可以。

內存資源

如下圖：

這里的內存飽和度后面加了一個 Swap IO。其實了解內存的人會知道，swap 這個詞實在是有特定的含義，交換分區，但是在我們在配置 k8s 的時候會知道 swap 是關了的。但是這里 swap 是什么呢？

再來看它的 Query 語句。

node:node_memory_swap_io_bytes:sum_rate{cluster="$cluster"}

取了 node_memory_swap_io_bytes 這個值，這個值在 prometheus 里是什么呢？

- expr: | 1e3 * sum( (rate(node_vmstat_pgpgin{job="node-exporter"}[1m]) + rate(node_vmstat_pgpgout{job="node-exporter"}[1m])) ) record: :node_memory_swap_io_bytes:sum_rate

取了 vmstat 的 page in/out。這就理解了，swap 并不是特指交換分區。而是頁交換，沒有交換分區不打緊，頁交換還是要做的。

而有頁交換并不一定就是內存用完了，指內存中找不到要使用的頁也是要有 page in 的。而在代碼中定義了某個變量或對象的內存大小之后，當不夠用時，也照樣會 page out。

所以判斷內存是否夠用，不僅要看內存是否用完，還要看 page in/out 是否產生。

磁盤資源

磁盤的 IO 飽和度是比較容易判斷的，我們來看看它是如何判斷，同樣來看看它的 Query：

node:node_disk_saturation:avg_irate{cluster="$cluster"} / scalar(:kube_pod_info_node_count:{cluster="$cluster"})

取了 node_disk_staturation，同時計算了 avg_irate。我們來看一下這個值的來源。

- expr: | avg by (node) ( irate(node_disk_io_time_weighted_seconds_total{job="node-exporter",device=~"nvme.+|rbd.+|sd.+|vd.+|xvd.+|dm-.+"}[1m]) * on (namespace, pod) group_left(node) node_namespace_pod:kube_pod_info: ) record: node:node_disk_saturation:avg_irate

它取了 node_disk_io_time_weighted_seconds_total 的值，這是一個加權累積值。而這個值是來源于 iostat 中的avgqu-sz，這個值是 IO 隊列長度。

這樣就知道這個飽和度的來源了

網絡資源

在網絡資源的判斷上，這里用了一個非常直接的詞 dropped。直觀理解就是丟包，來看它的 Query 語句。

node:node_net_saturation:sum_irate{cluster="$cluster"}

這里調用了 node_net_saturation 的值，而這個值不夠直觀的知道是什么內容。

再來看看它的來源：

- expr: | sum by (node) ( (irate(node_network_receive_drop_total{job="node-exporter",device!~"veth.+"}[1m]) + irate(node_network_transmit_drop_total{job="node-exporter",device!~"veth.+"}[1m])) * on (namespace, pod) group_left(node) node_namespace_pod:kube_pod_info: ) record: node:node_net_saturation:sum_irate

從這段代碼就很清楚地知道了，這是從接收的 drop 來的。好直觀的名字。

其實判斷網絡瓶頸，不止是丟不丟包，也要看隊列。如果已經出現丟包了的話，那網絡質量就必定差了。

總結

其實不管我們用什么工具來看性能數據，都是需要知道它的來源和值的含義，這樣才能判斷精確。

在很多場合，不管是項目還是做一些分享，我都強調過性能分析中要先理解每個數據的含義再來看所選擇的工具中如何展現。

而有些人覺得上一個監控平臺或 APM 之類的就可以知道瓶頸點在哪里了，這個理念絕對是有問題的。

打好基礎，仍然是學習的重點。

Linux 云性能測試服務 CPTS 網絡

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。