rmem_max値が高いほど、パケット損失が多くなる
rmem_max Linux設定は、UDPパケットを受信するバッファーのサイズを定義します。
トラフィックがビジーになると、パケット損失が発生し始めます。
着信帯域幅に応じてパケットロスがどのように増加するかをグラフ化しました。
（私は IPerf を使用して、2つの間のUDPトラフィックを生成しますVMインスタンス）。
さまざまな色は、さまざまなrmem_maxの値に対応しています。
ご覧のように、rmem_maxを26214400（紺色）に設定すると、小さい値よりも早くパケット損失が発生します。 Linuxのデフォルト値は131071（濃い緑）が適切に見えます。
これらの状況で、なぜ JBossのドキュメント がrmem_maxを26214400に設定することを推奨するのですか？
これは、UDPトラフィックが350 MBytes /秒を超えると予想されるためですか？とにかく、1％を超えるパケット損失で何も機能しないと思います...
何が欠けていますか？
詳細：両方のノードで（たとえば）sysctl -w net.core.rmem_max=131071を使用し、サーバーiperf -s -u -P 0 -i 1 -p 5001 -f Mとして使用し、もう一方をクライアントiperf -c 172.29.157.3 -u -P 1 -i 1 -p 5001 -f M -b 300M -t 5 -d -L 5001 -T 1として使用しました。
バッファが増えても速度が上がるとは限りません。より多くのバッファはより多くのバッファを意味します。アプリケーションが必ずしも十分に迅速に受信したデータを処理できるわけではないため、特定の値を下回るとオーバーフローが発生します。これは悪いことですが、たまにトラフィックが急増した場合でも、アプリが適切なレートでサービスを提供するのに十分なバッファーがある時点では、他のものが無駄になる可能性があります。
大きすぎると、皮肉なことにパケットの損失につながる可能性のあるメモリを見つけて割り当てるために、カーネルにはるかに大きな負担がかかります。私の直感は、これはあなたが見ているものかもしれないということですが、確認するためにいくつかの他のメトリックが必要になるでしょう。
2.5Mの数値は、TCPのrmemおよびwmem値の設定に関する推奨事項に由来する可能性があります。ここで、ウィンドウのサイズ設定とバッファー設定の関係は、特定の状況下で大きな影響を与える可能性があります。 TCP！= UDP-しかし、一部の人々は、それが役立つ場合、TCPは、UDPも助けると考えています。あなたは正しい経験的情報を得ています。あなた、私は256Kの値に固執し、それを均等に呼びます。
問題は、通常、2つのエンドポイント（つまりサーバー）間のパスに複数のスイッチがあることです。 rmemを使用すると、エンドポイントのバッファのサイズを増やすことができますが、スイッチのバッファには影響がなく、かなり制限があります。したがって、スイッチバッファのオーバーフローによりパケットが失われる可能性があります。