開發(fā)或者運維中的性能優(yōu)化建議

寫到這里，本書已經(jīng)快接近尾聲了。在本書前面幾章的內(nèi)容里，我們深入地討論了很多內(nèi)核網(wǎng)絡(luò)模塊相關(guān)的問題。正和庖丁一樣，從今日往后我們看到的也不再是整個的 Linux （整頭牛）了，而是內(nèi)核的內(nèi)部各個模塊（筋?肌理）。我們也理解了內(nèi)核各個模塊是如何有機協(xié)作來幫我們完成任務(wù)的。

那么具備了這些深刻的理解之后，我們在性能方面有哪些優(yōu)化手段可用呢？我在本章中給出一些開發(fā)或者運維中的性能優(yōu)化建議。注意，我用的字眼是建議，而不是原則之類的。每一種性能優(yōu)化方法都有它適用或者不適用的應(yīng)用場景。你應(yīng)當(dāng)根據(jù)你當(dāng)前的項目現(xiàn)狀靈活來選擇用或者不用。

1 網(wǎng)絡(luò)請求優(yōu)化

建議1：盡量減少不必要的網(wǎng)絡(luò) IO

我要給出的第一個建議就是不必要用網(wǎng)絡(luò) IO 的盡量不用。

是的，網(wǎng)絡(luò)在現(xiàn)代的互聯(lián)網(wǎng)世界里承載了很重要的角色。用戶通過網(wǎng)絡(luò)請求線上服務(wù)、服務(wù)器通過網(wǎng)絡(luò)讀取數(shù)據(jù)庫中數(shù)據(jù)，通過網(wǎng)絡(luò)構(gòu)建能力無比強大分布式系統(tǒng)。網(wǎng)絡(luò)很好，能降低模塊的開發(fā)難度，也能用它搭建出更強大的系統(tǒng)。但是這不是你濫用它的理由！

我曾經(jīng)見過有的同學(xué)在自己開發(fā)的接口里要請求幾個第三方的服務(wù)。這些服務(wù)提供了一個 C 或者 Java 語言的SDK，說是 SDK 其實就是簡單的一次 UPD 或者 TCP 請求的封裝而已。這個同學(xué)呢，不熟悉 C 和 Java 語言的代碼，為了省事就直接在本機上把這些 SDK 部署上來，然后自己再通過本機網(wǎng)絡(luò) IO 調(diào)用這些 SDK。我們接手這個項目以后，分析了一下這幾個 SDK 的實現(xiàn)，其實調(diào)用和協(xié)議解析都很簡單。我們在自己的服務(wù)進程里實現(xiàn)了一遍，干掉了這些本機網(wǎng)絡(luò) IO 。效果是該項目 CPU 整體核數(shù)削減了 20 % +。另外除了性能以外，項目的部署難度，可維護性也都得到了極大的提升。

原因我們在本書第 5 章的內(nèi)容里說過，即使是本機網(wǎng)絡(luò) IO 開銷仍然是很大的。先說發(fā)送一個網(wǎng)絡(luò)包，首先得從用戶態(tài)切換到內(nèi)核態(tài)，花費一次系統(tǒng)調(diào)用的開銷。進入到內(nèi)核以后，又得經(jīng)過冗長的協(xié)議棧，這會花費不少的 CPU周期，最后進入環(huán)回設(shè)備的“驅(qū)動程序”。接收端呢，軟中斷花費不少的 CPU 周期又得經(jīng)過接收協(xié)議棧的處理，最后喚醒或者通知用戶進程來處理。當(dāng)服務(wù)端處理完以后，還得把結(jié)果再發(fā)過來。又得來這么一遍，最后你的進程才能收到結(jié)果。你說麻煩不麻煩。另外還有個問題就是多個進程協(xié)作來完成一項工作就必然會引入更多的進程上下文切

換開銷，這些開銷從開發(fā)視角來看，做的其實都是無用功。

上面我們還分析的只是本機網(wǎng)絡(luò) IO，如果是跨機器的還得會有雙方網(wǎng)卡的 DMA 拷貝過程，以及兩端之間的網(wǎng)絡(luò)RTT 耗時延遲。所以，網(wǎng)絡(luò)雖好，但也不能隨意濫用！

建議2：盡量合并網(wǎng)絡(luò)請求

在可能的情況下，盡可能地把多次的網(wǎng)絡(luò)請求合并到一次，這樣既節(jié)約了雙端的 CPU 開銷，也能降低多次 RTT 導(dǎo)致的耗時。

我們舉個實踐中的例子可能更好理解。假如有一個 redis，里面存了每一個 App 的信息（應(yīng)用名、包名、版本、截圖等等）。你現(xiàn)在需要根據(jù)用戶安裝應(yīng)用列表來查詢數(shù)據(jù)庫中有哪些應(yīng)用比用戶的版本更新，如果有則提醒用戶更新。

那么最好不要寫出如下的代碼：

get(包名)...}

上面這段代碼功能上實現(xiàn)上沒問題，問題在于性能。據(jù)我們統(tǒng)計現(xiàn)代用戶平均安裝 App 的數(shù)量在 60 個左右。那這段代碼在運行的時候，每當(dāng)用戶來請求一次，你的服務(wù)器就需要和 redis 進行 60 次網(wǎng)絡(luò)請求?？偤臅r最少是 60個 RTT 起。更好的方法是應(yīng)該使用 redis 中提供的批量獲取命令，如 hmget、pipeline等，經(jīng)過一次網(wǎng)絡(luò) IO 就獲取到所有想要的數(shù)據(jù)，如圖 1.1。

