性能分析方法

2020/01/04 22:45
阅读数 256

来源

性能分析方法是一个过程,遵循它你可以分析系统和应用程序的性能表现。这通常提供了分析的起点,以及寻找问题根源的指导。不同的方法适用于不同类型的问题,在达成目标之前,你应该尽可能的尝试各种方法。

没有方法指导的分析活动就像是不正规的调查,随意检查度量结果,直到发现问题(如果这是全部问题)。

本站详细介绍的方法有:

下面简单总结了我建立和遇到的方法。你可以把它们全部打印出来做成一个速查表或提示。

总结

在USENIX LISA 2012会议上,我的演讲Performance Analysis Methodology中,我首次总结并命名了几种性能分析方法(大部分由我开发)。后来我将这些方法记录到了我的Systems Performance一书中,以及ACMQ文章Thinking Methodically about Performance,后者出版在2013年2月的ACM通讯上。更多详细的参考资料在本页的末尾。

下面是我最新的总结列表,枚举了各种方法。首先从反面方法开始,包含它们是为了对比,而非遵循。

反面方法

责备其他人反面方法

  1. 找到一个由其他人负责的系统或环境组件。
  2. 假设问题由这个组件引起。
  3. 将问题转发给负责该组件的团队。
  4. 如果证明不是,返回步骤1。

街灯反面方法

  1. 选几个显然的工具:
    • 熟悉的
    • 从网上找的
    • 随便找的
  2. 运行工具。
  3. 寻找明显的问题。

醉汉反面方法

  1. 随机修改点什么,直到问题消失。

随机变更反面方法

  1. 度量性能基线。
  2. 随机选择一个属性来修改(比如一个可调优属性)。
  3. 向一个方向修改属性。
  4. 度量性能。
  5. 向相反的方向修改属性。
  6. 度量属性。
  7. 检查步骤4和6的结果是否优于基线。如果优于基线,保留变更。否则恢复原值。
  8. 返回步骤1。

消极基准测试反面方法

  1. 选择一个基准测试工具。
  2. 使用多种选项运行测试工具。
  3. 把结果做成幻灯片。
  4. 把幻灯片发给管理层。

交通灯反面方法

  1. 打开仪表盘。
  2. 全是绿灯?认定一切正常。
  3. 有红灯?认定存在问题。

方法

逐项检查清单方法

1到N:运行A,当B发生时,做C。

问题陈述方法

  1. 是什么让你觉得系统存在性能问题?
  2. 系统以前的性能表现好吗?
  3. 最近变更了什么?(软件?硬件?负载?)
  4. 性能下降可以用延迟或运行时间来表示吗?
  5. 这个问题影响到了其他人或其他应用吗(还是只影响到你?)
  6. 环境是什么?使用了什么软件和硬件?版本和配置是什么?

RTFM方法

(阅读合适的文档)如何研究性能工具和度量:

  1. man手册。
  2. 书籍。
  3. 网络搜索。
  4. 同事。
  5. 演讲幻灯片和视频。
  6. 技术支持服务。
  7. 源代码。
  8. 试验。
  9. 社交媒体。

科学方法

  1. 疑问。
  2. 假设。
  3. 预测。
  4. 检验。
  5. 分析。

OODA循环

  1. 观察。
  2. 定向。
  3. 决策。
  4. 行动。

负责特征分析方法

  1. 谁引起了负载?(PID、UID、IP地址等)
  2. 为什么要调用负载?(代码路径)
  3. 负载是什么?(IOPS、吞吐量、类型)
  4. 负载是如何随着时间变化的?(时间序列图表)

钻洞分析方法

  1. 从高级别开始。
  2. 检查下一级别细节。
  3. 分解最重要的分解部分。
  4. 如果问题没有解决,返回步骤2。

