上一篇文章中《圖解Linux網絡包接收過程》，我們梳理了在Linux系統下一個數據包被接收的整個過程。Linux內核對網絡包的接收過程大致可以分為接收到RingBuffer、硬中斷處理、ksoftirqd軟中斷處理幾個過程。其中在ksoftirqd軟中斷處理中，把數據包從RingBuffer中摘下來，送到協議棧的處理，再之后送到用戶進程socket的接收隊列中。

圖1 Linux內核接收網絡包過程 理解了Linux工作原理之后，還有更重要的兩件事情。第一是動手監控，會實際查看網絡包接收的整體情況。第二是調優，當你的服務器有問題的時候，你能找到瓶頸所在，并會利用內核開放的參數進行調節。 一 先說幾個工具

在正式內容開始之前，我們先來了解幾個Linux下監控網卡時可用的工具。

1）ethtool

首先第一個工具就是我們在上文中提到的ethtool，它用來查看和設置網卡參數。這個工具其實本身只是提供幾個通用接口，真正的實現是都是在網卡驅動中的。正因為該工具是由驅動直接實現的，所以個人覺得它最重要。

該命令比較復雜，我們選幾個今天能用到的說

-i顯示網卡驅動的信息，如驅動的名稱、版本等

-S查看網卡收發包的統計情況

-g/-G查看或者修改RingBuffer的大小

-l/-L查看或者修改網卡隊列數

-c/-C查看或者修改硬中斷合并策略

實際查看一下網卡驅動：

# ethtool -i eth0 driver: ixgbe ......這里看到我的機器上網卡驅動程序是ixgbe。有了驅動名稱，就可以在源碼中找到對應的代碼了。對于ixgbe來說，其驅動的源代碼位于drivers/net/ethernet/intel/ixgbe目錄下。ixgbe_ethtool.c`下都是實現的供ethtool使用的相關函數，如果ethtool哪里有搞不明白的，就可以通過這種方式查找到源碼來讀。另外我們前文《圖解Linux網絡包接收過程》里提到的NAPI收包時的poll回調函數，啟動網卡時的open函數都是在這里實現的。

2）ifconfig

網絡管理工具ifconfig不只是可以為網卡配置ip，啟動或者禁用網卡，也包含了一些網卡的統計信息。