圖1.1 網(wǎng)絡(luò)請求合并

建議3：調(diào)用者與被調(diào)用機器盡可能部署的近一些

在前面的章節(jié)中我們看到在握手一切正常的情況下， TCP 握手的時間基本取決于兩臺機器之間的 RTT 耗時。雖然我們沒辦法徹底去掉這個耗時，但是我們卻有辦法把 RTT 降低，那就是把客戶端和服務(wù)器放的足夠地近一些。盡量把每個機房內(nèi)部的數(shù)據(jù)請求都在本地機房解決，減少跨地網(wǎng)絡(luò)傳輸。

舉例，假如你的服務(wù)是部署在北京機房的，你調(diào)用的 mysql、redis最好都位于北京機房內(nèi)部。盡量不要跨過千里萬里跑到廣東機房去請求數(shù)據(jù)，即使你有專線，耗時也會大大增加！在機房內(nèi)部的服務(wù)器之間的 RTT 延遲大概只有零點幾毫秒，同地區(qū)的不同機房之間大約是 1 ms 多一些。但如果從北京跨到廣東的話，延遲將是 30 - 40 ms 左右，幾十倍的上漲！

建議4：內(nèi)網(wǎng)調(diào)用不要用外網(wǎng)域名

假如說你所在負責(zé)的服務(wù)需要調(diào)用兄弟部門的一個搜索接口，假設(shè)接口是："http://www.sogou.com/wq?key=開發(fā)內(nèi)功修煉"。

那既然是兄弟部門，那很可能這個接口和你的服務(wù)是部署在一個機房的。即使沒有部署在一個機房，一般也是有專線可達的。所以不要直接請求 www.sogou.com， 而是應(yīng)該使用該服務(wù)在公司對應(yīng)的內(nèi)網(wǎng)域名。在我們公司內(nèi)部，每一個外網(wǎng)服務(wù)都會配置一個對應(yīng)的內(nèi)網(wǎng)域名，我相信你們公司也有。

為什么要這么做，原因有以下幾點

1）外網(wǎng)接口慢。本來內(nèi)網(wǎng)可能過個交換機就能達到兄弟部門的機器，非得上外網(wǎng)兜一圈再回來，時間上肯定會慢。

2）帶寬成本高。在互聯(lián)網(wǎng)服務(wù)里，除了機器以外，另外一塊很大的成本就是 IDC 機房的出入口帶寬成本。兩臺機器在內(nèi)網(wǎng)不管如何通信都不涉及到帶寬的計算。但是一旦你去外網(wǎng)兜了一圈回來，行了，一進一出全部要繳帶寬費，你說虧不虧！！

3）NAT 單點瓶頸。一般的服務(wù)器都沒有外網(wǎng) IP，所以要想請求外網(wǎng)的資源，必須要經(jīng)過 NAT 服務(wù)器。但是一個公司的機房里幾千臺服務(wù)器中，承擔(dān) NAT 角色的可能就那么幾臺。它很容易成為瓶頸。我們的業(yè)務(wù)就遇到過好幾次 NAT 故障導(dǎo)致外網(wǎng)請求失敗的情形。NAT 機器掛了，你的服務(wù)可能也就掛了，故障率大大增加。

2 接收過程優(yōu)化

建議1：調(diào)整網(wǎng)卡 RingBuffer 大小

當(dāng)網(wǎng)線中的數(shù)據(jù)幀到達網(wǎng)卡后，第一站就是 RingBu??er。網(wǎng)卡在 RingBuffer 中尋找可用的內(nèi)存位置，找到后 DMA引擎會把數(shù)據(jù) DMA 到 RingBuffer 內(nèi)存里。因此我們第一個要監(jiān)控和調(diào)優(yōu)的就是網(wǎng)卡的 RingBuffer，我們使用ethtool 來來查看一下 Ringbuffer 的大小。

#ethtool-geth0Ringparametersforeth0:Pre-setmaximums:RX:4096RXMini:0RXJumbo:0TX:4096Currenthardwaresettings:RX:512RXMini:0RXJumbo:0TX: 512

這里看到我手頭的網(wǎng)卡設(shè)置 RingBuffer 最大允許設(shè)置到 4096 ，目前的實際設(shè)置是 512。

這里有一個小細節(jié)，ethtool查看到的是實際是Rx bd的大小。Rx bd位于網(wǎng)卡中，相當(dāng)于一個指針。

RingBu??er在內(nèi)存中，Rx bd指向RingBuffer。Rx bd和RingBuffer中的元素是一一對應(yīng)的關(guān)系。在網(wǎng)卡啟

動的時候，內(nèi)核會為網(wǎng)卡的Rx bd在內(nèi)存中分配RingBu??er，并設(shè)置好對應(yīng)關(guān)系。

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

圖2.1RingBuffer 溢出

那我們怎么樣能看一下，我們的服務(wù)器上是否有因為這個原因?qū)е碌膩G包呢？前面我們介紹的四個工具都可以查看

這個丟包統(tǒng)計，拿 ethtool 來舉例：

#ethtool-Seth0......rx_fifo_errors:0tx_fifo_errors: 0

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

