分析jHiccup延迟。 57us打嗝的来源

Question

我正在使用Azul Systems构建的jHiccup工具测量“打嗝”。它收集数据以确定JVM运行Java应用程序时发生的暂停时间（打嗝）的频率和持续时间。它适用于JVM级别以及更高级别（OS，驱动程序等）。

以下是结果 这些结果是在具有SUSE SLERT 11 2.6.33内核PREEMPT RT，Intel i5,4g内存的机器上获得的。该过程在cpu屏蔽（3个逻辑处理器被隔离）和99个优先级（FIFO）下运行。我想知道这57毫秒的延迟来自哪里。该应用程序非常简单。它是网络订单处理系统，因此它解析TCP数据包，执行简单的业务逻辑等等。没有GC，同步，它是单线程的。

我的猜测可能是网络问题，例如阻止阅读？当我尝试使用忙碌等待的非阻塞读取时，我得到了类似的结果，但也许我做错了。我不清楚这些打嗝可能来自何处。

Answer 1

IRQ Balance将在您的cpu中分发中断处理。你可以关闭它或控制它的面具，这样你就不会被打断（不幸的是有两个中断你无法关闭）

同一核心上的逻辑进程可能会相互干扰。为了获得最佳效果，我会隔离一个核心并且只使用它。

即使您屏蔽了应用程序，它也有很多线程。为了获得最佳结果，我使用linux来隔离多个内核，并仅将关键线程分配给这些内核。即同一应用程序中的其他线程根本不使用这些核心。

为了控制这个，我编写了这个库Java Thread Affinity即使使用这个库，我也会看到一些抖动（尽管少了多达10倍），这可能是由电源管理或本地定时器中断引起的。

Answer 2

这是一个非常有趣的问题，它也是一个不同寻常的jHiccup档案。在一家大银行工作，我通常会看到复杂应用程序的多模式jHiccup曲线 - 您似乎只有一条路径可以达到20％到99.999％的交易量。这非同寻常，很多人都喜欢效仿（尽管他们可能希望57usec更小）。有很多事情可能导致这种情况，通过找到一个可以改变57usec数字的变量 - CPU频率，NIC延迟，上下文切换成本，同步写入成本，线程调度公平性，可能最有效的方法。

你可以做很多事情来深入挖掘：

1. 分析 - 我很惊讶你的百分比与百分比的分布是多么平淡＆＃34;曲线是，并且它延伸到90％以下，这表明存在大约57微秒的单个非常常见的暂停事件。如果减小铲斗尺寸和水平轴会发生什么 - 您是否看到暂停是均匀的，正常的，二项的还是周期性的？ 你使用的是10GB吗？您的应用是否在工作负载和上下文切换之间显示非常恒定的相关性（高于0.85 r平方）？

2. 您可以尝试调整几个旋钮，看看57micro暂停的大小是否会发生变化。 请记住，这不是为了改进其调整以查看针向任一方向移动。你说禁用irq_balancer没有帮助 - 它是否会导致暂停的大小变化？ 我开始测试CPU频率是否会影响它。如果您使用的是E5-2690，您是否在E5-2650上看到相同或不同的延迟？如果您没有多种硬件，可以尝试通过更改max cset / turbo设置来实现此目的。我还尝试调整NIC上的IRQ合并设置，以便更改网络操作的NIC批处理的桶大小。如果两者都没有导致针移动，那么您就知道它不是简单的NIC延迟或CPU效应。

同样，我也尝试在具有RHEL 5内存屏障错误，更快的上下文切换和不同进程调度公平行为的旧内核上运行。像https://github.com/tsuna/contextswitch这样的工具可以表征这些东西。一旦你确定了一个可以改变你停顿的57微幅度的变量，你就会有75％的变化。

如果您当前正在使用Oracle JVM，那么您也可以尝试使用Zing，并查看是否会发生任何变化。

让我们知道会发生什么，

彼得