【问题标题】：Optimizing incoming UDP broadcast in Linux在 Linux 中优化传入的 UDP 广播
【发布时间】：2015-04-13 05:58:01
【问题描述】：
环境
- Linux/红帽
- 6 核
- Java 7/8
- 10G
应用程序
- 它是一款低延迟高频交易应用程序
- 通过多播 UDP 接收广播
- 有多个数据流
- 每个传入数据包大小小于 1K（固定大小）
- 应用程序延迟约为 4 微秒
架构
- 单独的应用程序线程映射到每个传入的多播流
- 在本机中使用 multicastsocket.receive() 从套接字接收数据
字节
- 解析字节并准备订单
问题
尽管可容忍的应用延迟约为 4 微秒，但我们无法获得理想的性能。我们认为这是因为网络延迟。
使用的调整步骤
- 增加了以下参数的大小：
- netdev_max_backlog
- NIC 环形缓冲区接收大小
- rmem_max
- tcp_mem
- socketreceivebuffer（在代码中）
问题：
- 我们观察到，在我们增加上述参数的值后，应用程序的性能会下降。要优化的建议参数和推荐值是什么。是否需要优化传入广播的指南？
- 有没有办法在这样的环境中以更准确的方式测量网络延迟。请注意，UDP 发送方是外部实体（交换）
提前致谢
【问题讨论】：
标签：
performance
linux-kernel
udp
low-latency
hft
【解决方案1】：
尚不清楚您测量的内容和方式。
你提到你正在接收 UDP，你为什么要调整 TCP 缓冲区大小？
一般来说，增加传入套接字缓冲区的大小可能会帮助您解决慢速接收器上的数据包丢失问题，但不会减少延迟。
您可能想了解更多关于bufferbloat的信息：
Bufferbloat 是分组交换网络中的一种现象，其中数据包的过度缓冲会导致高延迟和数据包延迟变化（也称为抖动），以及降低整体网络吞吐量。当路由器设备配置为使用过大的缓冲区时，即使是非常高速的网络也可能无法用于语音通话、聊天甚至网上冲浪等许多交互式应用程序。
您还可以将 Java 用于低延迟应用程序。人们通常无法使用 Java 实现这种延迟。垃圾收集器是主要原因之一。详情请见Quantifying the Performance
of Garbage Collection vs. Explicit Memory Management：
比较运行时、空间消耗和虚拟内存占用
在一系列基准测试中，我们展示了运行时性能
性能最好的垃圾收集器与显式垃圾收集器竞争
给定足够内存时的内存管理。特别是，
当垃圾收集的内存是原来的五倍时
根据需要，其运行时性能匹配或略高于
显式内存管理。但是，垃圾收集的
当它必须使用更小的性能时，性能会大大降低
堆。内存是原来的三倍，它的运行速度要慢 17%
平均，并且内存是两倍，它的运行速度要慢 70%。垃圾
收集也更容易受到物理分页的影响
内存稀缺。在这种情况下，所有的垃圾收集器
我们在这里检查遭受数量级的性能损失
相对于显式内存管理。
使用 Java 进行 HFT 的人通常会完全关闭垃圾收集并每天重新启动系统。