perfreord可以运行一个命令，但更多的是对已运行的进程进行性能剖析，并将剖析结果输出到perf.data(默认该文件名)中。不会像perfTOP一样实时输出剖析结果。输出perf.data可以通过perfreport进行剖析，或者通过perfscript输出结果给第三方输出可视化的视图。用前面的示例代码进行测试如下：

$perfrecord-g-F99./a.out $perfreport

Brendangregg写了两款对perf采样结果进行可视化剖析的开源工具：FlameGraphs和HeatMap.FlameGraphs即所谓的火焰图，是大伙用比较多的工具，能明确的展示程序各个函数的性能消耗。HeatMap可以从采样数据中的延迟数据来进行消耗展示。

源:http://walkerdu.com/2018/09/13/perf-event/

它可以借助CPUperformancecounters(性能计数器)，tracepoints,kprobes和uprobes来进行应用程序的性能剖析。perf用这部分linux内核提供的tracing特质进行事件的采集和剖析，perf用的event主要有以下几种：

HardwareEvents:CPU中的寄存器含有performancecounters(性能计数器)，用来统计Hardwareevent，比如cpu-cycles、instructionsexecuted、cache-misses、branchmispredicted等。这部分event构成了应用程序profiling的基础。 SoftwareEvents:基于内核计数器的低优先级events，比如,CPUmigrations(处置器迁移次数),minorfaults(softpagefaults),majorfaults(hardpagefaults). Tracepoints:是散落在内核源码中的一些hook，用来调用probe函数，开启后，它们便可以在特定的代码被运行到时被触发，这一特质可以被各种trace/debug工具所用。Perf就是该特质的用户之一。倘若你想了解在应用程序运行期间，内核内存管理模块的行为，便可以借助潜伏在slab分配器中的tracepoint。当内核运行到这部分tracepoint时，便会公告perf。 DynamicTracing：probe函数(探针or探测函数)，kprobe(kernelprobe)内核态探针，用来创建和管理内核代码中的探测点。Uprobes，user-probe，用户态探针，用来对用户态应用程序进行探测点的创建和管理，关于kprobe和uprobe可参考对应的内核文档 perf用的event出处，如下图：出处：brendangregg

3.安装

火焰图的用

https://blog.csdn.net/luckyApple1028/article/details/52972315

TOP对系统的性能进行剖析，种类TOP命令，当然可以对单个进程进行剖析

archive依据perf.data(由perfrecord生成)文件中的build-id将有关的目的文件打包，便捷在其他机器剖析

buildid-cache管理build-id,管理对于的bin文件

http://cwndmiao.github.io/programming%20tools/2013/11/26/Dwarf/

subcommand功能说明

perfTOP类似系统的命令TOP，可以实时的查询目前系统各个进程的各个函数的性能计数剖析：$sudoperfTOP

kmem剖析内核内存的用kvm剖析

Perf官方wiki

https://github.com/brendangregg/FlameGraph

具体各个字段包含的意思在perflist中已经列出了，这里剖析一下要紧的数据：

task-clock(msec):cpu处置task所消耗的时间，单位ms，0.808CPUsutilized的表示cpu用率为80.8%=2.164836/2.679758.该值越高代表程序是CPUbound而非IObound种类。 instructions：实行的指令条数，insnspercycle:即IPC，每一个cpu周期实行的指令条数，1.11=6100570(instructions)/5506056(cycles),IPC比上面的CPU用率更能说明CPU的用状况，关于IPC有一篇brendangregg的文章，非常不错的说明CPU用率不是一个非常不错的性能剖析指标 stalled-cycles-frontend和stalled-cycles-backend表示CPU停滞统计，具体可参考

Perf–Linux下的系统性能调优工具，第1部分

perfTOP的和perfrecord的功能参数差不多，大家可以加上-e：来统计特定的event，-g:开启call-graph,-p：剖析特定的进程

Linux内核调试技术——kprobe用与达成

evlist列出perf.data中采集的事件列表

http://www.brendangregg.com/perf.html

report读取perf.data(由perfrecord生成)并显示剖析结果

比如上面代码正常不开启优化的编译，进行profile是可以看到callgraph的，如下：

http://www.brendangregg.com/flamegraphs.html

没framepointer会使perf没办法获得完整的调用栈，如下示例：

lock剖析内核中的锁信息，包括锁的争用状况，等待延迟等

如下是perfreport剖析sshd进程的堆栈调用状况(来自brendangregg)：

Linux效能剖析工具:Perf

Perf维基百科

5.5.perf可视化剖析

Perf可以解决高级性能和问题排除，它可以剖析(当然现在我也只不过用来进行cpu性能剖析)：

