目录
系统性能分析和性能调整的方法和步骤，其中一些方法很新，尤其是USE 方法。
性能监测、排队理论，以及容量规划会在本章后面部分有所覆盖。后面的各章会在不同的环境中使用这些方法，对于特殊的性能分析领域还会使用一些特定的方法。
一、街灯讹方法
这个方法实际并不是一个深思熟虑的方法。用户选择熟悉的观测工具来分析性能，这些工具可能是从互联网上找到的，或者是用户随意选择的，仅仅想看看会有什么结果出现。这样的方法可能命中问题，也可能忽视很多问题。
性能调整可以用一种试错的方式反复摸索，对所知道的可调参数进行设置，熟悉各种不同的值，看看是否有帮助。
这样的方法也能揭示问题，但当你所熟悉的工具及所做的调整与问题不相关时，进展会很缓慢。这个方法用一类观测偏差来命名，这类偏差叫做街灯效应，出自下面这则寓言：
一天晚上，一个警察看到一个醉汉在路灯下的地面上找东西，问他在找什么。醉汉回答说他钥匙丢了。警察看了看也找不到，就问他：“你确定你钥匙是在这儿丢的，就在路灯下？”醉汉说：“不，但是这儿的光是最亮的”。
这相当于查看top(1)，不是因为这么做有道理，而是用户不知道怎么使用其他工具。
用这个方法找到的问题可能是真的问题，但未必是你想要找的那个。有一些其他的方法可以衡量发现的结果，能很快地排除这样的“误报”。
二、随机变动讹方法
这是一个实验性质的讹方法。用户随机猜测问题可能存在的位置，然后做改动，直到问题消失。为了判断性能是否已经提升，或者作为每次变动结果的判断，用户会选择一项指标进行研究，诸如应用程序运行时间、延时、操作率（每秒操作次数），或者吞吐量（每秒的字节数。整个方法如下：
1.任意选择一个项目做改动（例如，一项可变参数）。
2.朝某个方向做修改。
3.测量性能。
4.朝另一个方向修改。
5.测量性能。
6.步骤3 或步骤5 的结果是不是要好于基准值？如果是，保留修改并返回步骤1。
这个过程可能最终获得的调整仅适用于被测的工作负载，方法非常耗时而且可能做出的调整不能保持长期有效。例如，一个应用程序的改动规避了一个数据库或者操作系统的bug，其结果是可以提升性能，但是当这个bug 被修复后，程序这样的改动就不再有意义，关键是没有人真正了解这件事情。
三、责怪他人讹方法
这个讹方法包含以下步骤：
1.找到一个不是你负责的系统或环境的组件。
2.假定问题是与那个组件相关的。
3.把问题扔给负责那个组件的团队。
4.如果证明错了，返回步骤1。
也许是网络问题。你能和网络团队确认一下是不是发生了丢包或其他事情么？
不去研究性能问题，用这种方法的人把问题推到了别人身上，当证明根本不是别人的问题时，这对其他团队的资源是种浪费。这个讹方法只是一种因缺乏数据而造成的无端臆想。
为了避免成为牺牲品，向指责的人要屏幕截图，图中应清楚标明运行的是何种工具，输出是怎样中断的。你可以拿着这些东西找其他人征求意见。
四、Ad Hoc 核对清单法
当需要检查和调试系统时，技术支持人员通常会花一点时间一步步地过一遍核对清单。一个典型的场景，在产品环境部署新的服务器或应用时，技术支持人员会花半天的时间来检查一遍系统在真实压力下的常见问题。该类核对清单是Ad Hoc 的，基于对该系统类型的经验和之前所遇到的问题。
举个例子，这是核对清单中的一项：
运 行 iostat -x 1 检 查 await 列 。如 果 该 列 在 负 载 下 持 续 超 过10（ms），那么说明磁盘太慢或是磁盘过载。
一份核对清单会包含很多这样的检查项目。
这类清单能在最短的时间内提供最大的价值，是即时建议而且需要频繁更新以保证反映当前状态。这类清单处理的多是修复方法容易记录的问题，例如设置可调参数，而不是针对源代码或环境做定制的修复。
如果你管理一个技术支持的专业团队，Ad Hoc 核对清单能有效保证所有人都知道如何检查最糟糕的问题，能覆盖到所有显而易见的问题。核对清单能够写得清楚而又规范，说明了如何辨别每一个问题和如何做修复。不过当然，这个清单应该时常保持更新。
五、问题陈述法
明确问题如何陈述是支持人员开始反映问题时的例行工作。通过询问客户以下问题来完成：
1.是什么让你认为存在性能问题？
2.系统之前运行得好吗？
3.最近有什么改动？软件？硬件？负载？
4.问题能用延时或者运行时间来表述吗？
5.问题影响其他的人和应用程序吗（或者仅仅影响的是你）？
6.环境是怎么样的？用了哪些软件和硬件？是什么版本？是怎样的配置？
询问这些问题并得到相应的回答通常会立即指向一个根源和解决方案。因此问题陈述法作为独立的方法收录在此处，而且当你应对一个新的问题时，首先应该使用的就是这个方法。
扫一扫
173万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
