内容发布更新时间 : 2024/12/26 9:11:54星期一 下面是文章的全部内容请认真阅读。

Linux下的系统性能调优工具，第 2

部分

之前介绍了perf最常见的一些用法，关注于Linux系统上应用程序的调优。现在让我们把目光转移到内核以及其他perf命令上面来。

在内核方面，人们的兴趣五花八门，有些内核开发人员热衷于寻找整个内核中的热点代码；另一些则只关注某一个主题，比如slab分配器，对于其余部分则不感兴趣。对这些人而言，perf的一些奇怪用法更受欢迎。当然，诸如perf top，perf stat,perf record等也是内核调优的基本手段，但用法和part1所描述的一样，无需重述。

此外虽然内核事件对应用程序开发人员而言有些陌生，但一旦了解，对应用程序的调优也很有帮助。我曾经参与开发过一个数据库应用程序，其效率很低。通过常规的热点查询，IO统计等方法，我们找到了一些可以优化的地方，以至于将程序的效率提高了几倍。可惜对于拥有海量数据的用户，其运行时间依然无法达到要求。进一步调优需要更加详细的统计信息，可惜本人经验有限，实在是无计可施。从客户反馈来看，该应用的使用频率很低。作为一个程序员，为此我时常心情沮丧。

假如有perf，那么我想我可以用它来验证自己的一些猜测，比如是否太多的系统调用，或者系统中的进程切换太频繁?针对这些怀疑使用perf都可以拿出有用的报告，或许能找到问题吧。但过去的便无可弥补，时光不会倒流，无论我如何伤感，世界绝不会以我的意志为转移。所以我们好好学习perf，或许可以预防某些遗憾吧。

这里我还要提醒读者注意，讲述perf的命令和语法容易，但说明什么时候使用这些命令，或者说明怎样解决实际问题则很困难。就好象说明电子琴上88个琴键的唱名很容易，但想说明如何弹奏动听的曲子则很难。

在简述每个命令语法的同时，我试图通过一些示例来说明这些命令的使用场景，但这只能是一种微薄的努力。因此总体说来，本文只能充当那本随同电子琴一起发售的使用说明书。

回页首

使用tracepoint

当perf根据tick时间点进行采样后，人们便能够得到内核代码中的hot spot。那什么时候需要使用tracepoint来采样呢?

我想人们使用tracepoint的基本需求是对内核的运行时行为的关心，如前所述，有些内核开发人员需要专注于特定的子系统，比如内存管理模块。这便需要统计相关内核函数的运行情况。另外，内核行为对应用程序性能的影响也是不容忽视的：

以之前的遗憾为例，假如时光倒流，我想我要做的是统计该应用程序运行期间究竟发生了多少次系统调用。在哪里发生的?

下面我用ls命令来演示sys_enter这个tracepoint的使用：

[root@ovispoly/]#perf stat-e raw_syscalls：sys_enter ls bin dbg etc lib media opt root selinux sys usr boot dev home lost+found mnt proc sbin srv tmp var Performance counter stats for'ls'：101 raw_syscalls：sys_enter 0.003434730 seconds time

elapsed[root@ovispoly/]#perf record-e raw_syscalls：sys_enter ls[root@ovispoly/]#perf report Failed to open.lib/ld-2.12.so,continuing without symbols#Samples：70##Overhead Command Shared Object Symbol#....#97.14%ls ld-2.12.so[.]0x 0000000001629d 2.86%ls[vdso][.]0x 00000000421424##(For ahigher level overview,try：perf report--sort comm,dso)#

这个报告详细说明了在ls运行期间发生了多少次系统调用(上例中有101次)，多数系统调用都发生在哪些地方(97%都发生在ld-2.12.so中)。

有了这个报告，或许我能够发现更多可以调优的地方。比如函数foo()中发生了过多的系统调用，那么我就可以思考是否有办法减少其中有些不必要的系统调用。

您可能会说strace也可以做同样事情啊，的确，统计系统调用这件事完全可以用strace完成，但perf还可以干些别的，您所需要的就是修改-e选项后的字符串。

罗列tracepoint实在是不太地道，本文当然不会这么做。但学习每一个tracepoint是有意义的，类似背单词之于学习英语一样，是一项缓慢痛苦却不得不做的事情。

回页首

perf probe tracepoint是静态检查点，意思是一旦它在哪里，便一直在那里了，您想让它移动一步也是不可能的。内核代码有多少行?我不知道，100万行是至少的吧，但目前tracepoint有多少呢?我最大胆的想象是不超过1000个。所以能够动态地在想查看的地方插入动态监测点的意义是不言而喻的。

Perf并不是第一个提供这个功能的软件，systemTap早就实现了。但假若您不选择RedHat的发行版的话，安装systemTap并不是件轻松愉快的事情。perf是内核代码包的一部分，所以使用和维护都非常方便。

我使用的Linux版本为2.6.33。因此您自己做实验时命令参数有可能不同。 [root@ovispoly perftest]#perf probe schedule：12 cpu Added new event：probe：schedule(on schedule+52 with cpu)You can now use it on all perf tools,such as：perf record-e probe：schedule-a sleep 1[root@ovispoly perftest]#perf record-e probe：schedule-a sleep 1Error,output file perf.data exists,use-A to append or-f to

overwrite.[root@ovispoly perftest]#perf record-f-e probe：schedule-a sleep 1[perf record：Woken up 1times to write data][perf record：Captured and wrote 0.270 MB perf.data(~11811 samples)][root@ovispoly perftest]#perf report#Samples：40##Overhead Command Shared Object