網易老司機：網絡性能問題該怎樣監控與定位？

時間 2019-11-25

原文原文鏈接

轉載：https://blog.csdn.net/wangyiyice/article/details/53502682html

在性能測試中，特別是測試雲計算相關產品時，網絡是影響性能的關鍵的因素之一，此文主要介紹網絡性能如何監控以及常見網絡性能問題如何定位。linux

常見網絡模型和架構ios

首先介紹一下網絡交互的過程當中，數據包是怎麼走的。從發送到被接收，通過的路徑大體以下圖1所示：git

圖1 網絡交互中的數據包路徑github

以一次網絡交互爲例，一個數據包自發送端從上往下經由用戶態空間的應用、系統內核空間到達網卡驅動，而後經過數據鏈路傳輸到達接收端，再從下往上通過網卡驅動、系統內核空間最終到達用戶態空間的應用中等待被處理。在整個過程當中，涉及到多個隊列，一系列的參數設定，其中任一部分的波動均可能致使終端表現出網絡性能的抖動。後端

網絡性能監控
服務器

網絡性能監控是網絡性能測試的重要部分，也是定位網絡性能問題的重要手段。監控結果能相對直觀地顯示出網絡系統的運行狀態，幫助咱們分析和解決性能問題。在網絡性能監控中，最經常使用的監控方式有兩類：網卡性能監控和協議棧監控。網絡

1 網卡性能監控架構

網卡性能監控是網絡性能測試中最重要的監控方式之一，網卡承載了全部的網絡流量，不少關鍵性能參數都能從網卡性能監控中得到。網卡性能監控工具備不少，其中以sar較爲經常使用。tcp

1.1 網卡性能監控工具 - sar

sar 全稱爲System Activity Report，是Unix/Linux 下流行的系統資源監控命令，Linux 下若是沒有該命令，須要安裝 sysstat 包。

sar -n 能夠根據關鍵字以不一樣的角度報告實時的網絡流量變化，其中DEV和ETCP關鍵字最爲經常使用。

DEV關鍵字以設備爲單位提供網絡統計報告，方便快速觀察各網卡性能：

IFACE：設備名；
rxpck/s：每秒鐘接收的數據包；
txpck/s：每秒鐘發送的數據包；
rxbyt/s：每秒鐘接收的字節數；
txbyt/s：每秒鐘發送的字節數；
rxcmp/s：每秒鐘接收的壓縮數據包；
txcmp/s：每秒鐘發送的壓縮數據包；
rxmcst/s：每秒鐘接收的多播數據包。

ETCP關鍵字報告TCP層的錯誤統計，包括重試、斷連、重傳、錯誤、RST包等：

atmptf/s：每秒重試失敗數；
estres/s：每秒斷開鏈接數；
retrans/s：每秒重傳數；
isegerr/s：每秒錯誤數；
orsts/s：每秒RST數。

一般狀況下能夠將DEV和ETCP結合使用，如：sar -n DEV -n ETCP ，快速觀察網絡性能情況，結果如圖2：

圖2 DEV和ETCP結合使用

1.2 其餘網卡性能監控工具

除了sar外，還有不少網卡性能監控工具，諸如：

Ifconfig：查看網卡基本信息和統計數據；
Ethtool：檢查/設置網卡的配置；
Perf：Linux性能分析工具，能夠用來分析網卡的性能。

具體詳見附錄中的參考連接。

2協議棧監控

除了網卡以外，協議棧狀態也是影響網絡性能的關鍵因素之一，網絡性能出現異常時，每每能從協議棧狀態中看出端倪。在Linux系統中，Netstat是最經常使用的協議棧監控命令。

2.1 協議棧監控工具 – Netstat

Netstat是一個監控TCP/IP網絡的很是有用的工具，它能夠顯示路由表、實際的網絡鏈接以及每個網絡接口設備的狀態信息。Netstat用於顯示與IP、TCP、UDP和ICMP協議相關的統計數據，通常用於檢驗本機各端口的網絡鏈接狀況。

在性能測試過程當中，Netstat的經常使用用途有如下3種：

◆ 查看丟包

咱們常說的丟包有三種：

一種是內核可以記錄的，也就是協議棧上的丟包；
另外一種是網卡可以記錄的，就是網卡處理不過來丟包；
第三種就是傳輸過程當中被丟棄的，也就是離開本機以後，未能到達目標主機的。

無論哪一種丟包，根據TCP協議的重傳規則，咱們均可以經過重傳來估算系統的丟包狀況：

圖3 經過重傳來估算系統的丟包狀況

