性能之巅：常用性能分析方法

最新推荐文章于 2024-08-13 14:39:13 发布

Amae

最新推荐文章于 2024-08-13 14:39:13 发布

阅读量3.2k

点赞数

文章标签：性能分析性能分析方法内存优化网络优化系统优化

本文链接：https://blog.csdn.net/Smart_look/article/details/117202352

版权

本文详细介绍了18种性能分析方法，包括街灯讹方法、随机变动讹方法、科学法和USE方法等，通过这些方法来定位和解决系统性能问题。文章强调了问题陈述、工具使用和指标的重要性，并提供了基础线统计、缓存调优和微基准测试等实用技巧，旨在帮助读者深入理解和提升系统性能。

摘要由CSDN通过智能技术生成

为了便于总结，这些方法已经被归类成了不同的类型

为了便于总结，这些方法已经被归类成了不同的类型

方法	类型
街灯讹方法	观测分析
随机变动讹方法	实验分析
责怪他人讹方法	假设方法
AdHoc核对清单法	观测与实验分析
问题陈述法	信息收集
科学法	观测分析
诊断循环	生命周期分析
工具法	观测分析
USE方法	观测分析
工作负载特征归纳	观测分析、容量规划
向下挖掘分析	观测分析
延时分析	观测分析
R方法	观测分析
事件跟踪	观测分析
基础线统计	观测分析
性能监控	观测分析、容量规划
排队论	统计分析、容量规划
静态性能调整	观测分析、容量规划
缓存调优	观测分析、调优
微基准测试	实验分析
容量规划	容量规划、调优

1、街灯讹方法

这个方法实际并不是一个深思熟虑的方法。用户选择熟悉的观测工具来分析性能，这些工具可能是从互联网上找到的，或者是用户随意选择的，仅仅想看看会有什么结果出现。这样的
方法可能命中问题，也可能忽视很多问题。
性能调整可以用一种试错的方式反复摸索，对所知道的可调参数进行设置，熟悉各种不同
的值，看看是否有帮助。
这样的方法也能揭示问题，但当你所熟悉的工具及所做的调整与问题不相关时，进展会很缓慢。这个方法用一类观测偏差来命名，这类偏差叫做街灯效应，出自下面这则寓言：
一天晚上，一个警察看到一个醉汉在路灯下的地面上找东西，问他在找什么。醉汉回答说他钥匙丢了。警察看了看也找不到，就问他：“你确定你钥匙是在这儿丢的，就在路灯下？”醉汉说：“不，但是这儿的光是最亮的”
这相当于查看top(1)，不是因为这么做有道理，而是用户不知道怎么使用其他工具。
用这个方法找到的问题可能是真的问题，但未必是你想要找的那个。有一些其他的方法可
以衡量发现的结果，能很快地排除这样的“误报”。

2、随机变动讹方法

这是一个实验性质的讹方法。用户随机猜测问题可能存在的位置，然后做改动，直到问题消失。为了判断性能是否已经提升，或者作为每次变动结果的判断，用户会选择一项指标进行研究，诸如应用程序运行时间、延时、操作率（每秒操作次数），或者吞吐量（每秒的字节数）。
整个方法如下：
1.任意选择一个项目做改动（例如，一项可变参数）。
2.朝某个方向做修改。
3.测量性能。
4.朝另一个方向修改。
5.测量性能。
6.步骤3或步骤5的结果是不是要好于基准值？如果是，保留修改并返回步骤1。
这个过程可能最终获得的调整仅适用于被测的工作负载，方法非常耗时而且可能做出的调整不能保持长期有效。例如，一个应用程序的改动规避了一个数据库或者操作系统的bug，其结果是可以提升性能，但是当这个bug被修复后，程序这样的改动就不再有意义，关键是没有
人真正了解这件事情。

做不了解的改动还有另一个风险，即在生产负载的高峰期可能会引发更恶劣的问题，因此还需为此准备一个回退方案。

3、责怪他人讹方法

