啓用TCP_NODELAY的Linux環回性能

我最近偶然發現了一個有趣的TCP性能問題，同時運行了一些比較網絡性能和環回性能的性能測試。在我的情況下，網絡性能超過了環回性能（1Gig網絡，相同的子網）。在我處理延遲很重要的情況下，TCP_NODELAY已啓用。我們提出的最好理論是TCP擁塞控制正在阻止數據包。我們做了一些數據包分析，我們可以確定地看到數據包正在被保留，但原因並不明顯。現在的問題...啓用TCP_NODELAY的Linux環回性能

1）在什麼情況下，以及爲什麼通過回送進行通信比通過網絡慢？

2）當儘可能快地發送時，爲什麼切換TCP_NODELAY對環回的最大吞吐量的影響要遠遠大於網絡？

3）如何檢測和分析TCP擁塞控制作爲性能差的潛在解釋？

4）有沒有人有任何其他理論來解釋這種現象？如果是的話，任何證明理論的方法？

下面是一個簡單的點產生了一些樣本數據指向C++應用程序：

 
Transport  Message Size (bytes) TCP NoDelay Send Buffer (bytes) Sender Host Receiver Host Throughput (bytes/sec) Message Rate (msgs/sec) 
TCP   128     On   16777216    HostA   HostB   118085994    922546 
TCP   128     Off   16777216    HostA   HostB   118072006    922437 
TCP   128     On    4096    HostA   HostB   11097417     86698 
TCP   128     Off    4096    HostA   HostB   62441935    487827 
TCP   128     On   16777216    HostA   HostA   20606417    160987 
TCP   128     Off   16777216    HostA   HostA   239580949    1871726 
TCP   128     On    4096    HostA   HostA   18053364    141041 
TCP   128     Off    4096    HostA   HostA   214148304    1673033 
UnixStream 128     -    16777216    HostA   HostA   89215454    696995 
UnixDatagram 128     -    16777216    HostA   HostA   41275468    322464 
NamedPipe  128     -    -      HostA   HostA   73488749    574130

這裏有一些更多的有用的信息：

我只看到這個問題與小消息
HostA和HostB都具有相同的硬件套件（Xeon [email protected]，共32個內核/ 128 Gig Mem/1Gig Nics）
OS是RHEL 5.4內核2.6.18-164.2.1.el5）

謝謝

來源

2011-04-29 rns

如果等待時間是至關重要的，我會切換到UNIX域套接字（非常類似於TCP套接字）或管道（更快，更復雜，你需要兩個管道的雙向連接）。他們攜帶的行李比TCP套接字少，並且延遲時間更短。 – 2011-04-29 13:04:00

這些可能不是相關的問題，但我很好奇。在兩種情況下你看到的實際結果是什麼？吞吐量和時間是多少？另外，測試主要是在一個方向上發送，還是更多地是在響應中發送相同數量的數據的回聲樣式測試？ – 2011-04-29 13:13:35

@Mark我將我們的測試結果添加到主文章中。我還添加了一些其他相關細節。測試正在向一個方向發送。 – rns 2011-04-30 22:10:00

1或2）我不知道爲什麼你懶得用迴環可言，我個人不知道它會如何模仿一個真實的界面，以及它的有效性如何。我知道Microsoft禁用環回接口的NAGLE（如果你在意的話）。看看this link，這裏有一個討論。

3）我會密切關注在這兩種情況下的前幾個數據包，看看你是否得到前五個數據包的嚴重延遲。請參閱here

來源

2011-04-29 19:11:51 stackmate

我不能看到「此鏈接」，說MS禁用內格爾Loopback接口什麼。線程似乎是關於當*用戶*這樣做時會發生什麼。他問道，爲什麼在回送時禁用Nagle的算法更糟糕，如果已經關閉，情況就不會這樣。你能澄清嗎？ – EJP 2011-04-30 12:23:25

我們之所以使用環回是因爲我們認爲我們會獲得更好的性能，但是我們現在偶然發現了這種現象，我們試圖找出原因。此外，還有使用環回的真實世界用例（因爲預期會有更好的性能，並會削減硬件成本）。 – rns 2011-04-30 22:12:52

這個鏈接與微軟無關，它涉及到這個問題，也許你可以從這個線索推斷出一些東西 - 我認爲它沒有得到答案 - 但可能會討論相關的想法。 – stackmate 2011-05-02 17:42:25

1）在什麼情況下以及爲什麼通過回送進行通信比通過網絡慢？

Loopback將tx + rx的數據包設置+ tcp chksum計算放在同一臺機器上，所以它需要做兩倍的處理，而使用兩臺機器在它們之間分配tx/rx。這可能會對環回產生負面影響。

2）當發送儘可能快，爲什麼切換 TCP_NODELAY 有那麼多比在網絡上更超過迴環的最大吞吐量的影響？

不知道你是如何得出這個結論的，但是loopback vs network的實現方式有很大的不同，如果你試圖將它們推到極限，你會遇到不同的問題。環回接口（如答案1中所述）會在同一臺機器上導致tx + rx處理開銷。另一方面，網卡在循環緩衝區中可以有多少未完成的數據包有一定的限制，這將導致完全不同的瓶頸（而且這種差異在芯片之間也有很大差別，甚至在兩者之間他們）

3）我們如何檢測和分析TCP擁塞控制作爲性能差的潛在解釋？

擁塞控制只有在有數據包丟失的情況下才會啓動。你看到丟包了嗎？否則，您可能會對tcp窗口大小與網絡延遲因素產生限制。

4）有沒有人有任何其他理論來解釋這種現象的原因？如果是的話，任何證明理論的方法？

我不明白你在這裏提到的現象。我在桌面上看到的一切都是你有一些帶有大量發送緩衝區的套接字 - 這可能是完全合法的。在一臺快速機器上，您的應用程序肯定能夠生成比網絡可以抽出更多的數據，所以我不確定您在這裏將什麼歸類爲問題。

最後一點：小消息創建網絡由於種種原因，如在一個更大的性能損失：

有一個固定的每個數據包的開銷（用於MAC + IP + TCP頭）和有效載荷越小，你將擁有的開銷就越多。
許多網卡的限制都是相對於未完成數據包的數量而言的，這意味着當使用較小的數據包時，數據量會少得多，從而導致網卡瓶頸。網絡本身就是每個數據包的開銷，因此您可以通過網絡泵送的最大數據量取決於數據包的大小。

來源

2011-05-12 22:28:01 csd

這也是我面臨的同樣的問題。在同一臺RHEL6計算機上運行的兩個組件之間傳輸2 MB數據時，需要7秒才能完成。當數據量很大時，時間是不可接受的。花了1分鐘來傳輸10 MB的數據。

然後我試着用TCP_NODELAY禁用。它解決了這個問題

當兩個組件位於兩臺不同的機器中時，不會發生這種情況。

來源

2013-08-30 04:57:20 Gayanath

啓用TCP_NODELAY的Linux環回性能

回答

相關問題