背景知识

有些背景知识是分析性能问题时需要了解的。比如硬件 cache；再比如操作系统内核。应用程序的行为细节往往是和这些东西互相牵扯的，这些底层的东西会以意想不到的方式影响应用程序的性能，比如某些程序无法充分利用 cache，从而导致性能下降。比如不必要地调用过多的系统调用，造成频繁的内核 / 用户切换。等等。方方面面，这里只是为本文的后续内容做一些铺垫，关于调优还有很多东西，我所不知道的比知道的要多的多。

性能相关的处理器硬件特性，PMU 简介

当算法已经优化，代码不断精简，人们调到最后，便需要斤斤计较了。cache 啊，流水线啊一类平时不大注意的东西也必须精打细算了。

硬件特性之 cache

内存读写是很快的，但还是无法和处理器的指令执行速度相比。为了从内存中读取指令和数据，处理器需要等待，用处理器的时间来衡量，这种等待非常漫长。Cache 是一种 SRAM，它的读写速率非常快，能和处理器处理速度相匹配。因此将常用的数据保存在 cache 中，处理器便无须等待，从而提高性能。Cache 的尺寸一般都很小，充分利用 cache 是软件调优非常重要的部分。

硬件特性之流水线，超标量体系结构，乱序执行

提高性能最有效的方式之一就是并行。处理器在硬件设计时也尽可能地并行，比如流水线，超标量体系结构以及乱序执行。

处理器处理一条指令需要分多个步骤完成，比如先取指令，然后完成运算，最后将计算结果输出到总线上。在处理器内部，这可以看作一个三级流水线，如下图所示：

图 1. 处理器流水线

指令从左边进入处理器，上图中的流水线有三级，一个时钟周期内可以同时处理三条指令，分别被流水线的不同部分处理。

超标量（superscalar）指一个时钟周期发射多条指令的流水线机器架构，比如 Intel 的 Pentium 处理器，内部有两个执行单元，在一个时钟周期内允许执行两条指令。

此外，在处理器内部，不同指令所需要的处理步骤和时钟周期是不同的，如果严格按照程序的执行顺序执行，那么就无法充分利用处理器的流水线。因此指令有可能被乱序执行。

上述三种并行技术对所执行的指令有一个基本要求，即相邻的指令相互没有依赖关系。假如某条指令需要依赖前面一条指令的执行结果数据，那么 pipeline 便失去作用，因为第二条指令必须等待第一条指令完成。因此好的软件必须尽量避免这种代码的生成。

硬件特性之分支预测

分支指令对软件性能有比较大的影响。尤其是当处理器采用流水线设计之后，假设流水线有三级，当前进入流水的第一条指令为分支指令。假设处理器顺序读取指令，那么如果分支的结果是跳转到其他指令，那么被处理器流水线预取的后续两条指令都将被放弃，从而影响性能。为此，很多处理器都提供了分支预测功能，根据同一条指令的历史执行记录进行预测，读取最可能的下一条指令，而并非顺序读取指令。

分支预测对软件结构有一些要求，对于重复性的分支指令序列，分支预测硬件能得到较好的预测结果，而对于类似 switch case 一类的程序结构，则往往无法得到理想的预测结果。

上面介绍的几种处理器特性对软件的性能有很大的影响，然而依赖时钟进行定期采样的 profiler 模式无法揭示程序对这些处理器硬件特性的使用情况。处理器厂商针对这种情况，在硬件中加入了 PMU 单元，即 performance monitor unit。

PMU 允许软件针对某种硬件事件设置 counter，此后处理器便开始统计该事件的发生次数，当发生的次数超过 counter 内设置的值后，便产生中断。比如 cache miss 达到某个值后，PMU 便能产生相应的中断。

捕获这些中断，便可以考察程序对这些硬件特性的利用效率了。

Tracepoints

Tracepoint 是散落在内核源代码中的一些 hook，一旦使能，它们便可以在特定的代码被运行到时被触发，这一特性可以被各种 trace/debug 工具所使用。Perf 就是该特性的用户之一。

假如您想知道在应用程序运行期间，内核内存管理模块的行为，便可以利用潜伏在 slab 分配器中的 tracepoint。当内核运行到这些 tracepoint 时，便会通知 perf。

