tcpdumpはudpのパフォーマンスを向上させます

一連の負荷テストを実行して、次のセットアップのパフォーマンスを判断しています。

Node.js test suite (client) --> StatsD (server) --> Graphite (server)

つまり、node.jsテストスイートは、x秒ごとに一定量のメトリックを別のサーバーにあるStatsDインスタンスに送信します。次に、StatsDは、メトリックを毎秒同じサーバーにあるGraphiteインスタンスにフラッシュします。次に、テストスイートによって実際に送信されたメトリックの数と、グラファイトによって受信されたメトリックの数を調べて、テストスイートとグラファイトの間のパケット損失を判断します。

しかし、20〜50％の範囲の非常に大きなパケットドロップ率（UDPプロトコルで送信されていることに注意してください）が得られることがあることに気付きました。そのため、これらのパケットがドロップされる場所を調べ始めたのは、StatsDのパフォーマンスの問題の可能性があるからです。そこで、このドロップが発生した場所を追跡するために、システムのすべての部分でメトリックの記録を開始しました。そして、これは物事が奇妙になる場所です。

私が使用していtcpdumpのを、私は、テストの実行が行われた後、検査キャプチャファイルを作成します。しかし、tcpdumpを実行してテストを実行すると、パケット損失はほとんどありません。tcpdumpがテストのパフォーマンスを何らかの形で向上させているように見えますが、これがなぜ、どのように行われるのかわかりません。次のコマンドを実行して、サーバーとクライアントの両方でtcpdumpメッセージを記録しています。

tcpdump -i any -n port 8125 -w test.cap

特定のテストケースでは、40000メトリック/秒を送信しています。tcpdumpの実行中のテストでは約4％のパケット損失がありますが、テストなしでは約20％のパケット損失があります。

両方のシステムは、次のセットアップでXen VMとして実行されています。

• Intel Xeon E5-2630 v2 @ 2.60GHz
• 2GB RAM
• Ubuntu 14.04 x86_64

潜在的な原因についてすでに確認したこと：

• UDPバッファーの受信/送信サイズを増やします。
• テストに影響するCPU負荷。（クライアント側とサーバー側の両方で最大負荷40〜50％）
• 「any」の代わりに特定のインターフェイスでtcpdumpを実行します。
• 「-p」を指定してtcpdumpを実行し、混合モードを無効にします。
• サーバーでのみtcpdumpを実行します。これにより、20％のパケット損失が発生し、テストには影響がないようです。
• クライアントでのみtcpdumpを実行します。これにより、パフォーマンスが向上しました。
• netdev_max_backlogおよびnetdev_budgetを2 ^ 32-1に増やします。これは違いはありませんでした。
• すべてのNICで無差別モードの可能な設定をすべて試しました（サーバーのオンとクライアントのオフ、サーバーのオフとクライアントのオン、両方のオン、両方のオフ）。これは違いはありませんでした。

tcpdumpの実行中は、着信フレームの読み取り時にかなりプロンプトが表示されます。私の仮説は、NICのパケットリングバッファ設定が小さなサイズに少しあるかもしれないということです。tcpdumpの実行中は、よりタイムリーに空になります。

Red Hatサブスクライバーの場合、このサポート記事はパケット受信の概要に非常に役立ちます。そこには、あなたがまだ検討していないと思うものがいくつかあります。

システムがIRQをどのように処理しているかを検討してください。ネットワークインターフェイスの「dev_weight」を増やすことを検討してください（NICからユーザー空間に読み込まれるパケットが増えることを意味します）。アプリケーションがソケットを読み取る頻度を確認します（専用スレッドを使用できるかどうか、スケーラビリティに関する既知の問題/回避策があります）。

NICフレームバッファーを増やします（ethtoolコマンドを使用して- --set-ringなどの引数を確認します）。

「受信側のスケーリング」を見て、少なくともその数の受信スレッドを使用してトラフィックを読み取ります。

tcpdumpは、パケットリングバッファーのカーネルサポートを使用するなど、何かクールなことをしているのだろうか。それはあなたが見ている行動を説明するのに役立つでしょう。

どのパワーガバナーを使用していますか？「オンデマンド」または「保守的」ガバナーで同様の動作を見てきました。

「パフォーマンス」ガバナーを使用し、サーバーBIOSの省電力機能を無効にしてみてください。

それは何かを変えますか？

別の方法は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

私は、受信側がパケットレートを処理できないことを疑っています。その理由は次のとおりです。

1. クライアントで tcpdump を使用すると、ドロップされるパケットが減ります。tcpdumpはクライアントの速度を低下させるため、サーバーは、部分的に処理できるより低いパッカーレートを認識しています。クライアントとサーバーの両方でRX / TXパケットカウンターを確認することで、この仮説を確認できるはずです。

2. 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を調整することも忘れないでください。特定のインターフェースが、カーネルが処理できるよりも速くパケットを受信した場合、キューに入れることができるパケットの最大数。