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

Question

我正在使用 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、同步，它是单线程的。

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

Answer 1

IRQ Balance 将在您的 CPU 上分配中断处理。您可以关闭它或控制它的掩码，这样您就不会被打扰太多(不幸的是，有两个中断您无法关闭)

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

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

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