为何内核消耗CPU高,代码的地方在哪儿？ 什么代码引起了CPU2级cache未命中？ CPU是不是消耗在内存I/O上？ 哪些代码分配内存，分配了多少？ 什么触发了TCP重传？ 某个内核函数是不是正在被调用，调用频率多少？ 线程释放CPU是什么原因？

2.perf的event

stat对程序运行过程中的性能计数器进行统计

应用程序的符号表，用来将逻辑地址翻译成对应的函数和变量名，如此才能被技术员阅读和剖析，没符号表，profile的结果都是一些16进制的逻辑地址：

perfExamples

perf是一款linux内置的性能剖析工具，伴随内核发布，也被叫做perf_events,perftools,PCL(PerformanceCountersforLinux),发布于Linuxkernelversion2.6.31,perf是如何工作的呢？perf怎么用？本文是来介绍一下。

有三种办法可以修复这个问题，这里不做展开，这部分stackwalkingtechniques后面可以写一篇单独的文章：

usingdwarfdatatounwindthestack,事实上不少profile工具：gperftools,valgrind都是依靠于libunwind,通过dwarf来进行stacktrace的 usinglastbranchrecord(LBR)ifavailable(aprocessorfeature) returningtheframepointers

5.用

perf_flamegraph.png

6.参考

perf官方wiki的介绍是：Linuxprofilingwithperformancecounters

record对程序运行过程中的事件进行剖析和记录，并写入perf.data

list列出目前系统支持的所有事件名,可分为三类：硬件事件、软件事件，检查点

testperf对目前软硬件平台进行完善性测试，可用此工具测试目前的软硬件平台是不是能支持perf的所有功能。

perf提供了一系列的命令来剖析程序，如下：

这部分事件可以分为三类(在文章开始介绍perf工作原理的时候也说了):HardwareEvent,Softwareevent,Tracepointevent.

两种安装方法

通过包管理进行安装，perf工具在linux-tools-common工具包里，通过包管理系统安装的时候还需要依靠linux-tools-kernelversion包 网站源码编译：找到对应内核版本的网站源码包，在tools/perf目录下进行编译

4.背景

script读取perf.data(由perfrecord生成)，生成trace记录，供其他剖析工具用

要想用perf来剖析应用程序，需要知道一些基础定义，比如符号表,framepointer等信息

页错误

下面是对之前实例代码的采样数据perf.data进行FlameGraphs的绘制：

$perfscript|./stackcollapse-perf.pl|./flamegraph.pl>fg_output.svg

平时大家用的更多的是perfrecord，由于它可以将profiler的结果输出到文件，然后通过perfreport来进行剖析，或者通过可视化工具进行剖析和输出。所以下面着重介绍perfrecord

kvm虚拟机上的guestos

perfrecord几个总要参数说明一下：

-F:事件采样的频率,单位HZ,更高的频率会获得更细的统计，但会带来更多的开销 -g:进行堆栈追踪，生成调用关系图，等价于–call-graph，默认状况下，-g等同于–call-graphfp，即通过framepointer来进行堆栈追踪。假如framepointer被优化掉的话，可以通过dwarf,lbr进行堆栈追踪 sleep:采样的时间

annotate读取perf.data(由perfrecord生成)显示注释信息，假如被剖析的进程含义debug符号信息，则会显示汇编和对应的网站源码，不然只显示汇编代码

timechart对record结果进行可视化剖析输出，record命令需要加上timechart记录

大家常常在编译的时候会开启framepointers优化选项，即优化掉函数栈帧rbp，省略掉framepointer是编译器一个非常烂的优化，它会破坏debug,更烂的是省略framepointer通常是编译器默认的优化选项。

https://www.ibm.com/developerworks/cn/linux/l-cn-perf1/index.html

probe用于概念动态检查点。

perflist命令可以列出目前perf可用的事件：

cpu-cyclesORcycles[Hardwareevent] instructions[Hardwareevent] cache-references[Hardwareevent] cache-misses[Hardwareevent] branch-instructionsORbranches[Hardwareevent] branch-misses[Hardwareevent] bus-cycles[Hardwareevent] stalled-cycles-frontendORidle-cycles-frontend[Hardwareevent] stalled-cycles-backendORidle-cycles-backend[Hardwareevent] ref-cycles[Hardwareevent] alignment-faults[Softwareevent] bpf-output[Softwareevent] context-switchesORcs[Softwareevent] cpu-clock[Softwareevent] cpu-migrationsORmigrations[Softwareevent] dummy[Softwareevent] emulation-faults[Softwareevent] major-faults[Softwareevent] minor-faults[Softwareevent] page-faultsORfaults[Softwareevent] task-clock[Softwareevent] msr/tsc/[KernelPMUevent] rNNN[Rawhardwareeventdescriptor] cpu/t1=v1[,t2=v2,t3...]/modifier[Rawhardwareeventdescriptor] (see'manperf-list'onhowtoencodeit) mem:<addr>[/len][:access][Hardwarebreakpoint]

