使用 async-profiler 和 perf 测量 DirectByteBuffer

Question

我正在使用 async-profiler 和 perf，并决定针对 DirectByteBuffer 磁盘 IO 测量内核 activity。这是代码（用 Scala 编写，但其 Java 版本应该很明显）：

val path = Paths.get("/tmp/test")

val buffer = ByteBuffer.allocateDirect(4096 * 4096)

def main(args: Array[String]): Unit = {
  var fullReadsCount = 0
  while (true) {
    var bytesRead = 0
    var ch: SeekableByteChannel = null
    try {
      ch = Files.newByteChannel(path)
      while (bytesRead >= 0) {
        bytesRead = ch.read(buffer)
        buffer.clear()
      }
    } finally {
      if (ch != null)
        ch.close()
    }
    fullReadsCount += 1
    if(fullReadsCount % 100 == 0) println(fullReadsCount)
  }
}

我运行多次执行此代码并执行了 perf 和 async-profiler 并注意到以下结果：

异步分析器

$~/profiler.sh -i 28169 -d 30 <pid>
 //.... stack traces ommited
     ns  percent  samples  top

264788732   61.02%     9317  copy_user_enhanced_fast_string_[k]
 41510919    9.57%     1467  generic_file_read_iter_[k]
  9333863    2.15%      331  find_get_entry_[k]
  4181131    0.96%      148  __radix_tree_lookup_[k]
  4057194    0.94%      143  copy_page_to_iter_[k]
  1860485    0.43%       63  __d_lookup_rcu_[k]
  1610407    0.37%       50  _raw_spin_unlock_irqrestore_[k]

性能sudo perf record -F 31499 -g -p <pid> -- sleep 30

平均在所有运行中，我注意到 copy_user_enhanced_fast_string 百分比在 perf 和 async-profiler 61.02% 与 77.65% 中不同

问题： 为什么 perf 和 [=14= 采样的 copy_user_enhanced_fast_string 的百分比不同]？我试图提供相同的条件（频率和采样周期，但我没有运行模拟两个分析器。31499 Hz ≈ 28169 纳秒）。

还是我对结果的解读有误？

Answer 1

所选的分析间隔 (28 μs) 太短。
检查 dmesg - 可能有像

这样的内核警告

perf interrupt took too long (18047 > 18000), lowering kernel.perf_event_max_sample_rate to 25000

async-profiler与perf的区别在于处理PMU事件的机制。 perf 仅在环形缓冲区中收集样本，而 async-profiler 向进程发送信号以调用特定于应用程序的回调。通常对用户来说没有明显的区别，但是当分析频率太高时，信号可能会引入额外的噪声并影响进程调度。

我建议将分析间隔增加到至少 100 μs (10000 Hz)。这应该会使测量更加可靠。

使用 async-profiler 和 perf 测量 DirectByteBuffer

Measuring DirectByteBuffer with async-profiler and perf

java

linux

jvm

perf

async-profiler