我使用的perf
是 linux-2.6.36-gentoo-r4。设置/proc/sys/kernel/perf_event_paranoid
为 0,因此应该不会有问题。
由于我正在分析的长时间运行的应用程序有时会因某些不确定的原因而崩溃(我无法找到有关其停止工作的原因的信息),因此我转向使用性能事件进行系统范围的分析。
相关应用程序使用 MPI(消息传递接口)进行通信,进行并行数值计算。在运行应用程序之前(使用mpirun
),我已开始在以下位置记录系统范围的配置文件数据:一运行它的节点数:
$ perf record -o perf.all.cycles,graph.data -g -e cycles -a &
当我意识到应用程序崩溃后,我就终止了该perf
任务。
它已经离开了
$ du -sh perf.all.cycles,graph.data
14G perf.all.cycles,graph.data
14GB 数据。可惜perf report
不支持-a
切换。
如何通过perf
工具分析系统范围的分析数据?
2011.08.12 添加
简单地运行perf report
不会产生有用的输出:
$ perf report -i perf.all.cycles,graph.data
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
这是 14GB 配置文件数据的全部输出......
答案1
如果您使用 MPI 分发计算,那么使用 MPI 感知工具将为您提供更明智的结果:对于分布式应用程序,您可能会遇到负载不平衡的问题,其中一个 MPI 进程处于空闲状态,等待来自其他进程的数据。如果您碰巧正在准确地分析该 MPI 流程,那么您的性能分析将完全错误。
因此,第一步通常是了解程序的通信和负载平衡模式,并确定可为您提供所需工作负载的示例输入(例如,等级 0 上的 CPU 密集型)例如, 米普是一个 MPI 分析工具,可以生成有关通信模式、每个 MPI 调用花费的时间等的非常完整的报告。
然后,您可以在一个或多个选定的 MPI 等级上运行代码分析工具。无论如何,perf
在单个 MPI 等级上使用可能不是一个好主意,因为它的测量还将包含 MPI 库代码的性能,这可能不是您想要的。
答案2
perf report
不需要-a
交换机报告结果perf record -a
。您只需输入perf report
.
也就是说,分析 14G 的分析数据来跟踪崩溃似乎很奇怪。附加一个调试器怎么样?