# ethtool -G eth1 rx 4096 tx 4096

圖2.2RingBuffer 擴容

這樣網(wǎng)卡會被分配更大一點的”中轉(zhuǎn)站“，可以解決偶發(fā)的瞬時的丟包。不過這種方法有個小副作用，那就是排隊的包過多會增加處理網(wǎng)絡(luò)包的延時。所以應(yīng)該讓內(nèi)核處理網(wǎng)絡(luò)包的速度更快一些更好，而不是讓網(wǎng)絡(luò)包傻傻地在RingBuffer 中排隊。我們后面會再介紹到 RSS ，它可以讓更多的核來參與網(wǎng)絡(luò)包接收。

建議2：多隊列網(wǎng)卡 RSS 調(diào)優(yōu)

硬中斷的情況可以通過內(nèi)核提供的偽文件 /proc/interrupts 來進行查看。拿飛哥手頭的一臺虛機來舉例：

上述結(jié)果是我手頭的一臺虛機的輸出結(jié)果。上面包含了非常豐富的信息。網(wǎng)卡的輸入隊列 virtio1-input.0 的中斷號是 27，總的中斷次數(shù)是 1109986815，并且 27 號中斷都是由 CPU3 來處理的。

那么為什么這個輸入隊列的中斷都在 CPU3 上呢？這是因為內(nèi)核的一個中斷親和性配置，在我機器的偽文件系統(tǒng)中可以查看到。

#cat/proc/irq/27/smp_affinity8

smp_affinity 里是CPU的親和性的綁定，8 是二進制的 1000, 第4位為 1。代表的就是當(dāng)前的第 27 號中斷的都由第 4 個 CPU 核心 - CPU3 來處理。

現(xiàn)在的主流網(wǎng)卡基本上都是支持多隊列的。通過 ethtool 工具可以查看網(wǎng)卡的隊列情況。

#ethtool-leth0Channelparametersforeth0:Pre-setmaximums:RX:0TX:0Other:1Combined:63Currenthardwaresettings:RX:0TX:0Other:1Combined: 8

上述結(jié)果表示當(dāng)前網(wǎng)卡支持的最大隊列數(shù)是 63 ，當(dāng)前開啟的隊列數(shù)是 8 。這樣當(dāng)有數(shù)據(jù)到達的時候，可以將接收進來的包分散到多個隊列里。另外每一個隊列都有自己的中斷號。比如我手頭另外一臺多隊列的機器上看到結(jié)果（為了方便展示我刪除了部分不相關(guān)內(nèi)容）：

這臺機器上 virtio 這塊虛擬網(wǎng)卡上有四個輸入隊列，其硬中斷號分別是 27、29、31 和 33。有獨立的中斷號就可以獨立向某個 CPU 核心發(fā)起硬中斷請求，讓對應(yīng) CPU 來 poll 包。中斷和 CPU 的對應(yīng)關(guān)系還是通過 cat/proc/irq/{中斷號}/smp_affinity 來查看。通過將不同隊列的 CPU 親和性打散到多個 CPU 核上，就可以讓多核同時并行處理接收到的包了。這個特性叫做 RSS（Receive Side Scaling，接收端擴展），如圖 2.3。這是加快 Linux內(nèi)核處理網(wǎng)絡(luò)包的速度非常有用的一個優(yōu)化手段。

圖2.3多隊列網(wǎng)卡

在網(wǎng)卡支持多隊列的服務(wù)器上，想提高內(nèi)核收包的能力，直接簡單加大隊列數(shù)就可以了，這比加大 RingBuffer 更為有用。因為加大 RingBuffer 只是給個更大的空間讓網(wǎng)絡(luò)幀能繼續(xù)排隊，而加大隊列數(shù)則能讓包更早地被內(nèi)核處理。ethtool 修改隊列數(shù)量方法如下：

#ethtool -L eth0 combined 32

不過在一般情況下，由一個叫隊列中斷號和 CPU 之間的親和性并不需要手工維護，有一個 irqbalance的服務(wù)來自動管理。通過 ps 命令可以查看到這個進程。

#ps-ef|grepirqbroot 29805 1 0 18:57 ? 0000 /usr/sbin/irqbalance --foreground

Irqbalance 會根據(jù)系統(tǒng)中斷負載的情況，自動維護和遷移各個中斷的 CPU 親和性，以保持各個 CPU 之間的中斷開銷均衡。如果有必要，irqbalance 也會自動把中斷從一個 CPU 遷移到另一個 CPU 上。如果確實想自己維護親和性，那得先關(guān)掉 irqbalance，然后再修改中斷號對應(yīng)的 smp_affinity。

#serviceirqbalancestop# echo 2 > /proc/irq/30/smp_affinity

建議3：硬中斷合并

在第 1 章中我們看到，當(dāng)網(wǎng)絡(luò)包接收到 RingBuffer 后，接下來通過硬中斷通知 CPU。那么你覺得從整體效率上來講，是有包到達就發(fā)起中斷好呢，還是攢一些數(shù)據(jù)包再通知 CPU 更好。

先允許我來引用一個實際工作中的例子，假如你是一位開發(fā)同學(xué)，和你對口的產(chǎn)品經(jīng)理一天有10 個小需求需要讓你幫忙來處理。她對你有兩種中斷方式：

第一種：產(chǎn)品經(jīng)理想到一個需求，就過來找你，和你描述需求細節(jié)，然后讓你幫你來改。

