☰

UDP接收缓冲区错误

tag-icon • tag-icon linux performance udp
UDP接收缓冲区错误

我们在高流量环境中运行opensips SIP代理，它使用UDP协议。我们有时会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：它在af_packet.c. AF_PACKET表示 tcpdump。

看起来其他人看到了 tcpdump 触发的问题，但没有解决：https://groups.google.com/forum/#!msg/mechanical-sympathy/qLqYTouygTE/rq9XSBxgqiMJ

但我对 tpacket_rcv 中的丢失表示怀疑。可能这意味着通过标签退出函数ring_is_full。听起来数据包不会到达 tcpdump，因为它的缓冲区溢出。然而，我不认为这意味着数据包（必然）被完全丢弃；它仍然可以到达 UDP 套接字。这表明您的 dropwatch 记录未涵盖计数器中显示的任何 UDP 丢弃。我不认为 AF_PACKET 仅仅因为它们都是数据报套接字而被计为 UDP 丢弃。不幸的是，看起来这些tp_drops没有被显示netstat。

我想运行 dropwatch 并过滤掉 tpacket_rcv 行grep -v。只需足够长的时间即可看到 UDP 接收错误计数器的增加。

我认为rmem_max对于 UDP，只有当应用程序尝试提高接收缓冲区时才会有帮助。没有“opensips rmem”的真实搜索结果。我会尝试加注rmem_default。但我真的希望它们会显示为“接收缓冲区错误”，如果这是问题所在......

然而，它们也不是 UDP 校验和错误......

还有另一个名为 的可调参数netdev_max_backlog。显然，相应的溢出计数器是第二列/proc/net/softnet_stat（每个CPU有一行）。但这发生在数据包被馈送到 UDP 堆栈之前，因此它不应该影响 UDP 统计数据......

哎呀，这就是我现在能想到的，有点神秘:(。

编辑:

SIP 代理服务器相关缓冲区大小中有一个设置，该设置较小以处理高 pps 速率。调整后我们看到了良好的结果。掉落是有的，但是数量非常非常低。 ——萨蒂什

相关内容