eth0: flags=4163 mtu 1500 inet 10.162.42.51 netmask 255.255.248.0 broadcast 10.162.47.255 inet6 fe80:84ff88d1 prefixlen 64 scopeid 0x20 ether 6c8488:d1 txqueuelen 1000 (Ethernet) RX packets 2953454 bytes 414212810 (395.0 MiB) RX errors 0 dropped 4636605 overruns 0 frame 0 TX packets 127887 bytes 82943405 (79.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

RX packets：接收的總包數

RX bytes：接收的字節數

RX errors：表示總的收包的錯誤數量

RX dropped：數據包已經進入了 Ring Buffer，但是由于其它原因導致的丟包

RX overruns：表示了 fifo 的 overruns，這是由于 Ring Buffer不足導致的丟包

3）偽文件系統/proc

Linux 內核提供了 /proc 偽文件系統，通過/proc可以查看內核內部數據結構、改變內核設置。我們先跑一下題，看一下這個偽文件系統里都有啥：

/proc/sys目錄可以查看或修改內核參數

/proc/cpuinfo可以查看CPU信息

/proc/meminfo可以查看內存信息

/proc/interrupts統計所有的硬中斷

/proc/softirqs統計的所有的軟中斷信息

/proc/slabinfo統計了內核數據結構的slab內存使用情況

/proc/net/dev可以看到一些網卡統計數據

詳細聊下偽文件/proc/net/dev，通過它可以看到內核中對網卡的一些相關統計。包含了以下信息：

bytes: 發送或接收的數據的總字節數

packets: 接口發送或接收的數據包總數

errs: 由設備驅動程序檢測到的發送或接收錯誤的總數

drop: 設備驅動程序丟棄的數據包總數

fifo: FIFO緩沖區錯誤的數量

frame: The number of packet framing errors.（分組幀錯誤的數量）

colls: 接口上檢測到的沖突數

所以，偽文件/proc/net/dev也可以作為我們查看網卡工作統計數據的工具之一。

4）偽文件系統sysfs

sysfs和/proc類似，也是一個偽文件系統，但是比proc更新，結構更清晰。其中的/sys/class/net/eth0/statistics/也包含了網卡的統計信息。

# cd /sys/class/net/eth0/statistics/ # grep . * | grep tx tx_aborted_errors:0 tx_bytes:170699510 tx_carrier_errors:0 tx_compressed:0 tx_dropped:0 tx_errors:0 tx_fifo_errors:0 tx_heartbeat_errors:0 tx_packets:262330 tx_window_errors:0

好了，簡單了解過這幾個工具以后，讓我們正式開始今天的行程。

二 RingBuffer監控與調優

前面我們看到，當網線中的數據幀到達網卡后，第一站就是RingBuffer（網卡通過DMA機制將數據幀送到RingBuffer中）。因此我們第一個要監控和調優的就是網卡的RingBuffer，我們使用ethtool來查看一下：

# ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 512 RX Mini: 0 RX Jumbo: 0 TX: 512

這里看到我手頭的網卡設置RingBuffer最大允許設置到4096，目前的實際設置是512。

這里有一個小細節，ethtool查看到的是實際是Rx bd的大小。Rx bd位于網卡中，相當于一個指針。RingBuffer在內存中，Rx bd指向RingBuffer。Rx bd和RingBuffer中的元素是一一對應的關系。在網卡啟動的時候，內核會為網卡的Rx bd在內存中分配RingBuffer，并設置好對應關系。

在Linux的整個網絡棧中，RingBuffer起到一個任務的收發中轉站的角色。對于接收過程來講，網卡負責往RingBuffer中寫入收到的數據幀，ksoftirqd內核線程負責從中取走處理。只要ksoftirqd線程工作的足夠快，RingBuffer這個中轉站就不會出現問題。但是我們設想一下，假如某一時刻，瞬間來了特別多的包，而ksoftirqd處理不過來了，會發生什么？這時RingBuffer可能瞬間就被填滿了，后面再來的包網卡直接就會丟棄，不做任何處理！

那我們怎么樣能看一下，我們的服務器上是否有因為這個原因導致的丟包呢？前面我們介紹的四個工具都可以查看這個丟包統計，拿ethtool來舉例：

# ethtool -S eth0 ...... rx_fifo_errors: 0 tx_fifo_errors: 0

rx_fifo_errors如果不為0的話（在 ifconfig 中體現為 overruns 指標增長），就表示有包因為RingBuffer裝不下而被丟棄了。那么怎么解決這個問題呢？很自然首先我們想到的是，加大RingBuffer這個“中轉倉庫”的大小。通過ethtool就可以修改。

# ethtool -G eth1 rx 4096 tx 4096

這樣網卡會被分配更大一點的”中轉站“，可以解決偶發的瞬時的丟包。不過這種方法有個小副作用，那就是排隊的包過多會增加處理網絡包的延時。所以另外一種解決思路更好，那就是讓內核處理網絡包的速度更快一些，而不是讓網絡包傻傻地在RingBuffer中排隊。怎么加快內核消費RingBuffer中任務的速度呢，別著急，我們繼續往下看...

三 硬中斷監控與調優

在數據被接收到RingBuffer之后，下一個執行就是就是硬中斷的發起。我們先來查看硬中斷，然后再聊下怎么優化。

1）監控

硬中斷的情況可以通過內核提供的偽文件/proc/interrupts來進行查看。

$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 34 0 0 0 IO-APIC-edge timer ...... 27: 351 0 0 1109986815 PCI-MSI-edge virtio1-input.0 28: 2571 0 0 0 PCI-MSI-edge virtio1-output.0 29: 0 0 0 0 PCI-MSI-edge virtio2-config 30: 4233459 1986139461 244872 474097 PCI-MSI-edge virtio2-input.0 31: 3 0 2 0 PCI-MSI-edge virtio2-output.0

上述結果是我手頭的一臺虛機的輸出結果。上面包含了非常豐富的信息，讓我們一一道來：

網卡的輸入隊列virtio1-input.0的中斷號是27

27號中斷都是由CPU3來處理的

總的中斷次數是1109986815。

這里有兩個細節我們需要關注一下。

（1）為什么輸入隊列的中斷都在CPU3上呢？

這是因為內核的一個配置，在偽文件系統中可以查看到。

#cat /proc/irq/27/smp_affinity 8

smp_affinity里是CPU的親和性的綁定，8是二進制的1000,第4位為1，代表的就是第4個CPU核心-CPU3.

（2）對于收包來過程來講，硬中斷的總次數表示的是Linux收包總數嗎？
不是，硬件中斷次數不代表總的網絡包數。第一網卡可以設置中斷合并，多個網絡幀可以只發起一次中斷。第二NAPI 運行的時候會關閉硬中斷，通過poll來收包。

2）多隊列網卡調優

現在的主流網卡基本上都是支持多隊列的，我們可以通過將不同的隊列分給不同的CPU核心來處理，從而加快Linux內核處理網絡包的速度。這是最為有用的一個優化手段。

每一個隊列都有一個中斷號，可以獨立向某個CPU核心發起硬中斷請求，讓CPU來poll包。通過將接收進來的包被放到不同的內存隊列里，多個CPU就可以同時分別向不同的隊列發起消費了。這個特性叫做RSS（Receive Side Scaling，接收端擴展）。通過ethtool工具可以查看網卡的隊列情況。

# ethtool -l eth0 Channel parameters for eth0: Pre-set maximums: RX: 0 TX: 0 Other: 1 Combined: 63 Current hardware settings: RX: 0 TX: 0 Other: 1 Combined: 8

上述結果表示當前網卡支持的最大隊列數是63，當前開啟的隊列數是8。對于這個配置來講，最多同時可以有8個核心來參與網絡收包。如果你想提高內核收包的能力，直接簡單加大隊列數就可以了，這比加大RingBuffer更為有用。因為加大RingBuffer只是給個更大的空間讓網絡幀能繼續排隊，而加大隊列數則能讓包更早地被內核處理。ethtool修改隊列數量方法如下：

#ethtool -L eth0 combined 32

我們前文說過，硬中斷發生在哪一個核上，它發出的軟中斷就由哪個核來處理。所有通過加大網卡隊列數，這樣硬中斷工作、軟中斷工作都會有更多的核心參與進來。

每一個隊列都有一個中斷號，每一個中斷號都是綁定在一個特定的CPU上的。如果你不滿意某一個中斷的CPU綁定，可以通過修改/proc/irq/{中斷號}/smp_affinity來實現。

一般處理到這里，網絡包的接收就沒有大問題了。但如果你有更高的追求，或者是說你并沒有更多的CPU核心可以參與進來了，那怎么辦？放心，我們也還有方法提高單核的處理網絡包的接收速度。

3）硬中斷合并

先來講一個實際中的例子，假如你是一位開發同學，和你對口的產品經理一天有10個小需求需要讓你幫忙來處理。她對你有兩種中斷方式：

第一種：產品經理想到一個需求，就過來找你，和你描述需求細節，然后讓你幫你來改

第二種：產品經理想到需求后，不來打擾你，等攢夠5個來找你一次，你集中處理

我們現在不考慮及時性，只考慮你的工作整體效率，你覺得那種方案下你的工作效率會高呢？或者換句話說，你更喜歡哪一種工作狀態呢？很明顯，只要你是一個正常的開發，都會覺得第二種方案更好。對人腦來講，頻繁的中斷會打亂你的計劃，你腦子里剛才剛想到一半技術方案可能也就廢了。當產品經理走了以后，你再想撿起來剛被中斷之的工作的時候，很可能得花點時間回憶一會兒才能繼續工作。

對于CPU來講也是一樣，CPU要做一件新的事情之前，要加載該進程的地址空間，load進程代碼，讀取進程數據，各級別cache要慢慢熱身。因此如果能適當降低中斷的頻率，多攢幾個包一起發出中斷，對提升CPU的工作效率是有幫助的。所以，網卡允許我們對硬中斷進行合并。

現在我們來看一下網卡的硬中斷合并配置。

# ethtool -c eth0 Coalesce parameters for eth0: Adaptive RX: off TX: off ...... rx-usecs: 1 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 ......

我們來說一下上述結果的大致含義

Adaptive RX: 自適應中斷合并，網卡驅動自己判斷啥時候該合并啥時候不合并

rx-usecs：當過這么長時間過后，一個RX interrupt就會被產生

rx-frames：當累計接收到這么多個幀后，一個RX interrupt就會被產生

如果你想好了修改其中的某一個參數了的話，直接使用ethtool -C就可以，例如：

ethtool -C eth0 adaptive-rx on

不過需要注意的是，減少中斷數量雖然能使得Linux整體吞吐更高，不過一些包的延遲也會增大，所以用的時候得適當注意。

四 軟中斷監控與調優

在硬中斷之后，再接下來的處理過程就是ksoftirqd內核線程中處理的軟中斷了。之前我們說過，軟中斷和它對應的硬中斷是在同一個核心上處理的。因此，前面硬中斷分散到多核上處理的時候，軟中斷的優化其實也就跟著做了，也會被多核處理。不過軟中斷也還有自己的可優化選項。

1）監控

軟中斷的信息可以從 /proc/softirqs 讀取：

$ cat /proc/softirqs CPU0 CPU1 CPU2 CPU3 HI: 0 2 2 0 TIMER: 704301348 1013086839 831487473 2202821058 NET_TX: 33628 31329 32891 105243 NET_RX: 418082154 2418421545 429443219 1504510793 BLOCK: 37 0 0 25728280 BLOCK_IOPOLL: 0 0 0 0 TASKLET: 271783 273780 276790 341003 SCHED: 1544746947 1374552718 1287098690 2221303707 HRTIMER: 0 0 0 0 RCU: 3200539884 3336543147 3228730912 3584743459

2）軟中斷budget調整

不知道你有沒有聽說過番茄工作法，它的大致意思就是你要有一整段的不被打擾的時間，集中精力處理某一項作業。這一整段時間時長被建議是25分鐘。對于我們的Linux的處理軟中斷的ksoftirqd來說，它也和番茄工作法思路類似。一旦它被硬中斷觸發開始了工作，它會集中精力處理一波兒網絡包（絕不只是1個），然后再去做別的事情。

我們說的處理一波兒是多少呢，策略略復雜。我們只說其中一個比較容易理解的，那就是net.core.netdev_budget內核參數。

# sysctl -a | grep net.core.netdev_budget = 300

這個的意思說的是，ksoftirqd一次最多處理300個包，處理夠了就會把CPU主動讓出來，以便Linux上其它的任務可以得到處理。那么假如說，我們現在就是想提高內核處理網絡包的效率。那就可以讓ksoftirqd進程多干一會兒網絡包的接收，再讓出CPU。至于怎么提高，直接修改不這個參數的值就好了。

# sysctl -w net.core.netdev_budget=600

如果要保證重啟仍然生效，需要將這個配置寫到/etc/sysctl.conf

3）軟中斷GRO合并

GRO和硬中斷合并的思想很類似，不過階段不同。硬中斷合并是在中斷發起之前，而GRO已經到了軟中斷上下文中了。

如果應用中是大文件的傳輸，大部分包都是一段數據，不用GRO的話，會每次都將一個小包傳送到協議棧（IP接收函數、TCP接收）函數中進行處理。開啟GRO的話，Linux就會智能進行包的合并，之后將一個大包傳給協議處理函數。這樣CPU的效率也是就提高了。

# ethtool -k eth0 | grep generic-receive-offload generic-receive-offload: on

如果你的網卡驅動沒有打開GRO的話，可以通過如下方式打開。

# ethtool -K eth0 gro on

GRO說的僅僅只是包的接收階段的優化方式，對于發送來說是GSO。

五 總結

在網絡技術這一領域里，有太多的知識內容都停留在理論階段了。你可能覺得你的網絡學的滾瓜爛熟了，可是當你的線上服務出現問題的時候，你還是不知道該怎么排查，怎么優化。這就是因為只懂了理論，而不清楚Linux是通過哪些內核機制將網絡技術落地的，各個內核組件之間怎么配合，每個組件有哪些參數可以做調整。我們用兩篇文章詳細討論了Linux網絡包的接收過程，以及這個過程中的一些統計數據如何查看，如何調優。相信消化完這兩篇文章之后，你的網絡的理解直接能提升1個Level，你對線上服務的把控能力也會更加如魚得水。

原文標題：Linux 網絡包接收過程的監控與調優

文章出處：【微信公眾號：Linux愛好者】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq