1

我正在使用 async-profiler 和 perf 并决定测量DirectByteBuffer磁盘 IO 的内核活动。这是代码（用 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注意到以下结果：

  1. 异步探查器

    $~/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]

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

在此处输入图像描述

在我所做的所有跑步中，我注意到copy_user_enhanced_fast_string百分比在perf和async-profiler 61.02% vs 中是不同的77.65%

问题：为什么和copy_user_enhanced_fast_string采样？我试图提供相同的条件（频率和采样周期，并且我没有同时运行这两个分析器。31499 Hz ≈ 28169 纳秒）。perfasync-profiler

还是我对结果的解释是错误的？

4

1 回答 1

4

选择的分析间隔 (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)。这应该使测量更加可靠。

于 2018-09-21T02:15:20.597 回答