Perf 将 tracepoint 产生的事件记录下来，生成报告，通过分析这些报告，调优人员便可以了解程序运行时期内核的种种细节，对性能症状作出更准确的诊断。

从2.6.31内核开始，Linux内核自带了一个性能分析工具perf，能够进行函数级与指令级的热点查找。

 

perf

 

Performance analysis tools for linux.

Performance counters for Linux are a new kernel-based subsystem that provide a framework for all things

performance analysis. It covers hardware level (CPU/PMU, Performance Monitoring Unit) features and

software features (software counters, tracepoints) as well.

 

Perf是内置于Linux内核源码树中的性能剖析(profiling)工具。

它基于事件采样原理，以性能事件为基础，支持针对处理器相关性能指标与操作系统相关性能指标的性能剖析。

常用于性能瓶颈的查找与热点代码的定位。

 

CPU周期(cpu-cycles)是默认的性能事件，所谓的CPU周期是指CPU所能识别的最小时间单元，通常为亿分之几秒，

是CPU执行最简单的指令时所需要的时间，例如读取寄存器中的内容，也叫做clock tick。

 

Perf是一个包含22种子工具的工具集，以下是最常用的5种：

perf-list

perf-stat

perf-top

perf-record

perf-report

 

perf-list

 

Perf-list用来查看perf所支持的性能事件，有软件的也有硬件的。

 

List all symbolic event types.

perf list [hw | sw | cache | tracepoint | event_glob]

 

(1) 性能事件的分布

hw：Hardware event，9个

sw：Software event，9个

cache：Hardware cache event，26个

tracepoint：Tracepoint event，775个

 

sw实际上是内核的计数器，与硬件无关。

hw和cache是CPU架构相关的，依赖于具体硬件。

tracepoint是基于内核的ftrace，主线2.6.3x以上的内核版本才支持。

 

(2) 指定性能事件(以它的属性)

-e <event> : u // userspace

-e <event> : k // kernel

-e <event> : h // hypervisor

-e <event> : G // guest counting (in KVM guests)

-e <event> : H // host counting (not in KVM guests)

 

(3) 使用例子

显示内核和模块中，消耗最多CPU周期的函数：

# perf top -e cycles:k

显示分配高速缓存最多的函数：

# perf top -e kmem:kmem_cache_alloc

 

perf-top

 

对于一个指定的性能事件(默认是CPU周期)，显示消耗最多的函数或指令。

 

System profiling tool.

Generates and displays a performance counter profile in real time.

perf top [-e <EVENT> | --event=EVENT] [<options>]

 

perf top主要用于实时分析各个函数在某个性能事件上的热度，能够快速的定位热点函数，包括应用程序函数、

模块函数与内核函数，甚至能够定位到热点指令。默认的性能事件为cpu cycles。

 

(1) 输出格式

# perf top

第一列：符号引发的性能事件的比例，默认指占用的cpu周期比例。

第二列：符号所在的DSO(Dynamic Shared Object)，可以是应用程序、内核、动态链接库、模块。

第三列：DSO的类型。[.]表示此符号属于用户态的ELF文件，包括可执行文件与动态链接库)。[k]表述此符号属于内核或模块。

第四列：符号名。有些符号不能解析为函数名，只能用地址表示。

 

(2) 常用交互命令

h：显示帮助

UP/DOWN/PGUP/PGDN/SPACE：上下和翻页。

a：annotate current symbol，注解当前符号。能够给出汇编语言的注解，给出各条指令的采样率。

d：过滤掉所有不属于此DSO的符号。非常方便查看同一类别的符号。

P：将当前信息保存到perf.hist.N中。

 

(3) 常用命令行参数

-e <event>：指明要分析的性能事件。

-p <pid>：Profile events on existing Process ID (comma sperated list). 仅分析目标进程及其创建的线程。

-k <path>：Path to vmlinux. Required for annotation functionality. 带符号表的内核映像所在的路径。

-K：不显示属于内核或模块的符号。

-U：不显示属于用户态程序的符号。

-d <n>：界面的刷新周期，默认为2s，因为perf top默认每2s从mmap的内存区域读取一次性能数据。

