开头先膜拜gregg巨佬,并附上他的图:
性能分析
CPU使用率
CPU 使用率描述了非空闲时间占总CPU时间的百分比, 然后根据CPU上运行的任务的不同, 又可划分为: 用户CPU, 系统/内核CPU , 等待IO CPU, 软/硬中断CPU使用.
CPU使用率包括:
- 用户 CPU 使用率: 包括用户态 CPU 使用率（user）和低优先级用户态 CPU 使用率（nice），表示 CPU 在用户态运行的时间百分比。用户 CPU 使用率高，通常说明有应用程序比较繁忙。
- 系统 CPU 使用率: 表示 CPU 在内核态运行的时间百分比（不包括中断）。系统 CPU 使用率高，说明内核比较繁忙。
- 等待IO的使用率: 也就是
iowait,即系统等待IO的时间百分比. 如果iowait较高,说明系统与硬件的交互时间长. - 软/硬中断CPU使用率: 表示系统软硬中断的时间比率,使用率越高,说明发生了大量的中断.
- 窃取CPU使用率(steal): 表示被其他虚拟机占用的CPU时间百分比.
- 客户CPU使用率(guest): 运行客户虚拟机的 CPU 时间百分比。
平均负载
也就是top或者uptime中, 如下所示的内容:
1 | 9:29 up 1 day, 17:22, 4 users, load averages: 2.00 2.07 2.14 |
它反应了系统的整体负载情况，主要包括三个数值，分别指过去 1 分钟、过去 5 分钟和过去 15 分钟的平均负载。
理想情况下,认为负载等于CPU核数是一个较为理想的或者健康的状况. 但是在实际工作中,一般认为 0<load< 0.8 * 核数 为一个较为理想的使用状态. 高于0.8 * 核数 就可能需要引起警惕.
上下文切换
上下文切换分为:
- 自愿上下文切换: 无法获取足够的资源导致. 可能是内存,IO等系统资源不足导致
- 非自愿上下文切换: 进程的时间片已到被系统强制调度.
在进程的上下文切换中, 会将寄存器, 内核栈, 虚拟内存等数据恢复. 过多的上下文切换会导致,此项的大量开销, 减少CPU真正运行的时间.
缓存命中率
排查思路
方法论
如何判断性能优化是否有效? 特别是优化后 , 到底能提升多少性能呢?
评估优化效果
首先需要对系统性能指标进行量化,量化步骤如下:
- 确定性能的量化指标
- 测试优化前的性能指标
- 测试优化后的性能指标
不要局限在单一维度的指标上，至少要从应用程序和系统资源这两个维度，分别选择不同的指标。例如:
- 应用程序的维度，我们可以用吞吐量和请求延迟来评估应用程序的性能。
- 系统资源的维度，我们可以用CPU 使用率来评估系统的 CPU 使用情况。
选择从这两个维度分析的原因如下:
- 好的应用程序是性能优化的最终目的和结果，系统优化总是为应用程序服务的。所以，必须要使用应用程序的指标，来评估性能优化的整体效果。
- 系统资源的使用情况是影响应用程序性能的根源。所以，需要用系统资源的指标，来观察和分析瓶颈的来源。
性能测试: 如ab, sysbench 等, 记得要控制变量
性能问题通常不是独立的，如果有多个性能问题同时发生，你应该先优化哪一个呢？
多个问题,怎么抉择
并不是所有的性能问题都值得被优化, 在28原则中,可能有80%的问题由20%的代码导致. 所以优化那20%的代码即可.
还有就是首先做性能分析,找出最重要的、可以最大程度提升性能的问题,进行优化.
提升性能的方法并不是唯一的，当有多种方法可以选择时，你会选用哪一种呢？是不是总选那个最大程度提升性能的方法就行了呢?
多种优化方案,如何抉择
一句话,在成本和结果之间相互考量:
- 如果没有成本预算,选最优性能
- 如果资金不足,那就控制成本,牺牲性能.
毕竟只有业务能跑下去才有意义. 一切的优化都是以业务更好的运行而为目的.
常见的优化思路:
- 程序优化
- 编译器
- 算法处理
- 异步处理
- 多线程替代多进程
- 缓存
- 系统优化
- 绑核
- CPU独占
- 优先级
- 资源限制
- NUMA优化
- 中断负载均衡