4.1符号表

5.4.perfrecord

perfstat可以加上-e选项来设置自己关心的事件统计，具体参数可以通过上面的perflist来查询

data把perf.data文件转换成其他格式diff读取多个perf.data文件，并给出差异剖析

sched针对调度器子系统的剖析工具。

每一个具体事件包含的意思在perf_event_open的manpage中有说明：

cpu-cycles：统计cpu周期数，cpu周期：指一条指令的操作时间。 instructions：机器指令数目 cache-references：cache命中次数 cache-misses：cache失效次数 branch-instructions：分支预测成功次数 branch-misses：分支预测失败次数 alignment-faults：统计内存对齐错误发生的次数，当访问的非对齐的内存地址时，内核会进行处置，已保存不会发生问题，但会减少性能 context-switches：上下文切换次数， cpu-clock：cpuclock的统计，每一个cpu都有一个高精度定时器 task-clock：cpuclock中有task运行的统计 cpu-migrations：进程运行过程中从一个cpu迁移到另一cpu的次数 page-faults：页错误的统计 major-faults：页错误，内存页已经被swap到硬盘上，需要I/O换回 minor-faults：页错误，内存页在物理内存中，只不过没和逻辑页进行映射

http://wiki.csie.ncku.edu.tw/embedded/perf-tutorial

trace像strace，跟踪目的的系统调用，但开销比strace小

perf提供了内置的可视化剖析工具perftimechart，比如：

$perftimechartrecord./a.out $perftimechart

5.3.perfTOP

内核uprobes用介绍

https://blog.csdn.net/badu_123/article/details/8302642

https://en.wikipedia.org/wiki/Perf_(Linux)

5.2.perfstat

perf的用大体可以有三种方法：

Counting：统计的方法，统计事件发生的次数，这种方法不生成perf.data文件，比如perfstat,perfTOP Sampling:采样的方法，采样事件，并写入到内核buffer中，并异步写入perf.data文件中，perf.data文件可以被perfreport或者perfscript命令读取。 bpfprogramsonevents(https://www.ibm.com/developerworks/cn/linux/l-lo-eBPF-history/index.html)

对于通过软件包安装的程序，一般都会有dubugpackage(-dbgsym)即带有符号表信息的程序，若是网站源码安装的就需要编译时开启debug选项。

perfstat可以对程序运行过程中的性能计数器(包括Hardware，softwarecounters)进行统计，剖析程序的整体消耗状况：

$perfstatls Performancecounterstatsfor'ls': 2.164836task-clock(msec)#0.808CPUsutilized 51context-switches#0.024M/sec 4cpu-migrations#0.002M/sec 333page-faults#0.154M/sec 5506056#2.543GHz 0stalled-cycles-frontend#0.00%frontendcyclesidle 0stalled-cycles-backend#0.00%backendcyclesidle 6100570instructions#1.11insnspercycle 1298744branches#599.927M/sec 18509branch-misses#1.43%ofallbranches 0.002679758secondstimeelapsed

https://perf.wiki.kernel.org/index.php/Main_Page

作为服务器后台开发，不只要写业务逻辑，后台意味着高并发，稳定性，当你写了不少逻辑，发现性能有问题的时候，也要掌握性能剖析，进行性能优化,或许你会接触不少性能剖析工具：valgrind，gperftools，gprof,oprofile,有空闲慢慢一一介绍，在学习perf的过程中，也学习和加深了不少之前的常识，本文抛砖引玉，期望能帮大伙知道一些性能剖析更深的一些东西。

1.perf简介

通过用openssh-server-dbgsymandlibc6-dbgsym，sshd的perfreport剖析结果如下：

benchperf提供的基准套件的通用框架，可以对目前系统的调度，IPC，内存访问进行性能评估

4.2栈回溯(栈展开)

假如编译时开启-fomit-frame-pointer(这里由于测试代码容易，直接开优化的话就优化没了)，就没办法获得到callgraph

5.1.perflist

buildid-list列出perf.data中的所以buildids

https://yq.aliyun.com/articles/55820

perftimechart输出的是进程运行过程中系统调度的状况，没办法对程序的具体代码段进行性能剖析，但可以看出概要运行状况：running，idle，I/O等，