-G：得到函数的调用关系图。

perf top -G [fractal]，路径概率为相对值，加起来为100%，调用顺序为从下往上。

perf top -G graph，路径概率为绝对值，加起来为该函数的热度。

 

(4) 使用例子

# perf top // 默认配置

# perf top -G // 得到调用关系图

# perf top -e cycles // 指定性能事件

# perf top -p 23015,32476 // 查看这两个进程的cpu cycles使用情况

# perf top -s comm,pid,symbol // 显示调用symbol的进程名和进程号

# perf top --comms nginx,top // 仅显示属于指定进程的符号

# perf top --symbols kfree // 仅显示指定的符号

 

perf-stat

 

用于分析指定程序的性能概况。

 

Run a command and gather performance counter statistics.

perf stat [-e <EVENT> | --event=EVENT] [-a] <command>

perf stat [-e <EVENT> | --event=EVENT] [-a] - <command> [<options>]

 

(1) 输出格式

# perf stat ls

 

输出包括ls的执行时间，以及10个性能事件的统计。

task-clock：任务真正占用的处理器时间，单位为ms。CPUs utilized = task-clock / time elapsed，CPU的占用率。

context-switches：上下文的切换次数。

CPU-migrations：处理器迁移次数。Linux为了维持多个处理器的负载均衡，在特定条件下会将某个任务从一个CPU

迁移到另一个CPU。

page-faults：缺页异常的次数。当应用程序请求的页面尚未建立、请求的页面不在内存中，或者请求的页面虽然在内

存中，但物理地址和虚拟地址的映射关系尚未建立时，都会触发一次缺页异常。另外TLB不命中，页面访问权限不匹配

等情况也会触发缺页异常。

cycles：消耗的处理器周期数。如果把被ls使用的cpu cycles看成是一个处理器的，那么它的主频为2.486GHz。

可以用cycles / task-clock算出。

stalled-cycles-frontend：略过。

stalled-cycles-backend：略过。

instructions：执行了多少条指令。IPC为平均每个cpu cycle执行了多少条指令。

branches：遇到的分支指令数。branch-misses是预测错误的分支指令数。

 

(2) 常用参数

-p：stat events on existing process id (comma separated list). 仅分析目标进程及其创建的线程。

-a：system-wide collection from all CPUs. 从所有CPU上收集性能数据。

-r：repeat command and print average + stddev (max: 100). 重复执行命令求平均。

-C：Count only on the list of CPUs provided (comma separated list), 从指定CPU上收集性能数据。

-v：be more verbose (show counter open errors, etc), 显示更多性能数据。

-n：null run - don't start any counters，只显示任务的执行时间 。

-x SEP：指定输出列的分隔符。

-o file：指定输出文件，--append指定追加模式。

--pre <cmd>：执行目标程序前先执行的程序。

--post <cmd>：执行目标程序后再执行的程序。

 

(3) 使用例子

执行10次程序，给出标准偏差与期望的比值：

# perf stat -r 10 ls > /dev/null

显示更详细的信息：

# perf stat -v ls > /dev/null

只显示任务执行时间，不显示性能计数器：

# perf stat -n ls > /dev/null

单独给出每个CPU上的信息：

# perf stat -a -A ls > /dev/null

ls命令执行了多少次系统调用：

# perf stat -e syscalls:sys_enter ls 

 

perf-record

 

收集采样信息，并将其记录在数据文件中。

随后可以通过其它工具(perf-report)对数据文件进行分析，结果类似于perf-top的。

 

Run a command and record its profile into perf.data.

This command runs a command and gathers a performance counter profile from it, into perf.data,

without displaying anything. This file can then be inspected later on, using perf report.

 

(1) 常用参数

-e：Select the PMU event.

-a：System-wide collection from all CPUs.

-p：Record events on existing process ID (comma separated list).

-A：Append to the output file to do incremental profiling.

 -f：Overwrite existing data file.

-o：Output file name.

-g：Do call-graph (stack chain/backtrace) recording.

-C：Collect samples only on the list of CPUs provided.

 

(2) 使用例子

记录nginx进程的性能数据：