第二種：產(chǎn)品經(jīng)理想到需求后，不來打擾你，等攢夠 5 個來找你一次，你集中處理。

我們現(xiàn)在不考慮及時性，只考慮你的工作整體效率，你覺得那種方案下你的工作效率會高呢？或者換句話說，你更喜歡哪一種工作狀態(tài)呢？只要你真的有過工作經(jīng)驗，一定都會覺得第二種方案更好。對人腦來講，頻繁的中斷會打亂你的計劃，你腦子里剛才剛想到一半技術(shù)方案可能也就廢了。當(dāng)產(chǎn)品經(jīng)理走了以后，你再想撿起來剛被中斷之的工作的時候，很可能得花點時間回憶一會兒才能繼續(xù)工作。

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

現(xiàn)在我們來看一下網(wǎng)卡的硬中斷合并配置。

#ethtool-ceth0Coalesceparametersforeth0:AdaptiveRX:offTX:off......rx-usecs:1rx-frames:0rx-usecs-irq:0rx-frames-irq:0......

我們來說一下上述結(jié)果的大致含義

Adaptive RX:：自適應(yīng)中斷合并，網(wǎng)卡驅(qū)動自己判斷啥時候該合并啥時候不合并

rx-usecs：當(dāng)過這么長時間過后，一個 RX interrupt 就會被產(chǎn)生

rx-frames：當(dāng)累計接收到這么多個幀后，一個 RX interrupt 就會被產(chǎn)生

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

# ethtool -C eth0 adaptive-rx on

不過需要注意的是，減少中斷數(shù)量雖然能使得 Linux 整體網(wǎng)絡(luò)包吞吐更高，不過一些包的延遲也會增大，所以用的時候得適當(dāng)注意。

建議4：軟中斷 budget 調(diào)整

再舉個日常工作相關(guān)的例子，不知道你有沒有聽說過番茄工作法這種高效工作方法。它的大致意思就是你在工作的時候，要有一整段的不被打擾的時間，集中精力處理某一項工作。這一整段時間時長被建議是 25 分鐘。對于我們的Linux的處理軟中斷的 ksoftirqd 來說，它也和番茄工作法思路類似。一旦它被硬中斷觸發(fā)開始了工作，它會集中精力處理一波兒網(wǎng)絡(luò)包（絕不只是1個），然后再去做別的事情。

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

#sysctl-a|grepnet.core.netdev_budget = 300

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

#sysctl -w net.core.netdev_budget=600

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

建議5：接收處理合并

硬中斷合并是指的攢一堆數(shù)據(jù)包后再通知一次 CPU，不過數(shù)據(jù)包仍然是分開的。Lro（Large Receive Offload） /Gro（Generic Receive Offload） 還能把數(shù)據(jù)包合并起來后再往上層傳遞。

如果應(yīng)用中是大文件的傳輸，大部分包都是一段數(shù)據(jù)，不用 LRO / GRO 的話，會每次都將一個小包傳送到協(xié)議棧（IP接收函數(shù)、TCP接收）函數(shù)中進行處理。開啟了的話，內(nèi)核或者網(wǎng)卡會進行包的合并，之后將一個大包傳給協(xié)議處理函數(shù)，如圖 2.4。這樣 CPU 的效率也就提高了。

圖2.4 接收處理合并

Lro 和 Gro 的區(qū)別是合并包的位置不同。Lro 是在網(wǎng)卡上就把合并的事情給做了，因此要求網(wǎng)卡硬件必須支持才行。而 Gso 是在內(nèi)核源碼中用軟件的方式實現(xiàn)的，更加通用，不依賴硬件。

那么如何查看你的系統(tǒng)內(nèi)是否打開了 LRO / GRO 呢？

#ethtool-keth0generic-receive-offload:onlarge-receive-offload:on...

如果你的網(wǎng)卡驅(qū)動沒有打開 GRO 的話，可以通過如下方式打開。

#ethtool-Keth0groon# ethtool -K eth0 lro on

3 發(fā)送過程優(yōu)化

建議1：控制數(shù)據(jù)包大小

在第四章中我們看到，在發(fā)送協(xié)議棧執(zhí)行的過程中到了 IP 層如果要發(fā)送的數(shù)據(jù)大于 MTU 的話，會被分片。這個分片會有哪些影響呢？首先就是在分片的過程中我們看到多了一次的內(nèi)存拷貝。其次就是分片越多，在網(wǎng)絡(luò)傳輸?shù)倪^程中出現(xiàn)丟包的風(fēng)險也越大。當(dāng)丟包重傳出現(xiàn)的時候，重傳定時器的工作時間單位是秒，也就是說最快 1 秒以后才能開始重傳。所以，如果在你的應(yīng)用程序里可能的話，可以嘗試將數(shù)據(jù)大小控制在一個 MTU 內(nèi)部來極致地提高性能。我所知道的是在早期的 QQ 后臺服務(wù)中應(yīng)用過這個技巧，不知道現(xiàn)在還有沒有在用。

建議2：減少內(nèi)存拷貝

假如你要發(fā)送一個文件給另外一臺機器上，那么比較基礎(chǔ)的做法是先調(diào)用 read 把文件讀出來，再調(diào)用 send 把數(shù)據(jù)把數(shù)據(jù)發(fā)出去。這樣數(shù)據(jù)需要頻繁地在內(nèi)核態(tài)內(nèi)存和用戶態(tài)內(nèi)存之間拷貝，如圖 3.1。

