Sat*_*ish 2 linux performance udp
我们在高流量环境中运行 opensips SIP 代理，它使用 UDP 协议。我们RX在界面上看到有时错误或溢出错误。我已经设置，rmem_max to 16M但仍然看到错误，这就是我在 netstat 中看到的。知道如何解决这个错误吗？
我们系统上有 40 个 CPU 和 64GB 内存，所以这不是资源问题。
还有一件事，我们在其上运行 tcpdump 并捕获所有 SIP 流量。你认为tcpdump会导致这个问题吗？
netstat -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
Dropwatch -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)
查找tpacket_rcv：它在af_packet.c. AF_PACKET表示 tcpdump。
貌似别人看到了tcpdump触发的问题，没有解决： https rq9XSBxgqiMJ
但我对 tpacket_rcv 中的下降持怀疑态度。可能这意味着函数通过 label 退出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 统计......
Whelp，这就是我现在能想到的，它有点神秘:(。
编辑：
在 SIP 代理服务器相关的缓冲区大小中有一个设置，该大小很小以处理高 pps 速率。调整后，我们看到了良好的结果。有掉落，但数量非常少。– 萨蒂什