UDP受信バッファエラー

Question

検索tpacket_rcv：でtcpdumpを示しますaf_packet.c。 AF_PACKET

他の人がtcpdumpによって発生した問題を見ましたが、解決できなかったようです。https://groups.google.com/forum/#!msg/mechanical-sympathy/qLqYTouygTE/rq9XSBxgqiMJ

しかし、tpacket_rcvの損失は疑わしいです。おそらく、これはラベルを通して関数を終了することを意味しますring_is_full。バッファオーバーフローが原因でパケットがtcpdumpに到達できないようです。しかし、これはパケットが（必ずしも）完全に廃棄されたことを意味するわけではありません。それでもUDPソケットに到達できます。これは、ドロップウォッチレコードがカウンタに表示されるUDPドロップをカバーしていないことを示します。私はAF_PACKETが両方ともデータグラムソケットなので、UDPの削除とは見なされないと思います。残念ながら、これらの内容tp_dropsは表示されないようですnetstat。

私はdropwatchを実行してtpacket_rcv行をフィルタリングしたいと思いますgrep -v。 UDP 受信エラーカウンタが増加するのを見るまで待ちます。

rmem_maxUDPの場合、アプリケーションが受信バッファを増やそうとする場合にのみ役に立つと思います。 "opensips rmem"の実際の検索結果はありません。を見てみましょうrmem_default。しかし、それが問題であれば、「受信バッファエラー」とマークされていると思います。

しかし、UDPチェックサムエラーではありません。

という別の調整可能なパラメータがありますnetdev_max_backlog。当然、対応するオーバーフローカウンタは第２の列/proc/net/softnet_stat（ＣＰＵ当たり１行）である。ただし、これはパケットがUDPスタックに供給される前に発生するため、UDP統計に影響を与えないでください。

あっ、今思い出すのはそれが全部です。ちょっと変ですね。：（。

編集する:

高いppsレートを処理するために、より小さいSIPプロキシサーバー固有のバッファサイズ設定があります。調整後、我々は良い結果を見た。滴がありますが、量は非常に少ないです。 ——サティッシュ

Answer 1