圖3.1 read + write 發(fā)送文件

目前減少內(nèi)存拷貝主要有兩種方法，分別是使用 mmap 和 sendfile 兩個系統(tǒng)調(diào)用。使用 mmap 系統(tǒng)調(diào)用的話，映射進來的這段地址空間的內(nèi)存在用戶態(tài)和內(nèi)核態(tài)都是可以使用的。如果你發(fā)送數(shù)據(jù)是發(fā)的是 mmap 映射進來的數(shù)據(jù)，則內(nèi)核直接就可以從地址空間中讀取，如圖 3.2，這樣就節(jié)約了一次從內(nèi)核態(tài)到用戶態(tài)的拷貝過程。

圖3.2 mmap + write 發(fā)送文件

不過在 mmap 發(fā)送文件的方式里，系統(tǒng)調(diào)用的開銷并沒有減少，還是發(fā)生兩次內(nèi)核態(tài)和用戶態(tài)的上下文切換。如果你只是想把一個文件發(fā)送出去，而不關(guān)心它的內(nèi)容，則可以調(diào)用另外一個做的更極致的系統(tǒng)調(diào)用 - sendfile。在這個系統(tǒng)調(diào)用里，徹底把讀文件和發(fā)送文件給合并起來了，系統(tǒng)調(diào)用的開銷又省了一次。再配合絕大多數(shù)網(wǎng)卡都支持的"分散-收集"（Scatter-gather）DMA 功能。可以直接從 PageCache 緩存區(qū)中 DMA 拷貝到網(wǎng)卡中，如圖3.3。這樣絕大部分的 CPU 拷貝操作就都省去了。

圖3.3 sendfile 發(fā)送文件

建議3：發(fā)送處理合并

在建議 1 中我們說到過發(fā)送過程在 IP 層如果要發(fā)送的數(shù)據(jù)大于 MTU 的話，會被分片。但其實是有一個例外情況，那就是開啟了 TSO（TCP Segmentation Offload）/ GSO（Generic Segmentation Offload）。我們來回顧和跟進

一下發(fā)送過程中的相關(guān)源碼：

//file:net/ipv4/ip_output.cstaticintip_finish_output(structsk_buff*skb){......//大于mtu的話就要進行分片了if(skb->len>ip_skb_dst_mtu(skb)&&!skb_is_gso(skb))returnip_fragment(skb,ip_finish_output2)?elsereturnip_finish_output2(skb)?}

ip_finish_output 是協(xié)議層中的函數(shù)。skb_is_gso 判斷是否使用 gso，如果使用了的話，就可以把分片過程推遲到更下面的設(shè)備層去做。

//file:net/core/dev.cintdev_hard_start_xmit(structsk_buff*skb,structnet_device*dev,structnetdev_queue*txq){......if(netif_needs_gso(skb,features)){if(unlikely(dev_gso_segment(skb,features)))gotoout_kfree_skb?if(skb->next)gotogso?}}

dev_hard_start_xmit 位于設(shè)備層，和物理網(wǎng)卡離得更近了。netif_needs_gso 來判斷是否需要進行 GSO 切分。在這個函數(shù)里會判斷網(wǎng)卡硬件是不是支持 TSO，如果支持則不進行 GSO 切分，將大包直接傳給網(wǎng)卡驅(qū)動，切分工作推遲到網(wǎng)卡硬件中去做。如果硬件不支持，則調(diào)用 dev_gso_segment 開始切分。

推遲分片的好處是可以省去大量包的協(xié)議頭的計算工作量，減輕 CPU 的負擔(dān)。

圖3.4 發(fā)送處理合并

使用 ethtool 工具可以查看當(dāng)前 tso 和 gso 的開啟狀況。

#ethtool-keth0tcp-segmentation-offload:ontx-tcp-segmentation:ontx-tcp-ecn-segmentation:off[fixed]tx-tcp6-segmentation:onudp-fragmentation-offload:off[fixed]generic-segmentation-offload: off

如果沒有開啟，可以使用 ethtool 打開。

#ethtool-Keth0tsoon# ethtool -K eth0 gso on

建議4：多隊列網(wǎng)卡 XPS 調(diào)優(yōu)

在第四章的發(fā)送過程中 4.4.5 小節(jié)，我們看到在 __netdev_pick_tx 函數(shù)中，要選擇一個發(fā)送隊列出來。如果存在XPS （Transmit Packet Steering）配置，就以 XPS 配置為準。過程是根據(jù)當(dāng)前 CPU 的 id 號去到 XPS 中查看是要用哪個發(fā)送隊列，來看下源碼。

//file:net/core/flow_dissector.cstatic inline int get_xps_queue(struct net_device *dev, struct sk_buff *skb){//獲取xps配置dev_maps=rcu_dereference(dev->xps_maps)?if(dev_maps){map=rcu_dereference(map=rcu_dereference(//raw_smp_processor_id()是獲取當(dāng)前cpuiddev_maps->cpu_map[raw_smp_processor_id()])?if(map){if(map->len==1)queue_index=map->queues[0]?...}