淘汰过程

  1. 将目标分解为部分。
  2. 选择一个测试方法:
    • 可以排除大部分未测试部分(最好可以排除剩余部分的一半)。
    • 可以快速执行。
  3. 执行测试。
  4. 是否有一些部分可以排除?
    • 是:返回步骤2。
    • 否:问题找到了吗?
      • 是:结束。
      • 否:有多少个部分经过测试?
        • 一个:目标是经过测试的部分,返回步骤1。
        • 多个:返回步骤2。
      • 不确定:考虑未测试的部分,返回步骤2,并选择一个不同的测试方法。

时间分解方法

  1. 度量操作时间(或延迟)。
  2. 将时间分解为逻辑上顺序的部分。
  3. 持续分解,直到延迟根源被确认。
  4. 量化:如果问题解决,度量加速效果。

(我以前把这种方法叫做“延迟分析方法”)

5个为什么性能方法

1:对于性能表现,提问“为什么”,然后回答这个问题。 2到5:对于前面的回答,提问“为什么”,然后回答问题。

分层方法

依次度量延迟细节(比如,使用直方图)

  1. 动态语言。
  2. 可执行程序。
  3. 库。
  4. 系统调用。
  5. 内核:文件系统、网络。
  6. 设备驱动。

调查产生延迟的最低层。

工具方法

  1. 列出可用的性能功能。
  2. 对每个工具,列出有用的度量。
  3. 对每个对量,列出可能的解释。
  4. 运行选定的工具并解释选定的度量。

USE方法

对每种资源,检查:

  1. 使用率。
  2. 饱和度。
  3. 错误。

CPU检测方法

  1. 进行CPU检测(如火焰图)。
  2. 分析占比大于1%的所有软件。

off-CPU分析

  1. 通过栈跟踪检测每个线程的off-CPU时间。
  2. 累加相同堆栈的时间。
  3. 按时间从高到低分析堆栈。

堆栈检测方法

  1. 检测线程堆栈记录,包括on-CPU和off-CPU。
  2. 累加。
  3. 自底向上分析堆栈。

TSA方法

  1. 对每个重要线程,度量其在每个操作系统线程状态下的时间,如:
    • 执行
    • 可运行
    • 交换
    • 休眠
    • 空闲
  2. 按照频率从高到低依次调查每个状态,使用适当的工具。

主动基准测试方法

  1. 配置基准测试,以适合长时间运行。
  2. 在运行时,使用其他工具分析性能,并确认限制因素。

R方法

  1. 选择对业务负载影响较大的用户操作。
  2. 测量用户操作响应时间的分析。
  3. 计算优化活动的净收益:
    • 如果有足够收益,调优。
    • 如果收益不足,延迟调优,直到情况变化。
  4. 返回步骤1。

性能评估步骤

  1. 陈述研究目标并定义系统边界。
  2. 列出系统服务和可能的影响。
  3. 选择性能度量。
  4. 列出系统和负载参数。
  5. 选择因子和它们的值。
  6. 选择负载。
  7. 设计试验。
  8. 分析和解释数据。
  9. 展示结果。
  10. 如果需要,重新开始。

容量计划过程

  1. 装配系统。
  2. 监视系统使用率
  3. 分析负载特征。
  4. 预测不同选项下的性能。
  5. 选择成本最低、性能最高的选项。

Intel自顶向下层次化性能特征方法

  • 是否为UOP问题?
    • 是:
      • 是否UOP已经收回?
        • 是:收回(正常)。
        • 否:调查故障推断。
    • 否:
      • 分配暂停?
        • 是:调查后端暂停。
        • 否:调查前端暂停。

性能咒语

  1. 别这么做。
  2. 只做一次。
  3. 做少一点。
  4. 晚一点做。
  5. 没人时做。
  6. 同时做吧。
  7. 选便宜的。

基准测试检查清单

  1. 为何不加倍?
  2. 达到限额了吗?
  3. 出错了吗?
  4. 可重现吗?
  5. 重要吗?
  6. 会发生吗?

参考资料

(略)

展开阅读全文
F2
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部