因爲Netstat中部分命令展現的是系統開機以來的累計值，直接查看可能結果不夠直觀，所以能夠配合watch 來使用。在watch命令中使用-d參數讓出現變化的指標高亮。固然也能夠用上文中提到的sar 來看重傳： sar -n ETCP 1，其中的retrans/s就是每秒重傳數。

◆ 查看全鏈接隊列配置狀況

全鏈接隊列的大小也是影響性能的關鍵因素，而 Linux 默認的大小才128，有時候忘了更改這個參數就會致使性能問題。針對全鏈接大小是否合理這個問題，能夠查看netstat統計指標中相關事件的發生頻率：

netstat -st |grep SYN

圖4 查看netstat統計指標

當這兩行出現比較大的頻率增加時，說明服務器的全鏈接隊列太小。

◆ 查看接收buffer配置狀況

接收緩衝區大小也是影響性能的關鍵因素之一，主要是受net.ipv4.tcp_rmem相關參數的影響，以及系統調用 SO_RVCBUF 參數的影響，一般咱們能夠經過查找 netstat -s 中 overrun、 collapse、pruned 等事件來觀察，若是相關的統計項一直都在增加，那麼說明應用的接收緩衝區須要調整了，以下圖5：

圖5 查看接收buffer配置狀況

2.2 其餘協議棧監控工具

除了Netstat外，還有不少協議棧監控工具，諸如：

Dropwatch：檢測網絡協議棧丟包；
Sysdig：網絡資源監控；
Systemtap：網絡性能監控和調試。

具體詳見附錄中的參考連接。

常見問題定位

在平常的網絡性能測試中常常遇到各式各樣的問題，接下來看兩個典型的例子，從問題表象、分析緣由到解決問題，從而更好地理解上文提到的網絡性能監控手段在網絡性能測試中的做用。

問題1 網絡丟包重傳

丟包重傳是一種較爲典型的網絡性能問題現象，tcp層丟包後系統會在200毫秒後自動重傳，雖然丟包並不會影響結果的正確性，可是200毫秒的延遲在有些時候會嚴重影響性能表現。

1.1 問題表象

在一次測試LVS上傳文件性能的過程當中，發現整個系統負載很是低，可是TPS上不去。理論TPS應該在40000左右，可是實際TPS只有400左右。

1.2 分析過程

在測試機和服務器上使用sar命令配合-n DEV -n ETCP參數，測試機上顯示有大量重傳（retrans/s）：

圖6 使用sar命令查看重傳

使用ethtool命令查看LVS的網卡配置，發現 LVS網卡的GRO（generic-receive-offload）/LRO（large-receive-offlod）配置項處於開啓狀態：

圖7 使用ethtool命令查看網卡配置

LVS開啓GRO/LRO時會在轉發數據包的過程當中自動組包至MTU大小。因爲LVS採用IP-Tunl轉發方式，在發日後端時會在數據包上再加上一個ip頭，所以後端接收到的數據包將會大於MTU，會被網卡丟棄掉從而致使重傳。

1.3 解決方法

綜上，解決方法有二，選一便可：

關閉LVS網卡的GRO/LRO功能，不自動組包。（關於GRO/LRO的相關介紹，能夠看附錄中的參考資料）；
將LVS轉發方式改成DR（Direct-Route）模式，DR模式相比IP-Tunl的不一樣在於發日後端時會替換數據包的IP頭而不是新增IP頭，所以數據包大小不會變大，也就不會超過MTU了。（關於LVS轉發方式相關介紹，能夠看附錄中的參考資料）。

解決問題後，性能恢復正常，每秒重傳數降爲0。

圖8 每秒重傳數降爲0

問題2TIME_WAIT與keep-alive

TIME_WAIT數（關於TIME_WAIT的相關介紹，能夠看附錄中的參考資料）在網絡性能問題中也是一個值得關注的重點。下面介紹一個使用Netstat定位TIME_WAIT的性能問題。

2.1 問題表象

在一次對某個http接口進行性能壓測的過程當中，測試進行一段時間以後，開始陸續出現錯誤，性能波動如圖9：

圖9 性能波動

2.2 分析過程

首先查看客戶端錯誤信息，顯示錯誤類型是經典的502 Cannot assign requested address：

圖10 客戶端鏈接異常

從新進行測試，在測試過程當中使用netstat配合awk實時查看協議棧狀況，發現測試開始後TIME_WAIT數快速增加，直至28000左右，於此同時，client端開始報502錯誤：

圖11 TIME_WAIT數暴增