2

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

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

我猜这可能是网络问题，例如阻止读取？当我尝试使用忙等待进行非阻塞读取时，我得到了类似的结果，但也许我做错了。我不知道这些打嗝是从哪里来的。

4

2 回答 2

2

IRQ Balance 将在您的 CPU 上分配中断处理。你可以关闭它或控制它的掩码，这样你就不会被打断（不幸的是有两个你不能关闭的中断）

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

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

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

于 2012-04-24T09:07:49.557 回答
0

这是一个非常有趣的问题，也是一个不寻常的 jHiccup 配置文件。在一家大银行工作，我通常会看到复杂应用程序的多模态 jHiccup 曲线——你似乎有一条路径，你的 20% 到 99.999% 的交易采用单一路径。这很了不起，很多人都喜欢效仿（尽管他们可能希望 57usec 小得多）。造成这种情况的原因有很多，通过找到一个可以改变 57usec 数字的变量来平分问题可能是最有效的 - CPU 频率、NIC 延迟、上下文切换成本、同步写入成本、线程调度公平性。

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

  1. 分析 - 我对您的“按百分比分布的打嗝”曲线的平坦程度感到震惊，并且它延伸到 90% 以下，这表明存在一个非常常见的大约 57 微秒的暂停事件。如果您减小存储桶大小和水平轴会发生什么 - 您是否看到暂停是均匀分布、正常分布、二项分布还是周期性分布？你用的是10GB吗？您的应用程序是否在工作负载和上下文切换之间显示出非常恒定的相关性（高于 0.85 r-squared）？

  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，看看是否会发生任何变化。

让我们知道会发生什么，

彼得

于 2014-12-12T13:26:45.993 回答