之前記錄過處理因?yàn)?LVS 網(wǎng)卡流量負(fù)載過高導(dǎo)致軟中斷發(fā)生丟包的問題,RPS 和 RFS 網(wǎng)卡多隊(duì)列性能調(diào)優(yōu)實(shí)踐[1],對(duì)一般人來說壓力不大的情況下其實(shí)碰見的概率并不高。這次想分享的話題是比較常見服務(wù)器網(wǎng)卡丟包現(xiàn)象排查思路,如果你是想了解點(diǎn)對(duì)點(diǎn)的丟包解決思路涉及面可能就比較廣,不妨先參考之前的文章如何使用 MTR 診斷網(wǎng)絡(luò)問題[2],對(duì)于 Linux 常用的網(wǎng)卡丟包分析工具自然是 ethtool。
ethtool 用于查看和修改網(wǎng)絡(luò)設(shè)備(尤其是有線以太網(wǎng)設(shè)備)的驅(qū)動(dòng)參數(shù)和硬件設(shè)置。你可以根據(jù)需要更改以太網(wǎng)卡的參數(shù),包括自動(dòng)協(xié)商、速度、雙工和局域網(wǎng)喚醒等參數(shù)。通過對(duì)以太網(wǎng)卡的配置,你的計(jì)算機(jī)可以通過網(wǎng)絡(luò)有效地進(jìn)行通信。該工具提供了許多關(guān)于接駁到你的 Linux 系統(tǒng)的以太網(wǎng)設(shè)備的信息。
1. 了解接收數(shù)據(jù)包的流程
接收數(shù)據(jù)包是一個(gè)復(fù)雜的過程,涉及很多底層的技術(shù)細(xì)節(jié),但大致需要以下幾個(gè)步驟:
- 網(wǎng)卡收到數(shù)據(jù)包。將數(shù)據(jù)包從網(wǎng)卡硬件緩存轉(zhuǎn)移到服務(wù)器內(nèi)存中。通知內(nèi)核處理。經(jīng)過 TCP/IP 協(xié)議逐層處理。應(yīng)用程序通過 read() 從 socket buffer 讀取數(shù)據(jù)。
將網(wǎng)卡收到的數(shù)據(jù)包轉(zhuǎn)移到主機(jī)內(nèi)存(NIC 與驅(qū)動(dòng)交互)
NIC 在接收到數(shù)據(jù)包之后,首先需要將數(shù)據(jù)同步到內(nèi)核中,這中間的橋梁是 rx ring buffer。它是由 NIC 和驅(qū)動(dòng)程序共享的一片區(qū)域,事實(shí)上,rx ring buffer 存儲(chǔ)的并不是實(shí)際的 packet 數(shù)據(jù),而是一個(gè)描述符,這個(gè)描述符指向了它真正的存儲(chǔ)地址,具體流程如下:
- 驅(qū)動(dòng)在內(nèi)存中分配一片緩沖區(qū)用來接收數(shù)據(jù)包,叫做 sk_buffer;將上述緩沖區(qū)的地址和大小(即接收描述符),加入到 rx ring buffer。描述符中的緩沖區(qū)地址是 DMA 使用的物理地址;驅(qū)動(dòng)通知網(wǎng)卡有一個(gè)新的描述符;網(wǎng)卡從 rx ring buffer 中取出描述符,從而獲知緩沖區(qū)的地址和大?。痪W(wǎng)卡收到新的數(shù)據(jù)包;網(wǎng)卡將新數(shù)據(jù)包通過 DMA 直接寫到 sk_buffer 中。
當(dāng)驅(qū)動(dòng)處理速度跟不上網(wǎng)卡收包速度時(shí),驅(qū)動(dòng)來不及分配緩沖區(qū),NIC 接收到的數(shù)據(jù)包無法及時(shí)寫到 sk_buffer,就會(huì)產(chǎn)生堆積,當(dāng) NIC 內(nèi)部緩沖區(qū)寫滿后,就會(huì)丟棄部分?jǐn)?shù)據(jù),引起丟包。這部分丟包為 rx_fifo_errors,在 /proc/net/dev 中體現(xiàn)為 fifo 字段增長,在 ifconfig 中體現(xiàn)為 overruns 指標(biāo)增長。
通知系統(tǒng)內(nèi)核處理(驅(qū)動(dòng)與 Linux 內(nèi)核交互)
這個(gè)時(shí)候,數(shù)據(jù)包已經(jīng)被轉(zhuǎn)移到了 sk_buffer 中。前文提到,這是驅(qū)動(dòng)程序在內(nèi)存中分配的一片緩沖區(qū),并且是通過 DMA 寫入的,這種方式不依賴 CPU 直接將數(shù)據(jù)寫到了內(nèi)存中,意味著對(duì)內(nèi)核來說,其實(shí)并不知道已經(jīng)有新數(shù)據(jù)到了內(nèi)存中。那么如何讓內(nèi)核知道有新數(shù)據(jù)進(jìn)來了呢?答案就是中斷,通過中斷告訴內(nèi)核有新數(shù)據(jù)進(jìn)來了,并需要進(jìn)行后續(xù)處理。
提到中斷,就涉及到硬中斷和軟中斷,首先需要簡單了解一下它們的區(qū)別:
- 硬中斷:由硬件自己生成,具有隨機(jī)性,硬中斷被 CPU 接收后,觸發(fā)執(zhí)行中斷處理程序。中斷處理程序只會(huì)處理關(guān)鍵性的、短時(shí)間內(nèi)可以處理完的工作,剩余耗時(shí)較長工作,會(huì)放到中斷之后,由軟中斷來完成。硬中斷也被稱為上半部分。軟中斷:由硬中斷對(duì)應(yīng)的中斷處理程序生成,往往是預(yù)先在代碼里實(shí)現(xiàn)好的,不具有隨機(jī)性。(除此之外,也有應(yīng)用程序觸發(fā)的軟中斷,與本文討論的網(wǎng)卡收包無關(guān)。)也被稱為下半部分。
當(dāng) NIC 把數(shù)據(jù)包通過 DMA 復(fù)制到內(nèi)核緩沖區(qū) sk_buffer 后,NIC 立即發(fā)起一個(gè)硬件中斷。CPU 接收后,首先進(jìn)入上半部分,網(wǎng)卡中斷對(duì)應(yīng)的中斷處理程序是網(wǎng)卡驅(qū)動(dòng)程序的一部分,之后由它發(fā)起軟中斷,進(jìn)入下半部分,開始消費(fèi) sk_buffer 中的數(shù)據(jù),交給內(nèi)核協(xié)議棧處理。
通過中斷,能夠快速及時(shí)地響應(yīng)網(wǎng)卡數(shù)據(jù)請(qǐng)求,但如果數(shù)據(jù)量大,那么會(huì)產(chǎn)生大量中斷請(qǐng)求,CPU 大部分時(shí)間都忙于處理中斷,效率很低。為了解決這個(gè)問題,現(xiàn)在的內(nèi)核及驅(qū)動(dòng)都采用一種叫 NAPI(new API)的方式進(jìn)行數(shù)據(jù)處理,其原理可以簡單理解為 中斷 + 輪詢,在數(shù)據(jù)量大時(shí),一次中斷后通過輪詢接收一定數(shù)量包再返回,避免產(chǎn)生多次中斷。
2. ifconfig 解釋
[root@localhost?~]
eth0:?flags=4163<UP,BROADCAST,RUNNING,MULTICAST>?mtu?1500
inet?192.168.1.135?netmask?255.255.255.0?broadcast?192.168.1.255
inet6?fe80::20c:29ff:fe9b:52d3?prefixlen?64?scopeid?0x20<link>
ether?00:0c:29:9b:52:d3?txqueuelen?1000?(Ethernet)
RX?packets?833?bytes?61846?(60.3?KiB)
RX?errors?0?dropped?0?overruns?0?frame?0
TX?packets?122?bytes?9028?(8.8?KiB)
TX?errors?0?dropped?0?overruns?0?carrier?0?collisions?0
- RX errors
表示總的收包的錯(cuò)誤數(shù)量,這包括 too-long-frames 錯(cuò)誤,Ring Buffer 溢出錯(cuò)誤,crc 校驗(yàn)錯(cuò)誤,幀同步錯(cuò)誤,fifo overruns 以及 missed pkg 等等。
- RX dropped
表示數(shù)據(jù)包已經(jīng)進(jìn)入了 Ring Buffer,但是由于內(nèi)存不夠等系統(tǒng)原因,導(dǎo)致在拷貝到內(nèi)存的過程中被丟棄。
- RX overruns
表示了 fifo 的 overruns,這是由于 Ring Buffer(aka Driver Queue) 傳輸?shù)?IO 大于 kernel 能夠處理的 IO 導(dǎo)致的,而 Ring Buffer 則是指在發(fā)起 IRQ 請(qǐng)求之前的那塊 buffer。很明顯,overruns 的增大意味著數(shù)據(jù)包沒到 Ring Buffer 就被網(wǎng)卡物理層給丟棄了,而 CPU 無法即使的處理中斷是造成 Ring Buffer 滿的原因之一,上面那臺(tái)有問題的機(jī)器就是因?yàn)?interruprs 分布的不均勻 (都?jí)涸?core0),沒有做 affinity 而造成的丟包。
- RX frame
表示 misaligned 的 frames。
3. 網(wǎng)卡工作原理
網(wǎng)卡發(fā)包
網(wǎng)卡驅(qū)動(dòng)程序?qū)?IP 包添加 14 字節(jié)的 MAC 頭,構(gòu)成 frame(暫無 CRC)。Frame(暫無 CRC)中含有發(fā)送端和接收端的 MAC 地址,由于是驅(qū)動(dòng)程序創(chuàng)建 MAC 頭,所以可以隨便輸入地址,也可以進(jìn)行主機(jī)偽裝。
驅(qū)動(dòng)程序?qū)?frame(暫無 CRC)拷貝到網(wǎng)卡芯片內(nèi)部的緩沖區(qū),由網(wǎng)卡處理。
網(wǎng)卡芯片將未完全完成的 frame(缺 CRC)再次封裝為可以發(fā)送的 packet,也就是添加頭部同步信息和 CRC 校驗(yàn),然后丟到網(wǎng)線上,就完成一個(gè) IP 報(bào)的發(fā)送了,所有接到網(wǎng)線上的網(wǎng)卡都可以看到該 packet。
網(wǎng)卡收包
網(wǎng)線上的 packet 首先被網(wǎng)卡獲取,網(wǎng)卡會(huì)檢查 packet 的 CRC 校驗(yàn),保證完整性,然后將 packet 頭去掉,得到 frame。網(wǎng)卡會(huì)檢查 MAC 包內(nèi)的目的 MAC 地址,如果和本網(wǎng)卡的 MAC 地址不一樣則丟棄 (混雜模式除外)。
網(wǎng)卡將 frame 拷貝到網(wǎng)卡內(nèi)部的 FIFO 緩沖區(qū),觸發(fā)硬件中斷。(如有 ring buffer 的網(wǎng)卡,好像 frame 可以先存在 ring buffer 里再觸發(fā)軟件中斷(下篇文章將詳細(xì)解釋 Linux 中 frame 的走向),ring buffer 是網(wǎng)卡和驅(qū)動(dòng)程序共享,是設(shè)備里的內(nèi)存,但是對(duì)操作系統(tǒng)是可見的,因?yàn)榭吹?linux 內(nèi)核源碼里網(wǎng)卡驅(qū)動(dòng)程序是使用 kcalloc 來分配的空間,所以 ring buffer 一般都有上限,另外這個(gè) ring buffer size,表示的應(yīng)該是能存儲(chǔ)的 frame 的個(gè)數(shù),而不是字節(jié)大小。另外有些系統(tǒng)的 ethtool 命令 并不能改變 ring parameters 來設(shè)置 ring buffer 的大小,暫時(shí)不知道為什么,可能是驅(qū)動(dòng)不支持。)
網(wǎng)卡驅(qū)動(dòng)程序通過硬中斷處理函數(shù),構(gòu)建 sk_buff,把 frame 從網(wǎng)卡 FIFO 拷貝到內(nèi)存 skb 中,接下來交給內(nèi)核處理。(支持 napi 的網(wǎng)卡應(yīng)該是直接放在 ring buffer,不觸發(fā)硬中斷,直接使用軟中斷,拷貝 ring buffer 里的數(shù)據(jù),直接輸送給上層處理,每個(gè)網(wǎng)卡在一次軟中斷處理過程能處理 weight 個(gè) frame)
過程中,網(wǎng)卡芯片對(duì) frame 進(jìn)行了 MAC 過濾,以減小系統(tǒng)負(fù)荷。(除了混雜模式)
網(wǎng)卡中斷處理函數(shù)
產(chǎn)生中斷的每個(gè)設(shè)備都有一個(gè)相應(yīng)的中斷處理程序,是設(shè)備驅(qū)動(dòng)程序的一部分。每個(gè)網(wǎng)卡都有一個(gè)中斷處理程序,用于通知網(wǎng)卡該中斷已經(jīng)被接收了,以及把網(wǎng)卡緩沖區(qū)的數(shù)據(jù)包拷貝到內(nèi)存中。
當(dāng)網(wǎng)卡接收來自網(wǎng)絡(luò)的數(shù)據(jù)包時(shí),需要通知內(nèi)核數(shù)據(jù)包到了。網(wǎng)卡立即發(fā)出中斷。內(nèi)核通過執(zhí)行網(wǎng)卡已注冊(cè)的中斷處理函數(shù)來做出應(yīng)答。中斷處理程序開始執(zhí)行,通知硬件,拷貝最新的網(wǎng)絡(luò)數(shù)據(jù)包到內(nèi)存,然后讀取網(wǎng)卡更多的數(shù)據(jù)包。
這些都是重要、緊迫而又與硬件相關(guān)的工作。內(nèi)核通常需要快速的拷貝網(wǎng)絡(luò)數(shù)據(jù)包到系統(tǒng)內(nèi)存,因?yàn)榫W(wǎng)卡上接收網(wǎng)絡(luò)數(shù)據(jù)包的緩存大小固定,而且相比系統(tǒng)內(nèi)存也要小得多。所以上述拷貝動(dòng)作一旦被延遲,必然造成網(wǎng)卡 FIFO 緩存溢出 - 進(jìn)入的數(shù)據(jù)包占滿了網(wǎng)卡的緩存,后續(xù)的包只能被丟棄,這也應(yīng)該就是 ifconfig 里的 overrun 的來源。
當(dāng)網(wǎng)絡(luò)數(shù)據(jù)包被拷貝到系統(tǒng)內(nèi)存后,中斷的任務(wù)算是完成了,這時(shí)它把控制權(quán)交還給被系統(tǒng)中斷前運(yùn)行的程序。
緩沖區(qū)訪問
網(wǎng)卡的內(nèi)核緩沖區(qū),是在 PC 內(nèi)存中,由內(nèi)核控制,而網(wǎng)卡會(huì)有 FIFO 緩沖區(qū),或者 ring buffer,這應(yīng)該將兩者區(qū)分開。FIFO 比較小,里面有數(shù)據(jù)便會(huì)盡量將數(shù)據(jù)存在內(nèi)核緩沖中。
網(wǎng)卡中的緩沖區(qū)既不屬于內(nèi)核空間,也不屬于用戶空間。它屬于硬件緩沖,允許網(wǎng)卡與操作系統(tǒng)之間有個(gè)緩沖;
內(nèi)核緩沖區(qū)在內(nèi)核空間,在內(nèi)存中,用于內(nèi)核程序,做為讀自或?qū)懲布臄?shù)據(jù)緩沖區(qū);
用戶緩沖區(qū)在用戶空間,在內(nèi)存中,用于用戶程序,做為讀自或?qū)懲布臄?shù)據(jù)緩沖區(qū);
另外,為了加快數(shù)據(jù)的交互,可以將內(nèi)核緩沖區(qū)映射到用戶空間,這樣,內(nèi)核程序和用戶程序就可以同時(shí)訪問這一區(qū)間了。
對(duì)于有 ring buffer 的網(wǎng)卡,ring buffer 是由驅(qū)動(dòng)與網(wǎng)卡共享的,所以內(nèi)核可以直接訪問 ring buffer,一般拷貝 frames 的副本到自己的內(nèi)核空間進(jìn)行處理(deliver 到上層協(xié)議,之后的一個(gè)個(gè) skb 就是按 skb 的指針傳遞方式傳遞,直到用戶獲得數(shù)據(jù),所以,對(duì)于 ring buffer 網(wǎng)卡,大量拷貝發(fā)生在 frame 從 ring buffer 傳遞到內(nèi)核控制的計(jì)算機(jī)內(nèi)存里)。
4. 丟包排查思路
網(wǎng)卡工作在數(shù)據(jù)鏈路層,數(shù)據(jù)量鏈路層,會(huì)做一些校驗(yàn),封裝成幀。我們可以查看校驗(yàn)是否出錯(cuò),確定傳輸是否存在問題。然后從軟件層面,是否因?yàn)榫彌_區(qū)太小丟包。
先查看硬件情況
一臺(tái)機(jī)器經(jīng)常收到丟包的報(bào)警,先看看最底層的有沒有問題:
- 查看工作模式是否正常
[root@localhost?~]#?ethtool?eth0?|?egrep?'Speed|Duplex'
Speed:?1000Mb/s
Duplex:?Full
- 查看檢驗(yàn)是否正常
[root@localhost?~]#?ethtool?-S?eth0?|?grep?crc
rx_crc_errors:?0
Speed,Duplex,CRC 之類的都沒問題,基本可以排除物理層面的干擾。
overruns 和 buffer size
for?i?in?`seq?1?100`;?do?ifconfig?eth2?|?grep?RX?|?grep?overruns;?sleep?1;?done
RX?packets:346547657?errors:0?dropped:0?overruns:35345?frame:0
-g???–show-ringQueries?the?specified?ethernet?device?for?rx/tx?ring?parameter?information.
-G???–set-ringChanges?the?rx/tx?ring?parameters?of?the?specified?ethernet?device.
ethtool?-g?eth0
[root@localhost?~]
Ring?parameters?for?eth0:
Pre-set?maximums:
RX:?4096
RX?Mini:?0
RX?Jumbo:?0
TX:?4096
Current?hardware?settings:
RX:?256
RX?Mini:?0
RX?Jumbo:?0
TX:?256
ethtool?-G?eth0?rx?2048
ethtool?-G?eth0?tx?2048
[root@localhost?~]
[root@localhost?~]
[root@localhost?~]
Ring?parameters?for?eth0:
Pre-set?maximums:
RX:?4096
RX?Mini:?0
RX?Jumbo:?0
TX:?4096
Current?hardware?settings:
RX:?2048
RX?Mini:?0
RX?Jumbo:?0
TX:?2048
Red Hat 官方解決思路
Issue
Why rx_crc_errors incrementing in the receive counter of ethtool -S output?
$?ethtool?-S?<Interface_name>?|?grep?-i?error
?????rx_error_bytes:?0
?????tx_error_bytes:?0
?????tx_mac_errors:?0
?????tx_carrier_errors:?0
?????rx_crc_errors:?9244
?????rx_align_errors:?0
Resolution
- Change the cable.Check switch configuration.Change the network interface card.
Root Cause
- Most of the time incrementing the value of rx_crc_errors means the problem is in Layer-1 of the networking model.When a packet is received at the interface, it goes through a data integrity check which is called cyclic redundancy check. If the packet fails in that check, it is marked as rx_crc_errors.The switch was forcing the NIC to operate in half-duplex mode. Fixing the switch to tell the NIC to operate in full-duplex mode have resolved the issue.
Diagnostic Steps
Check ethtool -S output and find where are the drops and errors.
$?ethtool?-S?<Interface_name>?|?grep?-i?error
?????rx_error_bytes:?0
?????tx_error_bytes:?0
?????tx_mac_errors:?0
?????tx_carrier_errors:?0
?????rx_crc_errors:?9244??>>>>>>
?????rx_align_errors:?0
Check the numbers corresponding to rx_crc_errors.
ethtool?p1p1
Settings?for?p1p1:
?Supported?ports:?[?FIBRE?]
?Supported?link?modes:???10000baseT/Full
?Supported?pause?frame?use:?Symmetric
?Supports?auto-negotiation:?No
?Supported?FEC?modes:?Not?reported
?Advertised?link?modes:??10000baseT/Full
?Advertised?pause?frame?use:?Symmetric
?Advertised?auto-negotiation:?No
?Advertised?FEC?modes:?Not?reported
?Speed:?10000Mb/s
?Duplex:?Full
?Port:?FIBRE
?PHYAD:?0
?Transceiver:?internal
?Auto-negotiation:?off
?Supports?Wake-on:?d
?Wake-on:?d
?Current?message?level:?0x00000007?(7)
??????????drv?probe?link
?Link?detected:?yes
顯示了 p1p1 的接口類型,連接模式,速率等等信息,以及當(dāng)前是否連接了網(wǎng)線(如果是網(wǎng)線 Supported ports 就是 TP,如果是光纖則顯示 Fiber),這里例舉下 3 個(gè)重要關(guān)鍵詞:
Supported ports: [FIBRE]
Speed: 10000Mb/s
Link detected: yes
ethtool?-S?p1p1?|?grep?-i?error
?????rx_errors:?0
?????tx_errors:?0
?????rx_over_errors:?0
?????rx_crc_errors:?0
?????rx_frame_errors:?0
?????rx_fifo_errors:?0
?????rx_missed_errors:?0
?????tx_aborted_errors:?0
?????tx_carrier_errors:?0
?????tx_fifo_errors:?0
?????tx_heartbeat_errors:?0
?????rx_length_errors:?0
?????rx_long_length_errors:?0
?????rx_short_length_errors:?0
?????rx_csum_offload_errors:?0
ethtool?-p?<Interface_name>
ethtool?-p?eth0
ethtool?-i?p1p1
driver:?ixgbe
version:?5.1.0-k-rh7.6
firmware-version:?0x80000960,?18.3.6
expansion-rom-version:
bus-info:?0000:04:00.0
supports-statistics:?yes
supports-test:?yes
supports-eeprom-access:?yes
supports-register-dump:?yes
supports-priv-flags:?yes
ethtool?-s?eth0?speed?100
參考文章
ethtool[3]
Counters Troubleshooting for Linux Driver[4]
Why do I see rx_crc_errors in ethtool output?[5]
ping 請(qǐng)求錯(cuò)誤分析[6]
ifconfig 命令詳解[7]
ethtool 命令詳解[8]
ethtool 解決網(wǎng)卡丟包嚴(yán)重和網(wǎng)卡原理[9]
腳注:
[1]RPS 和 RFS 網(wǎng)卡多隊(duì)列性能調(diào)優(yōu)實(shí)踐: https://wsgzao.github.io/post/rps/
[2]如何使用 MTR 診斷網(wǎng)絡(luò)問題: https://wsgzao.github.io/post/mtr/
[3]ethtool: https://mirrors.edge.kernel.org/pub/software/network/ethtool/
[4]Counters Troubleshooting for Linux Driver: https://community.mellanox.com/s/article/counters-troubleshooting-for-linux-driver
[5]Why do I see rx_crc_errors in ethtool output?: https://access.redhat.com/solutions/154543
[6]ping 請(qǐng)求錯(cuò)誤分析: https://blog.csdn.net/u011857683/article/details/83663316
[7]ifconfig 命令詳解: https://blog.csdn.net/u011857683/article/details/83758503
[8]ethtool 命令詳解: https://blog.csdn.net/u011857683/article/details/83758689
[9]ethtool 解決網(wǎng)卡丟包嚴(yán)重和網(wǎng)卡原理: https://blog.csdn.net/u011857683/article/details/83758869