容器中的诊断与分析2——live diagnosis——perf Linux下的内核测试工具——perf使用简介 系统级性能分析工具 — Perf linux perf - 性能测试和优化工具 goo

 

Linux下的内核测试工具——perf使用简介

系统级性能分析工具 — Perf

linux perf - 性能测试和优化工具：示例&应用

 

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

 

 介绍：

Perf是内置于Linux内核源码树中的性能剖析(profiling)工具。是Linux kernel自带的系统性能优化工具

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

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

 

优点：

与Linux Kernel的紧密结合，它能够最早应用到加入Kernel的new feature。而像OProfile, GProf等一般会“慢一拍”。

pef能够用于查看热点函数，查看cashe miss的比率，从而帮助开发者来优化程序性能。

 

运行原理：

• 性能调优工具如 perf，Oprofile 等的基本原理都是对被监测对象进行采样。是功能级和指令级热外表
  • 在CPU的PMU registers中Get/Set performance counters来得到诸如instructions executed, cache-missed suffered, branches mispredicted等信息。
  • Linux kernel对这些registers进行了一系列抽象，因此你能够按进程，按CPU或者按counter group等不一样类别来查看Sample信息。
• 最简单的情形是根据 tick 中断进行采样，即在 tick 中断内触发采样点，在采样点里判断程序当时的上下文。
  • 假如一个程序 90% 的时间都花费在函数 foo() 上，那么 90% 的采样点都应该落在函数 foo() 的上下文中。
  • 运气不可捉摸，但我想只要采样频率足够高，采样时间足够长，那么以上推论就比较可靠。
  • 所以，经过 tick 触发采样，咱们即可以了解程序中哪些地方最耗时间，从而重点分析。
• 稍微扩展一下思路，就能够发现改变采样的触发条件使得咱们能够得到不一样的统计数据：
  • 以时间点 ( 如 tick) 做为事件触发采样即可以获知程序运行时间的分布。
  • 以 cache miss 事件触发采样即可以知道 cache miss 的分布，即 cache 失效常常发生在哪些程序代码中。如此等等。
  • 使用perf list（在root权限下运行），能够列出全部的采样事件。事件分为如下三种：
    • Hardware Event 是由 PMU 硬件产生的事件，好比 cache 命中，当您须要了解程序对硬件特性的使用状况时，便须要对这些事件进行采样
    • Software Event 是内核软件产生的事件，好比进程切换，tick 数等 ;
    • Tracepoint event 是内核中的静态 tracepoint 所触发的事件，这些 tracepoint 用来判断程序运行期间内核的行为细节，好比 slab 分配器的分配次数等。
    • 上述每个事件均可以用于采样，并生成一项统计数据，时至今日，尚没有文档对每个 event 的含义进行详细解释。

 

 

CPU周期(cpu-cycles)：

是默认的性能事件，

是指CPU所能识别的最小时间单元，一般为亿分之几秒，

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

 

 

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

• perf-list：
  • 用来查看perf所支持的性能事件，有软件的也有硬件的。查看全部可用的counters
  • perf list [hw | sw | cache | tracepoint | event_glob]
    • 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以上的内核版本才支持。

    • 何时须要使用 tracepoint 来采样呢？
      • 对内核的运行时行为的关心
        • 有些内核开发人员须要专一于特定的子系统，好比内存管理模块。这便须要统计相关内核函数的运行状况。另外，内核行为对应用程序性能的影响也是不容忽视的：
        • 例如,报告详细说明了在 ls 运行期间发生了多少次系统调用 ( 上例中有 101 次 )，多数系统调用都发生在哪些地方 (97% 都发生在 ld-2.12.so 中 )。

