容器里的进程归根结底都是运行在宿主机上的进程，所以宿主机一旦出现性能问题，它上面寄生的所有的容器的性能都会受到影响。
比如当宿主机内核从ubuntu 18.04（linux内核4.15）升级到ubuntu20.04(linux内核5.4)之后，你会发现该宿主机上的容器磁盘io读写性能降低为ubuntu 18.04内核的1/8左右。因为容器里的“操作系统”只有一个rootfs，没有bootfs，同一个宿主机上的多个容器，大家是共享宿主机内核的，所以一旦宿主机内核有问题，会直接影响到容器。
当出现I/O性能问题时，为了能够及时准确地定位到问题，可以使用fio来测试一下宿主机或容器内的I/O性能，或者使用perf+flameGraph来制作火焰图来进一步分析性能问题
篇幅过长，详见：https://egonlin.com/?p=250
perf是一款Linux性能分析工具。
我们可以使用perf工具来捕获一个任务在系统中的完整调度栈信息，或者系统整体的情况，以便分许到底是哪个环节拖慢了整体的性能。
例如:
如果我们发现CPU的使用率突然暴涨，如何迅速定位是哪个进程、哪段代码引起的呢？此时就可以用perf工具，来对CPU上执行的代码进行采样、统计，告诉我们CPU到底在忙些什么。
首先我们用以下命令模拟出CPU利用率暴涨的现象：
$ cat /dev/zero > /dev/null
然后我们看到 CPU 1 的 %system 飙升到95%：
| |
| 08:21:16 PM CPU %user %nice %system %iowait %steal %idle |
| 08:21:18 PM all 2.25 0.00 48.25 0.00 0.00 49.50 |
| 08:21:18 PM 0 0.50 0.00 1.00 0.00 0.00 98.51 |
| 08:21:18 PM 1 4.02 0.00 95.98 0.00 0.00 0.00 |
现在我们用 perf 工具采样：
| 安装 |
| yum install perf -y |
| |
| perf record -a -e cycles -o cycle.perf -g sleep 10 |
| |
| |
| perf record代表记录一段时间内系统/进程的性能时间 |
| 参数： |
| -a：分析整个系统的性能 |
| -e：选择性能事件 |
| -o：指定输出文件，默认为perf.data |
| -g：记录函数间的调用关系 |
| sleep 10 表示收集10秒钟。 |
把采样的数据生成报告：
| |
| |
| ... |
| |
| |
| |
| |
| |
| |
| 75.65% cat [kernel.kallsyms] [k] __clear_user |
| | |
| |
| | |
| | |
| | vfs_read |
| | sys_read |
| | system_call_fastpath |
| | __GI___libc_read |
| |
| |
| 2.34% cat [kernel.kallsyms] [k] system_call |
| | |
| |
| | |
| | |
| | |
| |
| ... |
| 我们很清楚地看到，CPU利用率有75%来自 cat 进程 的 sys_read 系统调用， |
| perf 甚至精确地告诉了我们是消耗在 read_zero 这个 kernel routine 上。 |
| |
| 性能事件是指在处理器或操作系统中发生的，可能影响到程序性能的硬件事件或软件事件 |
| 利用perf剖析程序性能时，需要指定当前测试的性能事件。 |
| |
| 我们可以用perf list查看当前系统支持的性能事件 |
| |
| 查看图片包含了软件事件与硬件事件： |
| https://egonlin.com/wp-content/uploads/2022/08/3-2.png |
| sw实际上是内核的计数器，与硬件无关。 |
| hw和cache是CPU架构相关的，依赖于具体硬件。 |
| tracepoint是基于内核的ftrace，主线2.6.3x以上的内核版本才支持。 |
| |
| 主要用于实时分析各个函数在某个性能事件上的热度，能够快速的定位热点函数，包括应用程序函数、 |
| |
| 常用参数 |
| |
| -e：指定性能事件，默认的性能事件为cpu cycles。 |
| |
| -a：显示在所有CPU上的性能统计信息 |
| |
| -C：显示在指定CPU上的性能统计信息 |
| |
| -p：指定进程PID |
| |
| -t：指定线程TID |
| |
| -K：隐藏内核统计信息 |
| |
| -U：隐藏用户空间的统计信息 |
| |
| -s：指定待解析的符号信息 |
| |
| ‘‐G’ or‘‐‐call‐graph’ <output_type,min_percent,call_order> |
| |
| graph: 使用调用树，将每条调用路径进一步折叠。这种显示方式更加直观。 |
| |
| 每条调用路径的采样率为绝对值。也就是该条路径占整个采样域的比率。 |
| |
| fractal |
| |
| 默认选项。类似与 graph，但是每条路径前的采样率为相对值。 |
| |
| flat |
| |
| 不折叠各条调用 |
| |
| 选项 call_order 用以设定调用图谱的显示顺序，该选项有 2个取值，分别是 |
| |
| callee 与caller。 |
| |
| 将该选项设为callee 时，perf按照被调用的顺序显示调用图谱，上层函数被下层函数所调用。 |
| |
| 该选项被设为caller 时，按照调用顺序显示调用图谱，即上层函数调用了下层函数路径，也不显示每条调用路径的采样率 |
| 注： Perf top需要root权限 |
| |
| 列名 含义 |
| Overhead 符号引发的性能事件比例 |
| Shared Object 符号所在的DSO(Dynamic Shared Object)，可以是应用程序、内核、动态链接库、模块。 |
| Symbol 符号名，前面的 [ ] 表示DSO类型，[.]表示此符号属于用户态的ELF文件，包括可执行文件与动态链接库，[k]表述此符号属于内核或模块 |
| |
| |
| 分析系统/进程的整体性能概况 |
| |
| task‐clock事件表示目标任务真正占用处理器的时间，单位是毫秒。也称任务执行时间 |
| |
| context-switches是系统发生上下文切换的次数 |
| |
| CPU-migrations是任务从一个处理器迁往另外一个处理器的次数 |
| |
| page-faults是内核发生缺页的次数 |
| |
| cycles是程序消耗的处理器周期数 |
| |
| instructions是指命令执行期间产生的处理器指令数 |
| |
| branches是指程序在执行期间遇到的分支指令数。 |
| |
| branch‐misses是预测错误的分支指令数。 |
| |
| XXX seconds time elapsed系程序持续时间 |
| |
| 任务执行时间/任务持续时间大于1，那可以肯定是多核引起的 |
| |
| 参数设置： |
| |
| -e：选择性能事件 |
| |
| -i：禁止子任务继承父任务的性能计数器。 |
| |
| -r：重复执行 n 次目标程序，并给出性能指标在n 次执行中的变化范围。 |
| |
| -n：仅输出目标程序的执行时间，而不开启任何性能计数器。 |
| |
| -a：指定全部cpu |
| |
| -C：指定某个cpu |
| |
| -A：将给出每个处理器上相应的信息。 |
| |
| -p：指定待分析的进程id |
| |
| -t：指定待分析的线程id |
| |
| |
| perf record收集一段时间内系统/进程的性能时间，并记录在文件中，可以离线分析。可以使用 perf report解析收集的采样数据文件。 |
| 参数： |
| |
| -e：选择性能事件 |
| |
| -p：待分析进程的id |
| |
| -t：待分析线程的id |
| |
| -a：分析整个系统的性能 |
| |
| -C：只采集指定CPU数据 |
| |
| -c：事件的采样周期 |
| |
| -o：指定输出文件，默认为perf.data |
| |
| -A：以append的方式写输出文件 |
| |
| -f：以OverWrite的方式写输出文件 |
| |
| -g：记录函数间的调用关系 |
| -F：控制perf命令对cpu的占用频率，底层控制的是内核参数perf_event_max_sample_rate |
| 详细解析： |
| 在/proc/sys/kernel/下有两个跟perf相关的内核参数 |
| （1）perf_cpu_time_max_percent perf分析工具最大能够占用CPU性能的百分比 |
| 0：不限制 |
| 1~100：百分比值 |
| （2）perf_event_max_sample_rate： 设置perf_event的最大取样速率，默认值为100000 |
| |
| perf命令采样时会占用cpu，需要对perf命令对cpu的占比进行限制， |
| 默认限制最大就是perf_cpu_time_max_percent=25，超过该值就会触发告警如下 |
| perf: interrupt took too long (3136 > 3126), lowering kernel.perf_event_max_sample_rate to 63000 |
| 触发告警的同时会调整采样速率perf_event_max_sample_rate，保持不要超过限制。 |
| 也就是说，如果你设置了perf_event_max_sample_rate， |
| 那么出现上面这个告警后，perf_event_max_sample_rate的值会被调整。 |
| 可以通过调高perf_cpu_time_max_percent来解决。 |
| 如果调高也不能解决，就设置为0，此时就不会在去监控cpu的占用率了。 |
| echo 0 > /proc/sys/kernel/perf_cpu_time_max_percent |
| echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate |
| |
| |
| perf report 主要用来展示上面perf record生成的perf.data文件。 |
| |
| 参数 |
| |
| -i：输入的数据文件 |
| |
| -v：显示每个符号的地址 |
| |
| -d <dos>：只显示指定dos的符号 |
| |
| -C：只显示指定comm的信息（Comm. 触发事件的进程名） |
| |
| -S：只考虑指定符号 |
| |
| -U：只显示已解析的符号 |
| |
| -g[type,min,order]：显示调用关系，具体等同于perf top命令中的-g |
| |
| -c：只显示指定cpu采样信息 |
| |
| -M：以指定汇编指令风格显示 |
| |
| –source：以汇编和source的形式进行显示 |
| |
| -p<regex>：用指定正则表达式过滤调用函数 |
举例1
| |
| |
| |
| |
| |
| |
| Samples: 1M of event 'cycles', Event count (approx.): 73891391490 |
| 5.44% perf [.] 0x0000000000023256 |
| 4.86% [kernel] [k] _spin_lock |
| 2.43% [kernel] [k] _spin_lock_bh |
| 2.29% [kernel] [k] _spin_lock_irqsave |
| 1.77% [kernel] [k] __d_lookup |
| 1.55% libc-2.12.so [.] __strcmp_sse42 |
| 1.43% nginx [.] ngx_vslprintf |
| 1.37% [kernel] [k] tcp_poll |
| |
| 第一列：符号引发的性能事件的比例，默认指占用的cpu周期比例。 |
| 第二列：符号所在的DSO(Dynamic Shared Object)，可以是应用程序、内核、动态链接库、模块。 |
| 第三列：DSO的类型。[.]表示此符号属于用户态的ELF文件，包括可执行文件与动态链接库)。[k]表述此符号属于内核或模块。 |
| 第四列：符号名。有些符号不能解析为函数名，只能用地址表示。 |
举例2
| # perf top -g |
| |
| # perf top -e cycles |
| |
| # perf top -p 23015,32476 |
| |
| # perf top -s comm,pid,symbol |
| |
| # perf top --comms nginx,top |
| |
| # perf top --symbols kfree |
举例3
| # perf stat ls |
| |
| Performance counter stats for 'ls': |
| |
| 0.653782 task-clock # 0.691 CPUs utilized |
| 0 context-switches # 0.000 K/sec |
| 0 CPU-migrations # 0.000 K/sec |
| 247 page-faults # 0.378 M/sec |
| 1,625,426 cycles # 2.486 GHz |
| 1,050,293 stalled-cycles-frontend # 64.62% frontend cycles idle |
| 838,781 stalled-cycles-backend # 51.60% backend cycles idle |
| 1,055,735 instructions # 0.65 insns per cycle |
| # 0.99 stalled cycles per insn |
| 210,587 branches # 322.106 M/sec |
| 10,809 branch-misses # 5.13% of all branches |
| |
| 0.000945883 seconds time elapsed |
| |
| 输出包括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是预测错误的分支指令数。 |
| |
| # perf stat -r 10 ls > /dev/null #执行10次程序，给出标准偏差与期望的比值 |
| |
| # perf stat -v ls > /dev/null #显示更详细的信息 |
| |
| # perf stat -n ls > /dev/null #只显示任务执行时间，不显示性能计数器 |
| |
| # perf stat -a -A ls > /dev/null #单独给出每个CPU上的信息 |
| |
| # perf stat -e syscalls:sys_enter ls #ls命令执行了多少次系统调用 |
举例4
| # perf record -p `pgrep -d ',' nginx` |
| |
| # perf record ls -g |
| |
| # perf record -e syscalls:sys_enter ls |
举例5
| |
| |
| |
| |
| Name acquired contended total wait (ns) max wait (ns) min wait (ns) |
| |
| &mm->page_table_... 382 0 0 0 0 |
| &mm->page_table_... 72 0 0 0 0 |
| &fs->lock 64 0 0 0 0 |
| dcache_lock 62 0 0 0 0 |
| vfsmount_lock 43 0 0 0 0 |
| &newf->file_lock... 41 0 0 0 0 |
| |
| Name：内核锁的名字。 |
| aquired：该锁被直接获得的次数，因为没有其它内核路径占用该锁，此时不用等待。 |
| contended：该锁等待后获得的次数，此时被其它内核路径占用，需要等待。 |
| total wait：为了获得该锁，总共的等待时间。 |
| max wait：为了获得该锁，最大的等待时间。 |
| min wait：为了获得该锁，最小的等待时间。 |
举例6
| # perf kmem record ls #记录 |
| |
| # perf kmem stat --caller --alloc -l 20 #报告 |
| |
| ------------------------------------------------------------------------------------------------------ |
| Callsite | Total_alloc/Per | Total_req/Per | Hit | Ping-pong | Frag |
| ------------------------------------------------------------------------------------------------------ |
| perf_event_mmap+ec | 311296/8192 | 155952/4104 | 38 | 0 | 49.902% |
| proc_reg_open+41 | 64/64 | 40/40 | 1 | 0 | 37.500% |
| __kmalloc_node+4d | 1024/1024 | 664/664 | 1 | 0 | 35.156% |
| ext3_readdir+5bd | 64/64 | 48/48 | 1 | 0 | 25.000% |
| load_elf_binary+8ec | 512/512 | 392/392 | 1 | 0 | 23.438% |
| |
| Callsite：内核代码中调用kmalloc和kfree的地方。 |
| Total_alloc/Per：总共分配的内存大小，平均每次分配的内存大小。 |
| Total_req/Per：总共请求的内存大小，平均每次请求的内存大小。 |
| Hit：调用的次数。 |
| Ping-pong：kmalloc和kfree不被同一个CPU执行时的次数，这会导致cache效率降低。 |
| Frag：碎片所占的百分比，碎片 = 分配的内存 - 请求的内存，这部分是浪费的。 |
| 有使用--alloc选项，还会看到Alloc Ptr，即所分配内存的地址。 |
举例7
| # perf sched record sleep 10 |
| |
| # perf report latency |
| |
| |
| Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at | |
| |
| events/10:61 | 0.655 ms | 10 | avg: 0.045 ms | max: 0.161 ms | max at: 9804.958730 s |
| sleep:11156 | 2.263 ms | 4 | avg: 0.052 ms | max: 0.118 ms | max at: 9804.865552 s |
| edac-poller:1125 | 0.598 ms | 10 | avg: 0.042 ms | max: 0.113 ms | max at: 9804.958698 s |
| events/2:53 | 0.676 ms | 10 | avg: 0.037 ms | max: 0.102 ms | max at: 9814.751605 s |
| perf:11155 | 2.109 ms | 1 | avg: 0.068 ms | max: 0.068 ms | max at: 9814.867918 s |
| |
| TASK：进程名和pid。 |
| Runtime：实际的运行时间。 |
| Switches：进程切换的次数。 |
| Average delay：平均的调度延迟。 |
| Maximum delay：最大的调度延迟。 |
| Maximum delay at：最大调度延迟发生的时刻。 |
举例8
| # perf probe --line schedule |
| |
| # perf report latency --sort max |
Linux性能计数器是一个新的基于内核的子系统，它提供一个性能分析框架，比如硬件（CPU、PMU(Performance Monitoring Unit)）功能和软件(软件计数器、tracepoint)功能。
通过perf，应用程序可以利用PMU、tracepoint和内核中的计数器来进行性能统计。它不但可以分析指定应用程序的性能问题（per thread），也可以用来分析内核的性能问题，当然也可以同时分析应用程序和内核，从而全面理解应用程序中的性能瓶颈。
使用perf，可以分析程序运行期间发生的硬件事件，比如instructions retired、processor clock cycles等；也可以分析软件事件，比如page fault和进程切换。
Performance Monitor Unit，性能监视单元，其实CPU提供的一个单元，属于硬件的范畴。通过访问相关的寄存器能读取到CPU的一些性能数据，目前大部分CPU都会提供相应的PMU。
内存读写是很快的，但是还是无法和处理器指令执行速度相比。为了从内存中读取指令和数据，处理器需要等待，用处理器时间来衡量，这种等待非常漫长。cache是一种SRAM，读写速度非常快，能和处理器相匹配。因此将常用的数据保存在cache中，处理器便无需等待，从而提高性能。cache的尺寸一般都很小，充分利用cache是软件调优非常重要部分。
tracepoints是散落在内核源码中的一些hook，它们可以在特定的代码被执行到时触发，这一特性可以被各种trace/debug工具所使用。
perf将tracepoint产生的时间记录下来，生成报告，通过分析这些报告，调优人员便可以了解程序运行期间内核的各种细节，对性能症状做出准确的诊断。
这些tracepint的对应的sysfs节点在/sys/kernel/debug/tracing/events目录下。
下图展示perf整体架构
perf提供的事件主要可以分为三种：
- Hardware Event由PMU部件产生，在特定的条件下探测性能事件是否发生以及发生的次数。比如cache命中。
- Software Event是内核产生的事件，分布在各个功能模块中，统计和操作系统相关性能事件。比如进程切换，tick数等。
- Tracepoint Event是内核中静态tracepoint所触发的事件，这些tracepoint用来判断程序运行期间内核的行为细节，比如slab分配器的分配次数等。
perf –help之后可以看到perf的二级命令（常用的以黑体标出）
我们可以把perf捕捉的信息制作成火焰图来方便查看与分析CPU 的调用栈
火焰图（Flame Graph）是由 Linux 性能优化大师 Brendan Gregg 发明的，和所有其他的 profiling 方法不同的是，火焰图以一个全局的视野来看待时间分布，它从底部往顶部，列出所有可能导致性能瓶颈的调用栈。
下载FlameGraph工具，
生成火焰图，一般遵循一下流程：
