UDP内核丢弃UDP数据包

概述我有一个服务器通过多播发送UDP数据包和许多客户端列出这些多播数据包. 每个数据包的固定大小为1040字节,服务器发送的整个数据大小为3GByte. 我的环境如下： 1 Gbit以太网 40个节点,1个发送者节点和39个接收器节点. 所有节点都具有相同的硬件配置：2个AMD CPU,每个CPU有2个核心@ 2,6GHz 在客户端,一个线程读取套接字并将数据放入队列.一个额外的线程d出队列中的数据并 我有一个服务器通过多播发送UDP数据包和许多客户端列出这些多播数据包.
每个数据包的固定大小为1040字节,服务器发送的整个数据大小为3GByte.

我的环境如下：

1 Gbit以太网

40个节点,1个发送者节点和39个接收器节点.
所有节点都具有相同的硬件配置：2个AMD cpu,每个cpu有2个核心@ 2,6GHz

在客户端,一个线程读取套接字并将数据放入队列.一个额外的线程d出队列中的数据并进行一些轻量级处理.

在多播传输期间,我在节点侧识别出丢包率为30％.通过观察netstat -su统计数据,我可以说,客户端应用程序丢失的数据包等于netstat输出的RcvbufErrors值.

这意味着 *** 作系统会丢弃所有丢失的数据包,因为套接字缓冲区已满,但我不明白为什么捕获线程无法及时读取缓冲区.
在传输过程中,4个核心中的2个被75％使用,其余的正在睡觉.
我是唯一使用这些节点的人,我认为这种机器在处理1Gbit带宽方面没有问题.我已经做了一些优化,通过为amd cpus添加g编译器标志,这会将丢包率降低到10％,但在我看来它仍然太高了.

当然我知道UDP不可靠,我有自己的校正协议.

我没有任何管理权限,因此我无法更改系统参数.

任何提示如何提高性能？

编辑：
我通过使用2个读取套接字的线程解决了这个问题. recv套接字缓冲区有时仍会变满.但平均跌幅低于1％,所以处理它不是问题.

解决方法 跟踪 Linux上的网络丢失可能有点困难,因为有许多组件可能会发生丢包.它们可以在硬件级别,网络设备子系统或协议层中发生.

我写了一篇非常detailed blog post的文章,解释了如何监控和调整每个组件.由于有许多不同的组件需要监控和调整,因此在这里总结一下这个简洁的答案有点难.

总结

以上是内存溢出为你收集整理的UDP内核丢弃UDP数据包全部内容，希望文章能够帮你解决UDP内核丢弃UDP数据包所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。