1

环境

  • Linux/红帽
  • 6核
  • 爪哇 7/8
  • 10G

应用

  • 它是一个低延迟的高频交易应用程序
  • 通过多播 UDP 接收广播
  • 有多个数据流
  • 每个传入数据包大小小于 1K（固定大小）
  • 应用程序延迟约为 4 微秒

建筑学

  • 单独的应用程序线程映射到每个传入的多播流
  • 使用本机字节中的 multicastsocket.receive() 从套接字接收数据
  • 解析字节并准备好订单

问题

尽管可容忍的应用程序延迟约为 4 微秒，但我们无法获得理想的性能。我们认为这是因为网络延迟。

使用的调整步骤

  • 增加了以下参数的大小：
  • netdev_max_backlog
  • NIC 环形缓冲区接收大小
  • rmem_max
  • tcp_mem
  • socketreceivebuffer（在代码中）

问题：

  1. 我们观察到，在我们增加上述参数的值后，应用程序的性能会下降。建议优化的参数和推荐值是什么。请求优化传入广播的指南？
  2. 有没有办法在这样的环境中以更准确的方式测量网络延迟。请注意，UDP 发送方是外部实体（交换）

提前致谢

4

1 回答 1

1

目前尚不清楚您测量什么以及如何测量。

您提到您正在接收 UDP，为什么要调整 TCP 缓冲区大小？

通常，增加传入套接字缓冲区的大小可能会帮助您解决慢速接收器上的数据包丢失问题，但不会减少延迟。

您可能想了解有关bufferbloat的更多信息：

Bufferbloat 是分组交换网络中的一种现象，其中数据包的过度缓冲会导致高延迟和数据包延迟变化（也称为抖动），并降低整体网络吞吐量。当路由器设备被配置为使用过大的缓冲区时，即使是非常高速的网络也可能实际上无法用于许多交互式应用程序，例如语音通话、聊天，甚至是网上冲浪。

您还可以将 Java 用于低延迟应用程序。人们通常无法使用 Java 实现这种延迟。垃圾收集器是主要原因之一。有关更多详细信息，请参阅量化垃圾收集与显式内存管理的性能：

在一系列基准测试中比较运行时、空间消耗和虚拟内存占用，我们表明，在给定足够内存时，性能最佳的垃圾收集器的运行时性能与显式内存管理相比具有竞争力。特别是， 当垃圾收集的内存是所需内存的五倍时，其运行时性能与显式内存管理相当或略高于显式内存管理. 但是，当垃圾收集必须使用较小的堆时，它的性能会大大降低。如果内存是原来的三倍，它的运行速度平均会慢 17%，如果内存是原来的两倍，它的运行速度会慢 70%。当物理内存稀缺时，垃圾收集也更容易受到分页的影响。在这种情况下，我们在这里检查的所有垃圾收集器都会遭受相对于显式内存管理而言数量级的性能损失。

使用 Java 进行 HFT 的人通常会完全关闭垃圾收集并每天重新启动他们的系统。

于 2015-02-12T16:06:28.997 回答