[转帖]如何用Perf解开服务器消耗的困境

如何,perf,解开,服务器,消耗,困境 · 浏览次数 : 0

小编点评

**Perf：跟踪问题三板斧** **1. 了解 Perf 的功能和独特优势** * 基于时间的性能分析 * 基于事件的性能分析 * 可用于性能瓶颈的查找与热点代码的定位 **2. 使用 perf top 打头阵** * 实时显示系统/进程的性能统计信息 * 对资源的整体消耗有一个基本了解 * 对照源码做一个基本定位 **3. 使用 perf stat 来统计** * 统计程序/线程的性能概况 * 了解 CPU 迁移次数、上下文切换次数、内存缺页数量等 * 查找性能瓶颈的根源 **4. 使用 FlameGraph 生成火焰图** * 显示程序运行过程中的调用关系 * 直观高效地判断谁消耗了您的服务器资源 * 找到性能瓶颈的根源

正文

https://rdc.hundsun.com/portal/article/637.html

无论是网站还是软件产品，服务器作为资源池，其重要性不言而喻。监控并了解服务器资源的消耗情况更是能将众多问题防范于未然，也许，一般的监控对于业内人基本不是问题，那让我们聊聊秘密武器Perf，你也许会有恍然大悟的感受。

【困境：是谁消耗了珍贵的资源】

案发现场是我们测试环境的一台服务器，程序的一个触发式任务，在某次版本更新后用了正常情况两倍的时间都没有完成，按照套路《Linux Performance Analysis in 60,000 Milliseconds》一路top,iostat,dstat等，没有发现任何常规意义的异常。

但系统资源都不缺，性能上不去，很可能的问题是单线程瓶颈和锁的问题，于是 top -H -p pid一把，果然单线程CPU 100%，如下图。

于是习惯性的strace进去发现了一个熟悉的身影syscall:futex,有什么东西是单线程处理并且还拿着锁…… pstack 之后也没有得到什么有用的信息，此时，Perf就适时闪亮登场了。

【Perf：跟踪问题三板斧】

Perf 是内置于Linux内核源码树中的性能剖析（profiling）工具。基于事件采样原理，以性能事件为基础，支持针对处理器相关性能指标与操作系统相关性能指标的性能剖析。可用于性能瓶颈的查找与热点代码的定位。
▲Perf主要的用途在以下2个方面：

基于时间的性能分析

基于事件的性能分析

针对时间无关的性能指标（哪个函数/指令触发了最多的Cache missing 哪个程序使用的系统调用数最多等）；性能计数器（ISR记录当前进程的采样信息：PC，PID，TID 性能计数器累积到一定数值（采样周期）时触发中断）；热点进程热点函数热点指令。

perf help

除此之外，Perf 还可以跟踪的性能事件非常全面，归结后可分为以下三种：
▪ Hardware Event 是由 PMU 硬件产生的事件，比如 cache 命中，当您需要了解程序对硬件特性的使用情况时，便需要对这些事件进行采样；
▪ Software Event 是内核软件产生的事件，比如进程切换，tick 数等 ;
▪ Tracepoint event 是内核中的静态 tracepoint 所触发的事件，这些 tracepoint 用来判断程序运行期间内核的行为细节，比如 slab 分配器的分配次数等。

我们只要了解下面这些常用就基本能判断问题了↓↓

【实战：打破困境直达核心】

了解perf的功能和独特优势之后，让我们一起回归到本文开篇的情境中，让Perf施展一下自己拳脚吧。

（1）perf top打头阵–实时显示系统/进程的性能统计信息

先用 perf top看看CPU实时热点情况，对资源的整体消耗有一个基本了解，并对照源码做一个基本定位。

选择 Annotate，找出热点（可以精确到 CPU 指令):

从跟踪情况可以看到CPU主要消耗在，MOV ，CMP，SETB，RETQ 等指令上面，而尤其CMP和RETQ指令在链表功能中使用时资源耗费最多，基于该处的怀疑，我们用 Perf stat 来对程序/线程进行分析。

（2） perf stat来统计–用于分析指定程序/线程的性能概况

▲perf stat 输出解读如下

▪ task-clock

用于执行程序的CPU时间，单位是ms(毫秒)。第二列中的CPU utillized则是指这个进程在运行perf的这段时间内的CPU利用率，该数值是由task-clock除以最后一行的time elapsed再除以1000得出的。