源碼中 raw_smp_processor_id 是在獲取當(dāng)前執(zhí)行的 CPU id。用該 CPU 號查看對應(yīng)的 CPU 核是否有配置。XPS配置在 /sys/class/net//queues/tx-/xps_cpus 這個偽文件里。例如對于我手頭的一臺服務(wù)器來說，配置是這樣的。

#cat/sys/class/net/eth0/queues/tx-0/xps_cpus00000001#cat/sys/class/net/eth0/queues/tx-1/xps_cpus00000002#cat/sys/class/net/eth0/queues/tx-2/xps_cpus00000004#cat/sys/class/net/eth0/queues/tx-3/xps_cpus00000008......

上述結(jié)果中 xps_cpus 是一個 CPU 掩碼，表示當(dāng)前隊列對應(yīng)的 CPU 號。從上面輸出看對于 eth0 網(wǎng)卡 下的 tx-0 隊列來說，是和 CPU0 綁定的。00000001 表示 CPU0，00000002 表示 CPU1，...，以此類推。假如當(dāng)前 CPU 核是CPU0，那么找到的隊列就是 eth0 網(wǎng)卡 下的 tx-0。

圖3.5多隊列網(wǎng)卡發(fā)送

那么通過 XPS 指定了當(dāng)前 CPU 要使用的發(fā)送隊列有什么好處呢。好處大致是有兩個：

第一，因為更少的 CPU 爭用同一個隊列，所以設(shè)備隊列鎖上的沖突大大減少。如果進一步配置成每個 CPU都有自己獨立的隊列用，則會完全消除隊列鎖的開銷。

第二，CPU 和發(fā)送隊列一對一綁定以后能提高傳輸結(jié)構(gòu)的局部性，從而進一步提升效率。

關(guān)于RSS、RPS、RFS、aRFS、XPS等網(wǎng)絡(luò)包收發(fā)過程中的優(yōu)化手段可用參考源碼中

Documentation/networking/scaling.txt這個文檔。里面有關(guān)于這些技術(shù)的詳細官方說明。

建議5：使用 eBPF 繞開協(xié)議棧的本機 IO

如果你的業(yè)務(wù)中涉及到大量的本機網(wǎng)絡(luò) IO 可以考慮這個優(yōu)化方案。

在第 5 章中我們看到，本機網(wǎng)絡(luò) IO 和跨機 IO 比較起來，確實是節(jié)約了驅(qū)動上的一些開銷。發(fā)送數(shù)據(jù)不需要進RingBuffer 的驅(qū)動隊列，直接把 skb 傳給接收協(xié)議棧(經(jīng)過軟中斷)。但是在內(nèi)核其它組件上，可是一點都沒少，系統(tǒng)調(diào)用、協(xié)議棧(傳輸層、網(wǎng)絡(luò)層等)、設(shè)備子系統(tǒng)整個走 了一個遍。連“驅(qū)動”程序都走了(雖然對于回環(huán)設(shè)備來說這個驅(qū)動只是一個純軟件的虛擬出來的東東)。

如果想用本機網(wǎng)絡(luò) IO，但是又不想頻繁地在協(xié)議棧中繞來繞去。那么你可以試試 eBPF。使用 eBPF 的 sockmap和 sk redirect 可以繞過 TCP/IP 協(xié)議棧，而被直接發(fā)送給接收端的 socket，業(yè)界已經(jīng)有公司在這么做了。

4 內(nèi)核與進程協(xié)作優(yōu)化

建議1：盡量少用 recvfrom 等進程阻塞的方式

在 3.3 節(jié)我們看到，在使用了 recvfrom 阻塞方式來接收 socket 上數(shù)據(jù)的時候。每次一個進程專?為了等一個socket 上的數(shù)據(jù)就得被從 CPU 上拿下來。然后再換上另一個 進程。等到數(shù)據(jù) ready 了，睡眠的進程又會被喚醒?？偣矁纱芜M程上下文切換開銷。如果我們服務(wù)器上需要有大量的用戶請求需要處理，那就需要有很多的進程存在，而且不停地切換來切換去。這樣的缺點有如下這么幾個：

因為每個進程只能同時等待一條連接，所以需要大量的進程。

進程之間互相切換的時候需要消耗很多 CPU 周期，一次切換大約是 3 - 5 us 左右。

頻繁的切換導(dǎo)致 L1、L2、L3 等高速緩存的效果大打折扣

大家可能以為這種網(wǎng)絡(luò) IO 模型很少見了。但其實在很多傳統(tǒng)的客戶端 SDK 中，比如 mysql、redis 和 kafka 仍然是沿用了這種方式。

建議2：使用成熟的網(wǎng)絡(luò)庫

使用 epoll 可以高效地管理海量的 socket。在服務(wù)器端。我們有各種成熟的網(wǎng)絡(luò)庫進行使用。這些網(wǎng)絡(luò)庫都對epoll 使用了不同程度的封裝。

首先第一個要給大家參考的是 Redis。老版本的 Redis 里單進程高效地使用 epoll 就能支持每秒數(shù)萬 QPS 的高性能。如果你的服務(wù)是單進程的，可以參考 Redis 在網(wǎng)絡(luò) IO 這塊的源碼。

如果是多線程的，線程之間的分工有很多種模式。那么哪個線程負責(zé)等待讀 IO 事件，那個線程負責(zé)處理用戶請求，哪個線程又負責(zé)給用戶寫返回。根據(jù)分工的不同，又衍生出單 Reactor、多 Reactor、以及 Proactor 等多種模式。大家也不必頭疼，只要理解了這些原理之后選擇一個性能不錯的網(wǎng)絡(luò)庫就可以了。比如 PHP 中的 Swoole、Golang 的 net 包、Java 中的 netty 、C++ 中的 Sogou Workflow 都封裝的非常的不錯。

