性能监控与优化

性能优化——CPU

性能指标&＃xff1a;

• 吞吐、延时&＃xff08;应用负载视角&＃xff09;
• CPU、内存&＃xff08;资源视角&＃xff09;

性能分析&＃xff0c;其实就是找出应用或系统的瓶颈&＃xff0c;并设法去避免或者缓解它们&＃xff0c;从而更高效地利用系统资源处理更多的请求。这包含了一系列的步骤&＃xff0c;比如下面这六个步骤&＃xff1a;

• 选择指标评估应用程序和系统的性能&＃xff1b;
• 为应用程序和系统设置性能目标&＃xff1b;
• 进行性能基准测试&＃xff1b;
• 性能分析定位瓶颈&＃xff1b;
• 优化系统和应用程序&＃xff1b;
• 性能监控和告警。

性能工具图谱&＃xff1a;

平均负载

平均负载是指单位时间内&＃xff0c;系统处于可运行状态(R 状态)和不可中断状态(D 状态)的平均进程数&＃xff0c;也就是平均活跃进程数。

可运行状态&＃xff1a;可运行状态的进程&＃xff0c;是指正在使用 CPU 或者正在等待 CPU 的进程&＃xff0c;即ps 命令中的R 状态&＃xff08;Running&＃xff09;

不可中断状态&＃xff1a;正处于内核态关键流程中的进程&＃xff0c;并且这些流程是不可打断的&＃xff0c;比如最常见的是等待硬件设备的 I/O 响应&＃xff0c;也就是我们在 ps 命令中看到的 D 状态&＃xff08;Uninterruptible Sleep&＃xff0c;也称为 Disk Sleep&＃xff09;的进程。

对于活跃进程数&＃xff0c;最理想的就是每个 CPU 上都刚好运行着一个进程&＃xff0c;这样每个 CPU 都得到了充分利用。比如当平均负载为 2 时&＃xff0c;意味着什么呢&＃xff1f;

• 在只有 2 个 CPU 的系统上&＃xff0c;意味着所有的 CPU 都刚好被完全占用。
• 在 4 个 CPU 的系统上&＃xff0c;意味着 CPU 有 50% 的空闲。
• 而在只有 1 个 CPU 的系统中&＃xff0c;则意味着有一半的进程竞争不到 CPU。

平均负载为多少时合理&＃xff1f;

我们知道&＃xff0c;平均负载最理想的情况是等于 CPU 个数。所以在评判平均负载时&＃xff0c;首先你要知道系统有几个 CPU&＃xff0c;这可以通过 top 命令或者从文件 /proc/cpuinfo 中读取。

知道了CPU个数&＃xff0c;如果平均负载比CPU个数还要大时&＃xff0c;可以判断系统已经出现了过载。

我们可以简单的通过uptime查看系统的负载&＃xff1a;

$ uptime
02:34:03 up 2 days, 20:14, 1 user, load average: 0.63, 0.83, 0.88


各数据的含义&＃xff1a;

02:34:03 – 当前时间

up 2 days, 20:14, – 系统运行时间

1 user – 正在登陆用户数

load average: 0.63, 0.83, 0.88 – 依次是过去 1 分钟、5 分钟、15 分钟的平均负载。

Linux 系统压力测试工具&＃xff1a;stress

Linux 系统监测工具&＃xff1a; sysstat: mpstat pidstat

实际生产环境中&＃xff0c;平均负载高于CPU数量的70%的时候时&＃xff0c;就应该分析排查负载高的问题。

但 70% 这个数字并不是绝对的&＃xff0c;最推荐的方法&＃xff0c;还是把系统的平均负载监控起来&＃xff0c;然后根据更多的历史数据&＃xff0c;判断负载的变化趋势。当发现负载有明显升高趋势时&＃xff0c;比如说负载翻倍了&＃xff0c;你再去做分析和调查。

平均负载与CPU使用率

平均负载与CPU使用率并不一定完全对应。平均负载指单位时间内&＃xff0c;处于可运行状态和不可中断状态的进程数&＃xff0c;所以&＃xff0c;它不仅包括了正在使用 CPU 的进程&＃xff0c;还包括等待 CPU 和等待 I/O 的进程。而 CPU 使用率&＃xff0c;是单位时间内 CPU 繁忙情况的统计。可能的情况有&＃xff1a;

• CPU 密集型进程&＃xff0c;使用大量 CPU 会导致平均负载升高&＃xff0c;此时这两者是一致的&＃xff1b;
• I/O 密集型进程&＃xff0c;等待 I/O 也会导致平均负载升高&＃xff0c;但 CPU 使用率不一定很高&＃xff1b;
• 大量等待 CPU 的进程调度也会导致平均负载升高&＃xff0c;此时的 CPU 使用率也会比较高。