▪ context-switches

进程切换次数，记录了程序运行过程中发生了多少次进程切换，应该避免频繁的进程切换。

▪ cpu-migrations

程序在运行过程中发生的CPU迁移次数，即被调度器从一个CPU转移到另外一个CPU上运行。

▪ page-faults

缺页。指当内存访问时先根据进程虚拟地址空间中的虚拟地址通过MMU查找该内存页在物理内存的映射，没有找到该映射，则发生缺页，然后通过CPU中断调用处理函数，从物理内存中读取。

▪ Cycles

处理器时钟，一条机器指令可能需要多个 cycles。

▪ Cache-references

cache 命中的次数。

▪ Cache-misses

cache 失效的次数。

▪ L1-dcache-load-missed

一级数据缓存读取失败次数。

▪ L1-dcache-loads

一级数据缓存读取次数。

从 Perf stat 输出数据可以看到CPU的迁移次数较多，程序上下文切换比较频繁，Cache命中率不是很理想，内存缺页也比较多，对照源码定位到本次问题是因为为保证数据一致性在获取数据时增加了CRC码校验过程，只有当CRC码校验正确的情况下才进行后续工作，该处单线程处理，且有锁操作，导致程序频繁上下文切换、内存缺页严重。

当问题已经被准确找到，你会发现修改过程其实并不困难。下面我们再将解放方案做的更完善一下，对跟踪数据进行图形化，让大家更直观的体会一下程序。

（3） FlameGraph来出图
首先我们用 perf record 获取基础数据，perf record 命令主要是用来记录一段时间内系统/进程的性能事件，如下：

我们首先执行 perf record -a -g -p ‘PID’ --sleep 60 来收集数据，其次我们用 perf script 调用扩展脚本生成可跟踪信息。

总的来说，perf script 可以用来做以下两件事情：
• 查看perf的数据文件（perf.data）
• 执行基于python/perl的扩展功能(需要python环境)

我们执行FlameGraph的扩展脚本perf script |FlameGraph-master/stackcollapse-perf.pl

最后用 FlameGraph 生成火焰图，Flame Graph是Brendan Gregg开发的一个小工具能够将perf等剖析工具采到的call stack数据转换为svg图执行** FlameGraph-master/flamegraph.pl > flame-h5.svg** 生成火焰图

结果如下：

通过此图，相信你能够直观高效地判断出到底是谁消耗了您珍贵的服务器资源，找准根源，困境将不攻自破。

【彩蛋：学无止境】

除了Perf外，还有 SystemTap，google-perftools，DTrace 我这里统称性能跟踪优化四大帅），如果您能熟练掌握各个工具的特点及使用方法，那么90%的性能问题在您这里将不再是问题。
1. SystemTap
systemtap 是利用Kprobe 提供的API来实现动态地监控和跟踪运行中的Linux内核的工具,相比Kprobe，systemtap更加简单，提供给用户简单的命令行接口，以及编写内核指令的脚本语言。
Systemtap 工作原理是通过将脚本语句翻译成C语句，编译成内核模块。模块加载之后，将所有探测的事件以钩子的方式挂到内核上，当任何处理器上的某个事件发生时，相应钩子上句柄就会被执行。最后，当systemtap会话结束之后，钩子从内核上取下，移除模块。
2. google-perftools
google-perftools 是一款针对 C/C++ 程序的性能分析工具，使用该工具可以对 CPU 时间片、内存使用情况进行“画像”，通过它所输出的结果，我们可以对程序中各个函数（得到函数之间的调用关系）耗时情况一目了然.最后可以生成类似下面的gif图片，够清晰炫酷吧。
3. DTrace

DTrace（全称Dynamic Tracing)，也称为动态跟踪，是由 Sun™ 开发的一个用来在生产和试验性生产系统上找出系统瓶颈的工具，可以对内核(kernel)和用户应用程序(user application)进行动态跟踪并且对系统运行不构成任何危险的技术。在任何情况下它都不是一个调试工具，而是一个实时系统分析寻找出性能及其他问题的工具。 DTrace 是个特别好的分析工具，带有大量的帮助诊断系统问题的特性。还可以使用预先写好的脚本利用它的功能。用户也可以通过使用 DTrace D 语言创建他们自己定制的分析工具，以满足特定的需求。