建議3：使用 Kernel-ByPass 新技術(shù)

如果你的服務(wù)對網(wǎng)絡(luò)要求確實特別特特別的高，而且各種優(yōu)化措施也都用過了，那么現(xiàn)在還有終極優(yōu)化大招 --Kernel-ByPass 技術(shù)。在本書我們看到了內(nèi)核在接收網(wǎng)絡(luò)包的時候要經(jīng)過很?的收發(fā)路徑。在這期間牽涉到很多內(nèi)核組件之間的協(xié)同、協(xié)議棧的處理、以及內(nèi)核態(tài)和用戶態(tài)的拷貝和切換。Kernel-ByPass 這類的技術(shù)方案就是繞開內(nèi)核協(xié)議棧，自己在用戶態(tài)來實現(xiàn)網(wǎng)絡(luò)包的收發(fā)。這樣不但避開了繁雜的內(nèi)核協(xié)議棧處理，也減少了頻繁了內(nèi)核態(tài)用戶態(tài)之間的拷貝和切換，性能將發(fā)揮到極致！

目前我所知道的方案有 SOLARFLARE 的軟硬件方案、DPDK 等等。如果大家感興趣，可以多去了解一下！

5 握手揮手過程優(yōu)化

建議1：配置充足的端口范圍

客戶端在調(diào)用 connect 系統(tǒng)調(diào)用發(fā)起連接的時候，需要先選擇一個可用的端口。內(nèi)核在選用端口的時候，是采用從可用端口范圍中某一個隨機位置開始遍歷的方式。如果端口不充足的話，內(nèi)核可能需要循環(huán)撞很多次才能選上一個可用的。這也會導(dǎo)致花費更多的 CPU 周期在內(nèi)部的哈希表查找以及可能的自旋鎖等待上。因此不要等到端口用盡報錯了才開始加大端口范圍，而且應(yīng)該一開始的時候就保持一個比較充足的值。

#vi/etc/sysctl.confnet.ipv4.ip_local_port_range=500065000# sysctl -p //使配置生效

如果端口加大了仍然不夠用，那么可以考慮開啟端口 reuse 和 recycle。這樣端口在連接斷開的時候就不需要等待2MSL 的時間了，可以快速回收。開啟這個參數(shù)之前需要保證 tcp_timestamps 是開啟的。

#vi/etc/sysctl.confnet.ipv4.tcp_timestamps=1net.ipv4.tcp_tw_reuse=1net.ipv4.tw_recycle=1# sysctl -p

建議2：客戶端最好不要使用 bind

如果不是業(yè)務(wù)有要求，建議客戶端不要使用 bind。因為我們在 6.3 節(jié)看到過，connect 系統(tǒng)調(diào)用在選擇端口的時候，即使一個端口已經(jīng)被用過了，只要和已經(jīng)有的連接四元組不完全一致，那這個端口仍然可以被用于建立新連接。但是 bind 函數(shù)會破壞 connect 的這段端口選擇邏輯，直接綁定一個端口，而且一個端口只能被綁定一次。如果使用了 bind，則一個端口只能用于發(fā)起一條連接上。總體上來看，你的機器的最大并發(fā)連接數(shù)就真的受限于65535 了。

建議3：小心連接隊列溢出

服務(wù)器端使用了兩個連接隊列來響應(yīng)來自客戶端的握手請求。這兩個隊列的長度是在服務(wù)器 listen 的時候就確定好了的。如果發(fā)生溢出，很可能會丟包。所以如果你的業(yè)務(wù)使用的是短連接且流量比較大，那么一定得學(xué)會觀察這兩個隊列是否存在溢出的情況。因為一旦出現(xiàn)因為連接隊列導(dǎo)致的握手問題，那么 TCP 連接耗時都是秒級以上了。

對于半連接隊列， 有個簡單的辦法。那就是只要保證 tcp_syncookies 這個內(nèi)核參數(shù)是 1 就能保證不會有因為半連接隊列滿而發(fā)生的丟包。對于全連接隊列來說，可以通過 netstat -s 來觀察。netstat -s 可查看到當(dāng)前系統(tǒng)全連接隊列滿導(dǎo)致的丟包統(tǒng)計。但該數(shù)字記錄的是總丟包數(shù)，所以你需要再借助 watch 命令動態(tài)監(jiān)控。

#watch'netstat--s|grepoverflowed'160 times the listen queue of a socket overflowed //全連接隊列滿導(dǎo)致的丟包

如果輸出的數(shù)字在你監(jiān)控的過程中變了，那說明當(dāng)前服務(wù)器有因為全連接隊列滿而產(chǎn)生的丟包。你就需要加大你的全連接隊列的?度了。全連接隊列是應(yīng)用程序調(diào)用 listen時傳入的 backlog 以及內(nèi)核參數(shù) net.core.somaxconn 二者之中較小的那個。如果需要加大，可能兩個參數(shù)都需要改。如果你手頭并沒有服務(wù)器的權(quán)限，只是發(fā)現(xiàn)自己的客戶端機連接某個 server 出現(xiàn)耗時長，想定位一下是否是因為握手隊列的問題。那也有間接的辦法，可以 tcpdump 抓包查看是否有 SYN 的 TCP Retransmission。如果有偶發(fā)的 TCP Retransmission， 那就說明對應(yīng)的服務(wù)端連接隊列可能有問題了。