• perf-stat：概览程序的运行状况
  • 分析指定程序的性能概况。面对一个问题程序，最好采用自顶向下的策略。先总体看看该程序运行时各类统计事件的大概，再针对某些方向深刻细节。而不要一会儿扎进琐碎细节，会一叶障目的
    • 有些程序慢是由于计算量太大，其多数时间都应该在使用CPU进行计算，这叫作CPUbound型；有些程序慢是由于过多的IO，这种时候其CPU利用率应该不高，这叫作IObound型；对于CPUbound程序的调优和IObound的调优是不一样的。
    • Perfstat应该是您最早使用的一个工具。它经过归纳精简的方式提供被调试程序运行的总体状况和汇总数据。
    • 进行调优应该要找到热点 ( 即最耗时的代码片断 )，再看看是否可以提升热点代码的效率。
  • perf stat [-e <EVENT> | --event=EVENT] [-a] - <command> [<options>]
  • task-clock：任务真正占用的处理器时间，单位为ms。CPUs utilized = task-clock / time elapsed，CPU的占用率。
    • Task-clock-msecs：CPU 利用率，该值高，说明程序的多数时间花费在 CPU 计算上而非 IO。
  • context-switches：上下文的切换次数。
  • Cache-misses：程序运行过程当中整体的 cache 利用状况，若是该值太高，说明程序的 cache 利用很差

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

  • page-faults：缺页异常的次数。当应用程序请求的页面还没有创建、请求的页面不在内存中，或者请求的页面虽然在内存中，但物理地址和虚拟地址的映射关系还没有创建时，都会触发一次缺页异常。另外TLB不命中，页面访问权限不匹配等状况也会触发缺页异常。

  • cycles：消耗的处理器周期数。若是把被ls使用的cpu cycles当作是一个处理器的，那么它的主频为2.486GHz。
    • 能够用cycles / task-clock算出。
  • instructions：执行了多少条指令。IPC为平均每一个cpu cycle执行了多少条指令。
  • branches：遇到的分支指令数。branch-misses是预测错误的分支指令数。
  • IPC：是 Instructions/Cycles 的比值，该值越大越好，说明程序充分利用了处理器的特性。
  • Cache-references: cache 命中的次数
  • Cache-misses: cache 失效的次数。
• perf-top：
  • 对于一个指定的性能事件(默认是CPU周期)，显示消耗最多的函数或指令
  • perf top [-e <EVENT> | --event=EVENT] [<options>]

  • 要用于实时分析各个函数在某个性能事件上的热度，可以快速的定位热点函数，包括应用程序函数、模块函数与内核函数，甚至可以定位到热点指令。

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

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

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

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

• perf-record：精确制导——定位程序瓶颈
  • 收集采样信息，并将其记录在数据文件中。
    • 随后能够经过其它工具(perf-report)对数据文件进行分析，结果相似于perf-top的。
  • 查找时间上的热点函数
  • 3个问题
    • perf未能定位本地符号表对应的symbol和地址的对应关系：0x000003d4对应的什么函数？
    • 采样频率不够高，失去了一些函数的信息：显然一些内核函数没有显示在上面的结果中，由于采样频率若是不够高，那么势必会有一些函数中的采样点没有/
      • 用perf record -F count 来指定采样频率
    • 如何克服采样的随机性带来的问题：为了在测量更加逼近正确值，咱们采用屡次重复取平均值的方法来逼近真实值。（这里能够用-r来指定重复次数）
• perf-report：精确制导——定位程序瓶颈
  • 读取perf ：record建立的数据文件，并给出热点分析结果。
• perf-lock
  • 内核锁的性能分析。
  • perf lock {record | report | script | info}

  • Name：内核锁的名字。

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

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

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

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

  • min wait：为了得到该锁，最小的等待时间。
• perm-kmem
  • slab分配器的性能分析。
  • perf kmem {record | stat} [<options>]

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

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

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

  • Hit：调用的次数。

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

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

  • 有使用--alloc选项，还会看到Alloc Ptr，即所分配内存的地址
• probe-sched
  • 调度模块分析。　
  • perf sched {record | latency | map | replay | script}

  • TASK：进程名和pid。

  • Runtime：实际的运行时间。

  • Switches：进程切换的次数。

  • Average delay：平均的调度延迟。

  • Maximum delay：最大的调度延迟。

  • Maximum delay at：最大调度延迟发生的时刻。
• perf-probe
  • 自定义探测点。

• 还有一些适用于较特殊场景的工具， 好比内核锁、slab分配器、调度器，也支持自定义探测点。

 

[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

 

 

 

 

 

 

 

 

 

 

 

google perftools分析程序性能

介绍

经过采样的方式，给程序中cpu的使用状况进行“画像”

• 经过它所输出的结果，咱们能够对程序中各个函数（获得函数之间的调用关系）耗时状况一目了然
• 对程序作性能优化的时候，这个是很重要的，先把最耗时的若干个操做优化好，程序的总体性能提高应该十分明显，这也是作性能优化的一个最为基本的原则—先优化最耗时的

 

下载 gperftools：https://code.google.com/p/gperftools/downloads/detail?name=gperftools-2.0.tar.gz

 

搭配组件：

安装图形化分析工具kcachegrind：

• 来分析产生的profiling文件，linux环境下使用。
• 采用kcachegrind查看函数之间依赖，并分析程序性能

查看profile结果：pprof工具

• 是一个perl的脚本，经过这个工具，能够将google-perftool的输出结果分析得更为直观，输出为图片、pdf等格式。
• 在使用pprof以前须要先安装运行per15；若是要进行图标输出则须要安装dot；若是须要--gv模式的输出则须要安装gv

 

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