實踐案例丨GaussDB網絡重傳/丟包問題定位總結

摘要：本文將介紹幾種經常使用手段，用於梳理數據庫網絡故障可能存在的問題，從而快速定位恢復。

1 問題背景

在GaussDB各種問題場景中，網絡故障是最難定位及恢復的問題之一，其不只可能影響着數據庫的性能，甚至在必定程度上會阻塞業務的正常運行，形成嚴重後果。網絡問題牽連着應用側（即GaussDB）、操做系統、交換機以及硬件資源等，本文將介紹幾種經常使用手段，用於梳理其間可能存在的問題，從而快速定位恢復。文中涉及的參數、視圖詳情可參考產品文檔。

2 問題現象

圖1. gsar腳本運行結果

對於性能慢、數據庫鏈接異常等狀況，建議使用gsar腳本檢查網絡狀態，若重傳率或丟包率超過0.01%，如圖1最後一列紅色框，則說明網絡存在問題，需進一步分析定位。

3 排查一：TaiShan服務器網卡加固

對於TaiShan服務器(100/200)，均須要使用兼容的網卡及驅動，不然頗有可能產生此類網絡問題。

須嚴格按照加固配置指南進行定位，包括透明大頁等均需覈查。

4 排查二：MTU一致性

MTU即最大傳輸單元，整條數據鏈路要保證MTU的一致性，不然可能因爲數據包大小不匹配致使丟包。使用ifconfig命令便可查看和修改各個網卡的MTU值：

圖2. ifconfig修改MTU

如圖2，其缺點是重啓後失效，想長久保留還需修改配置文件，不一樣操做系統修改方法不一樣，可谷歌查找。

5 排查三：網絡重傳狀況

1. netstat查看重傳次數

使用gsar腳本觀察到明顯的重傳現象後，可根據netstat命令具體查看重傳狀態：

圖3. netstat查看重傳狀態

若重傳次數達到12次（圖3紅色框中，第一列表示距離下一次重傳的時間，第二列爲已經發生重傳的次數，理論上重傳達到9分鐘，keepalive就會檢測到鏈接異常，將其斷開），則說明此時網絡不通，可進一步排查對端進程狀態以及網絡環境（ping）。

2. netstat查看緩存區狀態

當發送緩存區嚴重阻塞時，可明顯看到重傳現象，仍然使用netstat命令查看緩存區狀況：

圖4. netstat查看發送緩存區狀態

圖4紅色框爲發送端緩存區狀態，能夠看到阻塞較爲嚴重且接收端均爲192.168.2.101，此時能夠根據端口號查看對端接收狀況：

圖5. netstat查看對端接收緩存區狀態

圖5紅色框爲44112端口的接收端緩存區，阻塞現象一樣明顯。此時，能夠根據GaussDB相關視圖獲取各線程狀態，進而分析阻塞緣由，以一條阻塞的鏈接爲例：

圖6. DN上根據client_port查到query_id

根據GaussDB節點端口登陸數據庫，利用對端鏈接端口號查找到query_id；

圖7. CN上根據query_id查到各線程狀態

登陸GaussDB的CN節點，根據query_id找到CN線程id，此時DN均在向CN傳輸數據，可使用gstack打印此時CN的堆棧等。

1） 打印線程堆棧：gstack lwtid

2） 監控線程與內核交互：strace -p lwtid -tt -T -o strace.log

3） 查看線程使用的CPU資源：top -p pid -d 0.2

3. 已知語句gather慢

個別語句執行慢，打印執行計劃發現主要耗時在gather上，此時可根據要執行的sql語句找到對應CN和DN的狀態，找到慢因所在節點及線程id，再打印堆棧信息等進一步分析。

圖8. 根據sql查到CN線程狀態

6 排查四：網絡丟包狀況

1. 內存不足

內存不足是引起丟包的一大緣由，可是通常會出現其餘的直觀表現，可以使用free、top等命令查看內存狀況，也可以使用pv_total_memory_detail視圖觀察具體的進程情況。

2. CPU軟中斷不足

網卡接收到數據後，數據進入到TCP緩存區的過程須要進行CPU中斷處理，若此時相關CPU繁忙、軟中斷使用較高，CPU處理網卡的數據不及時，形成丟包。

圖9. speed_test壓測接收端

圖10. speed_test壓測發送端

圖11. speed_test壓測時網絡情況

圖12. speed_test壓測時CPU軟中斷情況

使用speed_test工具壓測觀察，兩臺機器分別做爲接收和發送端，如圖9~12，此時測試集羣無背景壓力，能夠看到網絡流量達到網卡上限，偶發出現丟包現象，查看對應的CPU軟中斷，一直處在高於70的水平。

此外，軟中斷也與IO相關，可以使用iostat命令查看對應時刻的IO狀態。對一些場景，網卡與業務分開綁核能夠有必定的緩解，使用get_irq_affinity2.sh腳本查看當前網卡綁核狀況：

圖13. 查看網卡綁核狀況

使用smart_irq_affi.sh對網卡進行綁核：

圖14. 對網卡進行綁核

使用gs_cgroup對GaussDB進行綁核：

圖15. 對GaussDB進行綁核

7 排查五：交換機

做爲整個數據傳輸鏈路的重要一環，針對交換機的拓撲結構、流控、接口帶寬等，需聯繫相關專家進行逐一排查。

8 經常使用命令

1. 網絡壓測工具：speed_test/iperf

    ./speed_test_xxx recv/send ip port
    iperf -s / iperf -c ip -t time -p thread_num

2. 網卡工具：ethtool

    ethtool ethx      // speed
    ethtool -i ethx    // driver
    ethtool -k ethx    // gro gso tso
    ethtool -l ethx    // channel
    ethtool -S ethx    // 統計信息

3. 抓包工具：tcpdump

    tcpdump tcp -i ethx and host ip1 and ip2 and port port1 -w target.pcap

9 總結

因爲數據傳輸鏈路的複雜性，重傳丟包問題定位較爲困難，但學會掌握必定的手段方法，理清思路，從源頭開始排查，終究會找到根因。

附件下載：

 GaussDB A 加固配置指南 04.pdf 2.11MB 

 腳本工具.rar 3.55KB 

本文分享自華爲雲社區《GaussDB網絡重傳/丟包問題定位總結》，原文做者：Caesar.D。

 

點擊關注，第一時間瞭解華爲雲新鮮技術~