我正在運行一組負載測試來確定以下設置的性能：
Node.js test suite (client) --> StatsD (server) --> Graphite (server)
簡而言之，node.js 測試套件每 x 秒向位於另一台伺服器上的 StatsD 實例發送一定數量的指標。然後 StatsD 每秒將指標刷新到位於同一伺服器上的 Graphite 實例。然後，我查看測試套件實際發送了多少指標以及 Graphite 接收了多少指標，以確定測試套件和 Graphite 之間的資料包遺失情況。
然而，我注意到有時會出現非常大的資料包遺失率（請注意，它是使用 UDP 協定發送的），範圍為 20-50%。因此，從那時起，我開始研究這些資料包被丟棄的位置，認為這可能是 StatsD 的一些效能問題。因此，我開始記錄系統每個部分的指標，以追蹤發生下降的位置。這就是事情變得奇怪的地方。
我在用著tcp轉儲建立一個捕獲文件，我在測試運行完成後檢查該文件。但每當我在 tcpdump 運行的情況下運行測試時，資料包遺失幾乎不存在！看起來 tcpdump 在某種程度上提高了我的測試性能，但我不明白為什麼它以及如何做到這一點。我正在運行以下命令來記錄伺服器和客戶端上的 tcpdump 訊息：
tcpdump -i any -n port 8125 -w test.cap
在一個特定的測試案例中，我每秒發送 40000 個指標。執行tcpdump時的測試丟包約4%，不執行tcpdump時丟包約20%
兩個系統都以 Xen VM 運行，設定如下：
- 英特爾至強 E5-2630 v2 @ 2.60GHz
- 2GB記憶體
- Ubuntu 14.04 x86_64
我已經檢查過潛在原因的事情：
- 增加 UDP 緩衝區接收/傳送大小。
- CPU 負載影響測試。 （客戶端和伺服器端最大負載為 40-50%）
- 在特定介面而不是“任何”上執行 tcpdump。
- 使用“-p”運行 tcpdump 以停用混雜模式。
- 僅在伺服器上執行 tcpdump。這導致出現 20% 的資料包遺失，但似乎不會影響測試。
- 僅在客戶端上執行 tcpdump。這導致了性能的提高。
- 將 netdev_max_backlog 和 netdev_budget 增加到 2^32-1。這沒有什麼區別。
- 在每個網路卡上嘗試了所有可能的混雜模式設定（伺服器開啟和用戶端關閉、伺服器關閉和用戶端開啟、都開啟、都關閉）。這沒有什麼區別。
答案1
當 tcpdump 運行時，它會相當迅速地讀取傳入的幀。我的假設是網卡的資料包環緩衝區設定可能有點小；當 tcpdump 運行時，它會更及時地被清空。
如果您是紅帽訂閱者，那麼這篇支援文章非常有用資料包接收概述。其中有些東西我認為你還沒考慮過。
考慮您的系統如何處理 IRQ；考慮增加網路介面的「dev_weight」（意味著更多資料包從 NIC 讀取到用戶空間）；查看應用程式讀取套接字的頻率（是否可以使用專用線程，是否存在有關可擴展性的已知問題/解決方法）。
增加 NIC 幀緩衝區（使用ethtool命令 - 查看--set-ring等參數）。
查看“接收端擴展”並至少使用那麼多接收線程來讀取流量。
我想知道 tcpdump 是否正在做一些很酷的事情，例如使用核心支持資料包環緩衝區。這將有助於解釋您所看到的行為。
答案2
你用什麼電源調速器？我見過“按需”或“保守”州長的類似行為。
嘗試使用「效能」調節器並停用伺服器 BIOS 中的任何節能功能。
它會改變什麼嗎？
答案3
另一種方式是ip_conntarck模組，你確定你的linux-box可以接受新的連結嗎？測試通過：
root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536
root@debian:/home/mohsen# sysctl net.ipv4.netfilter.ip_conntrack_count
net.ipv4.netfilter.ip_conntrack_count = 29
你必須測試
net.ipv4.netfilter.ip_conntrack_max > net.ipv4.netfilter.ip_conntrack_count
如果 max == count ，則您的最大連線已滿，且您的 linux-box 無法接受新連線。
如果您沒有 ip_conntrack，您可以透過以下方式輕鬆加載modprobe ip_conntrack
答案4
我懷疑接收方根本無法處理資料包速率，原因如下：
使用 tcpdump在客戶端上減少丟棄的資料包：tcpdump 正在減慢客戶端的速度，因此伺服器看到的打包速率要低得多，但它仍然可以部分處理。您應該能夠透過檢查客戶端和伺服器上的 RX/TX 封包計數器來確認這一假設
您提到您增加了 UDP 緩衝區接收/發送大小，您能詳細說明如何嗎？在伺服器上更改 rmem_max 很重要和rmem_default，範例：
sysctl -w net.core.rmem_max=524287 sysctl -w net.core.wmem_max=524287 sysctl -w net.core.rmem_default=524287 sysctl -w net.core.wmem_default=524287
測試您的設置
停止 statsd 和節點應用程序，然後讓系統空閒使用iperf測試網路/核心可以處理的資料包速率。如果您可以使用 iperf 傳輸 40K 資料包/秒，但不能使用 statsd，那麼您應該集中精力調整 statsd。
其他可調參數
也記得調一下net.core.netdev_max_backlog：當特定介面接收資料包的速度快於核心處理資料包的速度時，允許排隊的最大資料包數。