CPU使用率

Linux 作为一个多任务操作系统&＃xff0c;将每个 CPU 的时间划分为很短的时间片&＃xff0c;再通过调度器轮流分配给各个任务使用&＃xff0c;因此造成多任务同时运行的错觉。为了维护 CPU 时间&＃xff0c;Linux 通过事先定义的节拍率&＃xff08;内核中表示为 HZ&＃xff09;&＃xff0c;触发时间中断&＃xff0c;并使用全局变量 Jiffies 记录了开机以来的节拍数。每发生一次时间中断&＃xff0c;Jiffies 的值就加 1。

节拍率 HZ 是内核的可配选项&＃xff0c;可以设置为 100、250、1000 等。不同的系统可能设置不同数值&＃xff0c;可以通过查询 /boot/config 内核选项来查看它的配置值。由于节拍率 HZ 是内核选项&＃xff0c;所以用户空间程序并不能直接访问。为了方便用户空间程序&＃xff0c;内核还提供了一个用户空间节拍率 USER_HZ&＃xff0c;它总是固定为 100&＃xff0c;也就是 1/100 秒。这样&＃xff0c;用户空间程序并不需要关心内核中 HZ 被设置成了多少&＃xff0c;因为它看到的总是固定值 USER_HZ。

Linux 通过 /proc 虚拟文件系统&＃xff0c;向用户空间提供了系统内部状态的信息&＃xff0c;而 /proc/stat 提供的就是系统的 CPU 和任务统计信息。比方说&＃xff0c;如果只关注 CPU 的话&＃xff0c;可以执行下面的命令&＃xff1a;

# 只保留各个CPU的数据
$ cat /proc/stat | grep ^cpu
cpu 280580 7407 286084 172900810 83602 0 583 0 0 0
cpu0 144745 4181 176701 86423902 52076 0 301 0 0 0
cpu1 135834 3226 109383 86476907 31525 0 282 0 0 0


输出中第一列表示的是 CPU 编号&＃xff0c;如 cpu0、cpu1 &＃xff0c;而第一行没有编号的 cpu &＃xff0c;表示的是所有 CPU 的累加。其他列则表示不同场景下 CPU 的累加节拍数&＃xff0c;它的单位是 USER_HZ&＃xff0c;也就是 10 ms&＃xff08;1/100 秒&＃xff09;&＃xff0c;所以这其实就是不同场景下的 CPU 时间。proc主要条目有&＃xff1a;

• user&＃xff08;通常缩写为 us&＃xff09;&＃xff0c;代表用户态 CPU 时间。注意&＃xff0c;它不包括下面的 nice 时间&＃xff0c;但包括了 guest 时间。
• nice&＃xff08;通常缩写为 ni&＃xff09;&＃xff0c;代表低优先级用户态 CPU 时间&＃xff0c;也就是进程的 nice 值被调整为 1-19 之间时的 CPU 时间。这里注意&＃xff0c;nice 可取值范围是 -20 到 19&＃xff0c;数值越大&＃xff0c;优先级反而越低
• system&＃xff08;通常缩写为 sys&＃xff09;&＃xff0c;代表内核态 CPU 时间。
• idle&＃xff08;通常缩写为 id&＃xff09;&＃xff0c;代表空闲时间。注意&＃xff0c;它不包括等待 I/O 的时间&＃xff08;iowait&＃xff09;。
• iowait&＃xff08;通常缩写为 wa&＃xff09;&＃xff0c;代表等待 I/O 的 CPU 时间。
• irq&＃xff08;通常缩写为 hi&＃xff09;&＃xff0c;代表处理硬中断的 CPU 时间。
• softirq&＃xff08;通常缩写为 si&＃xff09;&＃xff0c;代表处理软中断的 CPU 时间。
• steal&＃xff08;通常缩写为 st&＃xff09;&＃xff0c;代表当系统运行在虚拟机中的时候&＃xff0c;被其他虚拟机占用的 CPU 时间。
• guest&＃xff08;通常缩写为 guest&＃xff09;&＃xff0c;代表通过虚拟化运行其他操作系统的时间&＃xff0c;也就是运行虚拟机的 CPU 时间。
• guest_nice&＃xff08;通常缩写为 gnice&＃xff09;&＃xff0c;代表以低优先级运行虚拟机的时间。

