【问题标题】:How to use linux `perf` tool to generate "Off-CPU" profile如何使用 linux `perf` 工具生成“Off-CPU”配置文件
【发布时间】:2014-05-30 15:49:48
【问题描述】:

Brendan D. Gregg(DTrace 书籍的作者)有一个有趣的分析变体:"Off-CPU" profiling(和 Off-CPU Flame Graphslides 2013, p112-137)查看线程或应用程序被阻塞的位置(未被 CPU 执行,但正在等待 I/O、页面错误处理程序或因 CPU 资源不足而取消调度):

这一次揭示了哪些代码路径在 CPU 关闭时被阻塞和等待,以及确切的等待时间。这与传统的分析不同,后者通常以给定的时间间隔对线程的活动进行采样,并且(通常)仅在线程在 CPU 上执行工作时才检查它们。

他还可以将 Off-CPU profile 数据和 On-CPU profile 结合在一起:http://www.brendangregg.com/FlameGraphs/hotcoldflamegraphs.html

Gregg 给出的示例是使用dtrace 制作的,这在 Linux 操作系统中通常不可用。但是有一些类似的工具(ktap、systemtap、perf)和perf,因为我认为拥有最广泛的安装基础。通常perf 会生成 On-CPU 配置文件(这些函数在 CPU 上执行的频率更高)。

  • 如何将 Gregg 的 Off-CPU 示例转换为 Linux 中的perf 分析工具?

PS:slides from LISA13, p124 中有指向 Off-CPU 火焰图的 systemtap 变体的链接:“Yichun Zhang 创建了这些,并一直在 Linux 上通过 SystemTap 使用它们来收集配置文件数据。请参阅: • @ 987654326@""(CloudFlare 啤酒会议,2013 年 8 月 23 日)

【问题讨论】:

标签: linux profiling wait perf


【解决方案1】:

我发布的 perf 技术 [1] 是一种高开销的解决方法,直到 perf 支持 BPF 才能做到这一点。

目前,在 Linux 上生成 CPU 外火焰图的成本最低的方法是在 4.6+ 内核(支持 BPF 堆栈跟踪)和 bcc/BPF 上。我为它编写了一个工具,offcputime[2],它可以使用“折叠输出”的 -f 选项运行,适合输入到 flamegraph.pl。这个 offcputime 工具在内核内容中进行计时和堆栈计数,并转储一个报告,然后用符号打印。

有一天,我希望 perf 本身也能够做到这一点:运行一个 BPF 程序来进行内核计数和转储报告。

与此同时,我们可以使用 bcc/BPF。如果由于某种原因您不能使用 bcc,您现在可以使用该 offcputime 程序并用 C 编写它。Linux 源代码中提供了更复杂的版本,如 samples/bpf/offwaketime*。借助 Linux 上的新 BPF 功能,只要有意愿,就有办法。

[1]http://www.brendangregg.com/blog/2015-02-26/linux-perf-off-cpu-flame-graph.html

[2]https://github.com/iovisor/bcc/blob/master/tools/offcputime_example.txt

【讨论】:

    【解决方案2】:

    Brendan Gregg 发表了关于 Off-cpu 火焰图生成的说明: http://www.brendangregg.com/blog/2015-02-26/linux-perf-off-cpu-flame-graph.htmlhttps://github.com/brendangregg/FlameGraph/issues/47#

    非 CPU 时间火焰图可以解决(比如说)60% 的问题,其余的则需要遍历线程唤醒以找到根本原因。我在关于火焰图的 LISA13 演讲(slidesyoutube)中解释了非 CPU 时间火焰图、这个唤醒问题和其他工作。

    在这里,我将展示一种使用 Linux perf_events 绘制非 CPU 时间火焰图的方法。

    # perf record -e sched:sched_stat_sleep -e sched:sched_switch \
     -e sched:sched_process_exit -a -g -o perf.data.raw sleep 1
    # perf inject -v -s -i perf.data.raw -o perf.data
    # perf script -f comm,pid,tid,cpu,time,period,event,ip,sym,dso,trace | awk '
    NF > 4 { exec = $1; period_ms = int($5 / 1000000) }
    NF > 1 && NF <= 4 && period_ms > 0 { print $2 }
    NF < 2 && period_ms > 0 { printf "%s\n%d\n\n", exec, period_ms }' | \
    ./stackcollapse.pl | \
    ./flamegraph.pl --countname=ms --title="Off-CPU Time Flame Graph" --colors=io > offcpu.svg
    

    使用 Gregg 的 stackcollapse.pl 和 flamegraph.pl 绘制火焰图。

    从 3.17 内核和更新的内核开始使用 perf 选项...

    【讨论】:

    • 不要被漂亮的像素、热情的挥手或新的流行语(如 on-and off-CPU)所吸引。如果您不只是“分析性能”,而是积极寻求最大性能,那么您必须找到试图向您隐藏的“瓶颈”,它们很容易隐藏在火焰图中。检查here
    • Mike,是否有许多现代分析器可以提供“来自墙上时间样本”的配置文件?您认为随机堆栈采样是现代(或唯一正确的)分析技术吗?
    • 我的意思是 1) 如果加速可以节省 X 部分时间,那么曝光两次所需的平均样本数是 2/X,而不是数千。 (Gregg 举了一个 2000 倍的例子,节省了 X=0.9995 的时间 - 两个甚至一个 样本都可以搞定。) 2)如果取数千个并总结(如在火焰图或任何其他摘要)丢失了准确告诉您加速是什么的洞察力,您不能错过任何。 3) 可能有更好的方法 - 让我们看看它是什么。
    • 数以百万计的程序员可能会感染一个有害的想法,即发现加速需要大量样本,总结。这个想法没有理论基础或实践基础。它伤害他们的方式是总结掩盖实际加速,根本找不到。有些人没有那么受人群影响,比如Jon Bentley, slide 35Agner Fog, page 18,以及那些投票给this的人。
    • Dunlavey,我认为这里所谓的“Off-CPU”可能很有用,它将使性能更接近您的“wall time”分析,而不是传统的gprof/perf record “cpu 时间”分析。 PS:你有没有你的 sigplan 2007 的在线副本dl.acm.org/citation.cfm?id=1294298 PPS:如何将en.wikipedia.org/wiki/Deep_sampling 的文章扩展为方法的介绍,并添加一些外部资源(不是来自你的论文)?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-10-25
    • 1970-01-01
    • 1970-01-01
    • 2021-04-11
    相关资源
    最近更新 更多