UDPプロトコルを使用するトラフィックが多い環境でopensips SIPプロキシを実行しています。時々、RXインターフェイスにバグやオーバーフローエラーが表示されることがあります。設定しましたが、rmem_max to 16Mまだエラーが表示されます。これがnetstatに表示されます。このエラーを解決する方法を知っていますか？
システムには40個のCPUと64GBのメモリがあるため、これはリソースの問題ではありません。
もう一つの点は、tcpdumpを実行し、すべてのSIPトラフィックをキャプチャすることです。tcpdumpそれがこの問題の原因だと思いますか？
ネットワーク統計 - su
Udp:
27979570 packets received
2727 packets to unknown port received.
724419 packet receive errors
41731936 packets sent
322 receive buffer errors
0 send buffer errors
InCsumErrors: 55
水滴観察-l kas
846 drops at tpacket_rcv+5f (0xffffffff815e46ff)
3 drops at tpacket_rcv+5f (0xffffffff815e46ff)
4 drops at unix_stream_connect+2ca (0xffffffff815a388a)
552 drops at tpacket_rcv+5f (0xffffffff815e46ff)
503 drops at tpacket_rcv+5f (0xffffffff815e46ff)
4 drops at unix_stream_connect+2ca (0xffffffff815a388a)
1557 drops at tpacket_rcv+5f (0xffffffff815e46ff)
6 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1203 drops at tpacket_rcv+5f (0xffffffff815e46ff)
2051 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1940 drops at tpacket_rcv+5f (0xffffffff815e46ff)
541 drops at tpacket_rcv+5f (0xffffffff815e46ff)
221 drops at tpacket_rcv+5f (0xffffffff815e46ff)
745 drops at tpacket_rcv+5f (0xffffffff815e46ff)
389 drops at tpacket_rcv+5f (0xffffffff815e46ff)
568 drops at tpacket_rcv+5f (0xffffffff815e46ff)
651 drops at tpacket_rcv+5f (0xffffffff815e46ff)
622 drops at tpacket_rcv+5f (0xffffffff815e46ff)
377 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
577 drops at tpacket_rcv+5f (0xffffffff815e46ff)
9 drops at tpacket_rcv+5f (0xffffffff815e46ff)
135 drops at tpacket_rcv+5f (0xffffffff815e46ff)
217 drops at tpacket_rcv+5f (0xffffffff815e46ff)
358 drops at tpacket_rcv+5f (0xffffffff815e46ff)
211 drops at tpacket_rcv+5f (0xffffffff815e46ff)
337 drops at tpacket_rcv+5f (0xffffffff815e46ff)
54 drops at tpacket_rcv+5f (0xffffffff815e46ff)
105 drops at tpacket_rcv+5f (0xffffffff815e46ff)
27 drops at tpacket_rcv+5f (0xffffffff815e46ff)
42 drops at tpacket_rcv+5f (0xffffffff815e46ff)
249 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1080 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1932 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1476 drops at tpacket_rcv+5f (0xffffffff815e46ff)
681 drops at tpacket_rcv+5f (0xffffffff815e46ff)
840 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1076 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1021 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
294 drops at tpacket_rcv+5f (0xffffffff815e46ff)
186 drops at tpacket_rcv+5f (0xffffffff815e46ff)
313 drops at tpacket_rcv+5f (0xffffffff815e46ff)
257 drops at tpacket_rcv+5f (0xffffffff815e46ff)
132 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
343 drops at tpacket_rcv+5f (0xffffffff815e46ff)
282 drops at tpacket_rcv+5f (0xffffffff815e46ff)
191 drops at tpacket_rcv+5f (0xffffffff815e46ff)
303 drops at tpacket_rcv+5f (0xffffffff815e46ff)
96 drops at tpacket_rcv+5f (0xffffffff815e46ff)
223 drops at tpacket_rcv+5f (0xffffffff815e46ff)
1 drops at tcp_rcv_state_process+1b0 (0xffffffff81550f70)
183 drops at tpacket_rcv+5f (0xffffffff815e46ff)
答え1
検索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プロキシサーバー固有のバッファサイズ設定があります。調整後、我々は良い結果を見た。滴がありますが、量は非常に少ないです。 ——サティッシュ