而我们通常所说的 CPU 使用率&＃xff0c;就是除了空闲时间外的其他时间占总 CPU 时间的百分比&＃xff0c;用公式来表示就是&＃xff1a;
$$CPU使用率\&＃61;1-空闲时间/CPU总时间$$
但是这里使用/proc/stat 的数据计算出来的是开机以来的平均 CPU 使用率&＃xff0c;一般没啥参考价值。

为了计算 CPU 使用率&＃xff0c;性能工具一般都会取间隔一段时间&＃xff08;比如 3 秒&＃xff09;的两次值&＃xff0c;作差后&＃xff0c;再计算出这段时间内的平均 CPU 使用率&＃xff0c;即
$$平均CPU使用率\&＃61;1-(new空闲时间-Old空闲时间)/(new总CPU时间-old总CPU时间)$$
上面是系统CPU使用率的计算方法&＃xff0c;而对于进程&＃xff0c;在 /proc/[pid]/stat 提供了每个进程提供了运行情况的统计信息。

对于上述系统/进程的CPU使用率&＃xff0c;各种各样的性能分析工具已经帮我们计算好了。不过要注意的是&＃xff0c;**性能分析工具给出的都是间隔一段时间的平均 CPU 使用率&＃xff0c;所以要注意间隔时间的设置&＃xff0c;特别是用多个工具对比分析时&＃xff0c;你一定要保证它们用的是相同的间隔时间。**比如&＃xff0c;对比一下 top 和 ps 这两个工具报告的 CPU 使用率&＃xff0c;默认的结果很可能不一样&＃xff0c;因为 top 默认使用 3 秒时间间隔&＃xff0c;而 ps 使用的却是进程的整个生命周期。

常用CPU观测工具

top显示了系统总体的 CPU 和内存使用情况&＃xff0c;以及各个进程的资源使用情况。

pidstat相对于top&＃xff0c;可以细分监控用户态CPU和内核态CPU每个进程的CPU使用情况

CPU使用率过高怎么办

通过 top、ps、pidstat 等工具&＃xff0c;你能够轻松找到 CPU 使用率较高&＃xff08;比如 100% &＃xff09;的进程。但是要想知道具体占用CPU的是哪个函数&＃xff0c;可以使用perf

perf top&＃xff0c;类似于 top&＃xff0c;它能够实时显示占用 CPU 时钟最多的函数或者指令&＃xff0c;因此可以用来查找热点函数&＃xff0c;如下所示&＃xff1a;


$ perf top
Samples: 833 of event &＃39;cpu-clock&＃39;, Event count (approx.): 97742399
Overhead Shared Object Symbol7.28% perf [.] 0x00000000001f78a44.72% [kernel] [k] vsnprintf4.32% [kernel] [k] module_get_kallsym3.65% [kernel] [k] _raw_spin_unlock_irqrestore
...


输出结果中&＃xff0c;第一行包含三个数据&＃xff0c;分别是采样数&＃xff08;Samples&＃xff09;、事件类型&＃xff08;event&＃xff09;和事件总数量&＃xff08;Event count&＃xff09;。

再往下看是一个表格式样的数据&＃xff0c;每一行包含四列&＃xff0c;分别是&＃xff1a;

• 第一列 Overhead &＃xff0c;是该符号的性能事件在所有采样中的比例&＃xff0c;用百分比来表示。
• 第二列 Shared &＃xff0c;是该函数或指令所在的动态共享对象&＃xff08;Dynamic Shared Object&＃xff09;&＃xff0c;如内核、进程名、动态链接库名、内核模块名等。
• 第三列 Object &＃xff0c;是动态共享对象的类型。比如 [.] 表示用户空间的可执行程序、或者动态链接库&＃xff0c;而 [k] 则表示内核空间。
• 最后一列 Symbol 是符号名&＃xff0c;也就是函数名。当函数名未知时&＃xff0c;用十六进制的地址来表示。

perf record 和 perf report。 perf top 虽然实时展示了系统的性能信息&＃xff0c;但它的缺点是并不保存数据&＃xff0c;也就无法用于离线或者后续的分析。而 perf record 则提供了保存数据的功能&＃xff0c;保存后的数据&＃xff0c;需要你用 perf report 解析展示。

在实际使用中&＃xff0c;我们还经常为 perf top 和 perf record 加上 -g 参数&＃xff0c;开启调用关系的采样&＃xff0c;方便我们根据调用链来分析性能问题。

无法用于离线或者后续的分析。而 perf record 则提供了保存数据的功能&＃xff0c;保存后的数据&＃xff0c;需要你用 perf report 解析展示。

在实际使用中&＃xff0c;我们还经常为 perf top 和 perf record 加上 -g 参数&＃xff0c;开启调用关系的采样&＃xff0c;方便我们根据调用链来分析性能问题。