# perf record -p `pgrep -d ',' nginx`

记录执行ls时的性能数据：

# perf record ls -g

记录执行ls时的系统调用，可以知道哪些系统调用最频繁：

# perf record -e syscalls:sys_enter ls

 

perf-report

 

读取perf record创建的数据文件，并给出热点分析结果。

 

Read perf.data (created by perf record) and display the profile.

This command displays the performance counter profile information recorded via perf record.

 

(1) 常用参数

-i：Input file name. (default: perf.data)

 

(2) 使用例子

# perf report -i perf.data.2

 

More

 

除了以上5个常用工具外，还有一些适用于较特殊场景的工具， 比如内核锁、slab分配器、调度器，

也支持自定义探测点。

 

perf-lock

 

内核锁的性能分析。

Analyze lock events.

perf lock {record | report | script | info}

 

需要编译选项的支持：CONFIG_LOCKDEP、CONFIG_LOCK_STAT。

CONFIG_LOCKDEP defines acquired and release events.

CONFIG_LOCK_STAT defines contended and acquired lock events.

 

(1) 常用选项

-i <file>：输入文件

-k <value>：sorting key，默认为acquired，还可以按contended、wait_total、wait_max和wait_min来排序。

 

(2) 使用例子

# perf lock record ls // 记录

# perf lock report // 报告

 

(3) 输出格式

 

Name：内核锁的名字。

aquired：该锁被直接获得的次数，因为没有其它内核路径占用该锁，此时不用等待。

contended：该锁等待后获得的次数，此时被其它内核路径占用，需要等待。

total wait：为了获得该锁，总共的等待时间。

max wait：为了获得该锁，最大的等待时间。

min wait：为了获得该锁，最小的等待时间。

最后还有一个Summary：

 

perf-kmem

 

slab分配器的性能分析。

Tool to trace/measure kernel memory(slab) properties.

perf kmem {record | stat} [<options>]

 

(1) 常用选项

--i <file>：输入文件

--caller：show per-callsite statistics，显示内核中调用kmalloc和kfree的地方。

--alloc：show per-allocation statistics，显示分配的内存地址。

-l <num>：print n lines only，只显示num行。

-s <key[,key2...]>：sort the output (default: frag,hit,bytes)

 

(2) 使用例子

# perf kmem record ls // 记录

# perf kmem stat --caller --alloc -l 20 // 报告

 

(3) 输出格式

Callsite：内核代码中调用kmalloc和kfree的地方。

Total_alloc/Per：总共分配的内存大小，平均每次分配的内存大小。

Total_req/Per：总共请求的内存大小，平均每次请求的内存大小。

Hit：调用的次数。

Ping-pong：kmalloc和kfree不被同一个CPU执行时的次数，这会导致cache效率降低。

Frag：碎片所占的百分比，碎片 = 分配的内存 - 请求的内存，这部分是浪费的。

有使用--alloc选项，还会看到Alloc Ptr，即所分配内存的地址。

最后还有一个Summary：

 

probe-sched

 

调度模块分析。

trace/measure scheduler properties (latencies)

perf sched {record | latency | map | replay | script}

 

(1) 使用例子 

# perf sched record sleep 10 // perf sched record <command>

# perf report latency --sort max

 

(2) 输出格式

TASK：进程名和pid。

Runtime：实际的运行时间。

Switches：进程切换的次数。

Average delay：平均的调度延迟。

Maximum delay：最大的调度延迟。

Maximum delay at：最大调度延迟发生的时刻。

 

perf-probe

 

可以自定义探测点。

Define new dynamic tracepoints.

 

使用例子

(1) Display which lines in schedule() can be probed

# perf probe --line schedule

前面有行号的可以探测，没有行号的就不行了。

 

(2) Add a probe on schedule() function 12th line.

# perf probe -a schedule:12

在schedule函数的12处增加一个探测点。

 

Reference

 

[1]. Linux的系统级性能剖析工具系列，by 承刚

[2]. http://www.ibm.com/developerworks/cn/linux/l-cn-perf1/

[3]. http://www.ibm.com/developerworks/cn/linux/l-cn-perf2/

[4]. https://perf.wiki.kernel.org/index.php/Tutorial