这个讹方法包含以下步骤：
1.找到一个不是你负责的系统或环境的组件。
2.假定问题是与那个组件相关的。
3.把问题扔给负责那个组件的团队。
4.如果证明错了，返回步骤1。
也许是网络问题。你能和网络团队确认一下是不是发生了丢包或其他事情么？
不去研究性能问题，用这种方法的人把问题推到了别人身上，当证明根本不是别人的问题时，这对其他团队的资源是种浪费。这个讹方法只是一种因缺乏数据而造成的无端臆想。
为了避免成为牺牲品，向指责的人要屏幕截图，图中应清楚标明运行的是何种工具，输出
是怎样中断的。你可以拿着这些东西找其他人征求意见。

4、AdHoc核对清单法

当需要检查和调试系统时，技术支持人员通常会花一点时间一步步地过一遍核对清单。
个典型的场景，在产品环境部署新的服务器或应用时，技术支持人员会花半天的时间来检查一遍系统在真实压力下的常见问题。该类核对清单是AdHoc的，基于对该系统类型的经验和之
前所遇到的问题。

举个例子，这是核对清单中的一项：
运行 iostat-x 1检查await列。如果该列在负载下持续超过10(ms)，那么说明磁盘大慢或是磁盘过载。

一份核对清单会包含很多这样的检查项目。
这类清单能在最短的时间内提供最大的价值，是即时建议（参见2.3节）而且需要频繁更新以保证反映当前状态。这类清单处理的多是修复方法容易记录的问题，例如设置可调参数，
而不是针对源代码或环境做定制的修复。
如果你管理一个技术支持的专业团队，AdHoc核对清单能有效保证所有人都知道如何检查最糟糕的问题，能覆盖到所有显而易见的问题。核对清单能够写得清楚而又规范，说明了如何辨别每一个问题和如何做修复。不过当然，这个清单应该时常保持更新。

5、问题陈述法

明确问题如何陈述是支持人员开始反映问题时的例行工作。通过询问客户以下问题来完成:

1.是什么让你认为存在性能问题？
2.系统之前运行得好吗？
3.最近有什么改动？软件？硬件？负载?
4.问题能用延时或者运行时间来表述吗?
5.问题影响其他的人和应用程序吗（或者仅仅影响的是你）？
6.环境是怎么样的？用了哪些软件和硬件？是什么版本？是怎样的配置?

询问这些问题并得到相应的回答通常会立即指向一个根源和解决方案。因此问题陈述法作为独立的方法收录在此处，而且当你应对一个新的问题时，首先应该使用的就是这个方法。

6、科学法

科学法研究未知的问题是通过假设和试验。总结下来有以下步骤:

1.问题
2.假设
3.预测
4.试验
5.分析

问题就是性能问题的陈述。从这点你可以假设性能不佳的原因可能是什么。然后你进行试验，可以是观测性的也可以是实验性的，看看基于假设的预测是否正确。最后是分析收集的试验数据。

举个例子，你可能发现某个应用程序在迁移到一个内存较少的系统时其性能会下降，你假设导致性能不好的原因是较小的文件系统缓存。你可以使用观测的试验方法分别测量两个系统的缓存失效率，预测内存较小的系统缓存失效率更高。用实验的方法可以增加缓存大小（加内存），预测性能将会有所提升。另外，还可以更简单，实验性的测试可以人为地减少缓存的小大（利用可调参数），预计性能将会变差。

下面还有一些更多的例子。
示例（观测性）

1.问题：什么导致了数据库查询很慢？
2.假设：噪声邻居（其他云计算租户）在执行磁盘1/0,与数据库的磁盘I/O在竞争（通
过文件系统）。
3.预测：如果得到在数据库查询过程中的文件系统I/O延时，可以看岀文件系统对于查
询很慢是有责任的。
4.试验：跟踪文件系统延时，发现文件系统上等待的时间在整个查询延时中的比例小于5%。
5.分析：文件系统和磁盘对查询速度慢没有责任。

虽然问题还没有解决，但是环境里的一些大型的组件已经被排除了。执行调查的人可以回到第2步做一个新的假设。

示例（实验性）

1.问题：为什么HTTP请求从主机A到主机C要比从主机B到主机C的时间长？
2.假设：主机A和主机B在不同的数据中心。
3.预测：把主机A移动到与主机B—样的数据中心将修复这个问题。
4.试验：移动主机A并测试性能。
5.分析：性能得到修复—与假设的一致。

如果问题没有得到解决，在开始新的假设之前，要恢复之前试验的变动！（对于此例，就
是把hostA移回去）

示例（实验性）