建議4：減少握手重試

在 6.5 節(jié)我們看到如果握手發(fā)生異常，客戶端或者服務(wù)端就會啟動超時重傳機制。這個超時重試的時間間隔是翻倍地增長的，1 秒、3 秒、7 秒、15 秒、31 秒、63 秒 ......。對于我們提供給用戶直接訪問的接口來說，重試第一次耗時 1 秒多已經(jīng)是嚴重影響用戶體驗了。如果重試到第三次以后，很有可能某一個環(huán)節(jié)已經(jīng)報錯返回 504 了。所以在這種應(yīng)用場景下，維護這么多的超時次數(shù)其實沒有任何意義。倒不如把他們設(shè)置的小一些，盡早放棄。其中客戶端的 syn 重傳次數(shù)由 tcp_syn_retries 控制，服務(wù)器半連接隊列中的超時次數(shù)是由 tcp_synack_retries 來控制。把它們兩個調(diào)成你想要的值。

建議5：打開 TFO（ TCP Fast Open）

我們第 6 章的時候沒有介紹一個細節(jié)，那就是 fastopen 功能。在客戶端和服務(wù)器端都支持該功能的前提下，客戶端的第三次握手 ack 包就可以攜帶要發(fā)送給服務(wù)器的數(shù)據(jù)。這樣就會節(jié)約一個 RTT 的時間開銷。如果支持，可以嘗試啟用。

#vi/etc/sysctl.confnet.ipv4.tcp_fastopen=3//服務(wù)器和客戶端兩種角色都啟用#sysctl--p

建議6：保持充足的文件描述符上限

在 Linux 下一切皆是文件，包括我們網(wǎng)絡(luò)連接中的 socket。如果你的服務(wù)進程需要支持海量的并發(fā)連接。那么調(diào)整和加大文件描述符上限是很關(guān)鍵的。否則你的線上服務(wù)將會收到 “Too many open files”這個錯誤。

相關(guān)的限制機制請參考 8.2 節(jié)，這里我們給出一套推薦的修改方法。例如你的服務(wù)需要在單進程支持 100 W 條并發(fā)，那么建議：

#vi/etc/sysctl.conffs.file-max=1100000//系統(tǒng)級別設(shè)置成110W，多留點buffer。fs.nr_open=1100000//進程級別也設(shè)置成110W，因為要保證比hardnofile大#sysctl--p#vi/etc/security/limits.conf//用戶進程級別都設(shè)置成100W*softnofile1000000* hard nofile 1000000

建議7：如果請求頻繁，請棄用短連接改用長連接

如果你的服務(wù)器頻繁請求某個 server，比如 redis 緩存。和建議 1 比起來，一個更好一點的方法是使用長連接。這樣的好處有

1）節(jié)約了握手開銷。短連接中每次請求都需要服務(wù)和緩存之間進行握手，這樣每次都得讓用戶多等一個握手的時間開銷。

2）規(guī)避了隊列滿的問題。前面我們看到當(dāng)全連接或者半連接隊列溢出的時候，服務(wù)器直接丟包。而客戶端呢并不知情，所以傻傻地等 3 秒才會重試。要知道 tcp 本身并不是專門為互聯(lián)網(wǎng)服務(wù)設(shè)計的。這個 3 秒的超時對于互聯(lián)網(wǎng)用戶的體驗影響是致命的。

3）端口數(shù)不容易出問題。端連接中，在釋放連接的時候，客戶端使用的端口需要進入 TIME_WAIT 狀態(tài)，等待 2MSL的時間才能釋放。所以如果連接頻繁，端口數(shù)量很容易不夠用。而長連接就固定使用那么幾十上百個端口就夠用了。

建議8：TIME_WAIT 的優(yōu)化

很多線上服務(wù)如果使用了短連接的情況下，就會出現(xiàn)大量的 TIME_WAIT。

首先，我想說的是沒有必要見到兩三萬個 TIME_WAIT 就恐慌的不行。從內(nèi)存的?度來考慮，一條 TIME_WAIT 狀態(tài)的連接僅僅是 0.5 KB 的內(nèi)存而已。從端口占用的角度來說，確實是消耗掉了一個端口。但假如你下次再連接的是不同的 Server 的話，該端口仍然可以使用。只有在所有 TIME_WAIT 都聚集在和一個 Server 的連接上的時候才會有問題。

那怎么解決呢? 其實辦法有很多。第一個辦法是按上面建議 1 中的開啟端口 reuse 和 recycle。第二個辦法是限制TIME_WAIT 狀態(tài)的連接的最大數(shù)量。

#vi/etc/sysctl.confnet.ipv4.tcp_max_tw_buckets=32768# sysctl --p

如果再徹底一些，也可以干脆采用建議 7 ，直接用?連接代替頻繁的短連接。連接頻率大大降低以后，自然也就沒有 TIME_WAIT 的問題了。

原文標(biāo)題：深入理解Linux網(wǎng)絡(luò)之網(wǎng)絡(luò)性能優(yōu)化建議

文章出處：【微信公眾號：Linux閱碼場】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。