定位伺服器數據丟棄包問題
當某個伺服器發生數據丟包時,它們肯定是由於某種原因。我們如何來分析為什麼數據包丟失。
以下是我們想要了解的情況:
一個數據包進入您計算機的網路堆棧( RX )(例如在埠 8000 上)。 在埠 8000 對應的應用程序接收之前被丟。
發送一個數據包( TX )。 在它從您的機器發出之前被丟。
本文不關注「數據包在網路傳輸過程丟了,讓我們用 traceroute / 通過計數 TCP 重傳進行診斷」(雖然這也很重要)!
怎麼知道數據包是否被丟棄?
我在 Twitter 上提問,得到了非常有用的答案 「看 netstat -i !」這是我的筆記本電腦上運行得到的結果:
bork@kiwi~> sudo netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg docker0 1500 0 0 0 0 0 0 0 0 0 BMU enp0s25 1500 0 1235101 0 242 0 745760 0 0 0 BMRU lo 65536 0 21558 0 0 0 21558 0 0 0 LRU nlmon0 3776 0 551262 0 0 0 0 0 0 0 ORU
看起來有一些收到的( RX )數據包在 enp0s25 (我的無線網卡)上丟失了。 但是沒有 TX 包丟失。
有人也告訴我,運行 ethtool -S 會有幫助,但是我的 ethtool 沒有 -S 選項。
怎麼知道為什麼數據包被丟棄
通過谷歌搜索,發現一個很酷的工具叫 dropwatch 。 沒有現成的 Ubuntu 安裝軟體包,但可以通過 github 下載:
https//github.com/pavel-odintsov/drop_watch
以下是我可以編譯的說明:
sudo apt-get install -y libnl-3-dev libnl-genl-3-dev binutils-dev libreadline6-dev git clone https://github.com/pavel-odintsov/drop_watch cd drop_watch/src vim Makefile # comment out the -Werror argument to gcc make
這裡是輸出! 它告訴我哪個內核函數丟失數據包,酷!
sudo ./dropwatch -l kas Initalizing kallsyms db dropwatch> start Enabling monitoring... Kernel monitoring activated. Issue Ctrl-C to stop monitoring 1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad) 10 drops at tcp_v4_rcv+80 (0xffffffff8179a620) 1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7) 4 drops at unix_release_sock+20e (0xffffffff817dc94e) 1 drops at igmp_rcv+e1 (0xffffffff817b4c41) 1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
用perf監控丟棄的數據包
還有另一個很酷的方法,用來調試發生什麼。
thomas graf 告訴我,可以使用 perf 監視 kfree_skb 事件,這將告訴你什麼時候丟棄數據包(內核堆棧發生的地方):
sudo perf record -g -a -e skb:kfree_skb sudo perf script
※Node也許不是構建大型服務的最佳選擇——Node之父Ryan Dahl訪談錄
※大規模Kafka集群的管理利器:LinkedIn最新開源的Cruise Control帶來了什麼?
※如何選擇使用開源軟體建立監控體系
※如何快速落地數據分析平台 大數據在他趣的應用實踐
※微服務的實踐:爆棚的CCF TF第一期技術分享都講了什麼(含PPT)
TAG:高可用架構 |