文章内容来自《性能之巅》2.5章节

 昔之善战者，先为不可胜，以待敌之可胜。不可胜在己，可胜在敌。

　　　　　—《孙子兵法之军形篇》

 

一、街灯讹法

　　非深思熟虑的方法。熟悉的观测工具随意看看，有几率去命中一些问题，也可能忽视一些问题。

　　性能调整可以用一种试错的方式反复摸索，对所知道的可调参数进行设置，熟悉各种不同的值，看看是否有帮助。

　　该方法也能揭示问题，但是当你所熟悉的工具及所做的调整与问题不相关时，进展很缓慢。

　　这个方法用一类观测偏差来命名，这类偏差叫做街灯效应。出自一篇寓言故事：

　　一天晚上，一个警察看到一个醉汉在路灯下边的地面找东西，问他在找什么。醉汉回答说他钥匙丢了。警察看了看也找不到，就问他：“你确定你要是是在这儿丢的，就在路灯下，醉汉说：“不，但是这儿的光是最亮的”。

　　相当于查看top，不是因为这么做有道理，而是用户不知道怎么样使用其他工具。

　　用这个方法找到的问题可能是真的问题，但未必是你想要找的那个。

二、随机变动讹法

　　这是一个实验性质的讹方法。用户随机猜测问题可能存在的位置，然后做改动，直到问题消失。为了判断性能是否已经提升，或者作为每次变动结果的判断，用户会选择一项指标进行研究，诸如应用程序运行时间、延时、操作率（每秒操作数）、或者吞吐量（每秒的字节数）整个方法如下：

　　1、任意选择一个项目做改动（例如一项可变参数）

　　2、朝某个方向做修改

　　3、测量性能

　　4、朝另一个方向做修改

　　5、测量性能

　　6、步骤3或者步骤5的结果是不是要好于基准值果是，保留修改并返回步骤1

　　这个过程可能最终获得的调整仅适用于被测的工作负载，方法非常耗时而且可能做出的调整不能保持长期有效。例如，一个应用程序的改动规避了一个数据库或者操作系统的bug，其结果是可以提升性能，但是当这个bug被修复后，程序这样的改动就不再有意义，关键是没有人真正了解这件事情。

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

三、责怪他人讹法

　　步骤：
　　1、找到一个不是你负责的系统或环境的组件

　　2、假定问题是与那个组件相关的

　　3、把问题扔给负责那个组件的团队

　　4、如果证明错了，返回步骤1

四、Ad Hoc核对清单法

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

　　举个例子，这是核对清单中的一项：

　　运行iostat -x 1检查await列。如果该列在负载下持续超过10ms，那么说明磁盘太慢或者磁盘过载。

　　一份核对清单会包含很多这样的检查项目。

　　这类清单能在最短的时间内提供最大的价值，是及时建议而且需要频繁的更新以保证反应当前状态。这类清单处理的多是修复方法容易记录的问题，例如设置可调参数，而不是针对源代码或者环境做定制的修复。

　　如果你管理一个技术支持的专业团队，Ad Hoc核对清单能有效保证所有人都知道如何检查最糟糕的问题，能覆盖到所有显而易见的问题。核对清单能够写的清楚而且又规范，说明了如何辨别每一个问题和如何做修复。不过当然，这个清单应该时长保持更新。

五、问题陈述法

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

　　1、是什么让你认为存在性能问题/span>

　　2、系统之前运行的好吗/span>

　　3、最近有什么改动件件载/span>

　　4、问题能用延时或者运行时间来表述吗/span>

　　5、问题影响其他的人和应用程序吗/span>

　　6、环境是怎么样的了那些软件和硬件什么版本怎样的配置/span>

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

六、科学法

　　科学法研究未知的问题是通过假设和实验。步骤：

　　1、问题

　　2、假设

　　3、预测

　　4、实验

　　5、分析

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

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

　　示例（观测性）：

　　1、问题：什么问题导致了数据库查询很慢/span>

　　2、假设：噪声邻居（其他云计算租户）在执行磁盘I/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、分析：性能得到修复–与假设的一致

　　如果问题没有得到解决，在开始新的假设之前，要恢复之前试验的变动！

七、诊断循环

　　诊断周期与科学方法相似：
　　假设–>仪器校验–>数据–>假设

　　就像科学法一样，这个方法也是通过收集数据来验证假设。这个循环强调数据可以快速的引发新的假设，进而验证改良，以此继续。

　　上述两个方法，理论数据都有很好的平衡。从假设发展到数据的过程很快，那么不好的理论就可尽早的被识别和遗弃，进而开发更好的理论。

八、工具法

　　导向方法如下：

　　1、列出可用到的性能工具（可选的、安装的或可购买的）

　　2、对于每一个工具，列出它提供的有用的指标

　　3、对于每一个指标，列出阐释该指标可能的规则

　　这个视角的核对清单告诉你那些工具能用、哪些指标能读，以及怎样阐释这些指标。虽然这相当高效，只依赖可用的（或知道的）工具，就能得到一个不完全的系统视野，但是与街灯讹法类似，用户不知道他的视野不完整–而且可能自始至终对此一无所知。需要定制工具（如动态跟踪）才能发现的问题可能永远被识别并解决。

　　在实践中，工具法确实在一定程度上辨别除了资源的瓶颈、错误，以及其他类型的问题，但通常不太高效。

　　当大量的工具和指标可被选用时，逐个枚举是很耗时的，当多个工具具有相同功能时，情况更糟，你需要花额外的时间来了解各个工具的优缺点，在某些情况下，比如要选择做文件系统微基准的工具的场合，工具相当多，虽然这时候你只需要一个。

九、use方法

　　use方法应用于性能研究，用来识别系统瓶颈一言蔽之就是：

　　对于所有的资源、查看他的使用率、饱和度和错误。

　　术语定义：

　　资源：所有服务器物理器件（CPU、总线~~~）某些软件资源也能算在内，提供有用的指标

　　使用率：在规定的时间间隔内，资源用于服务工作的时间百分比。虽然资源繁忙，但是资源还有能力接受更多的工作，不能接受更多工作的程度被视为饱和度。

　　错误：错误事件的个数

　　某些资源类型，包括内存，使用率指的是资源所用的容量。这与基于时间的定义是不同的，一旦资源的容量达到100%的使用率，就无法接受更多的工作，资源或者会把工作进行排队（饱和），或者返回错误，用use方法也就予以鉴别。

　　错误需要调查，因为他们会损害性能，如果故障模式是可恢复的，错误可能难以立即察觉。这包括操作失败重试，还有冗余设备池中的设备故障。

　　与工具法相反的是，use方法列举的是系统资源而不是工具，这帮助你得到一张完整的问题列表，在你寻找工具的时候做确认。即便对于有些问题现有的工具没有答案，但这些问题蕴含的知识对于性能分析也是极其有用的：这些是“已知的已知”

　　use方法会将分析引导到一定数量的关键指标上，这样可以尽快的核实所有的系统资源。在此之后，如果还没有找到问题，那么可以考虑采用其他的方法。

　　图描绘了use方法的流程图。错误被置于检查首位，要先于使用率和饱和度。错误通常容易很快被解释，在研究其他指标之前，把它们梳理清楚是省时高效的：

 

　　　　　　　　　　　　双CPU系统原理框图示例

　　　　　　　　　　　use方法指标示例

　　重复所有的组合，包括获取每个指标的步骤，记录下当前无法获得的指标，那些是已知的未知。最终你得到一个大约30项的指标清单，有些指标难以测量，有些根本测不了。所幸的是常见的问题用较简单的指标就能发现（例如：CPU饱和度，内存容量饱和度， 络接口使用率，磁盘使用率），所以这些指标首先要测量

　　一些比较难的组合示例可见下表

 

　　　　　　　　　　　　延时分析过程

十三、R方法

　　R方法是针对Oracle数据库开发的性能分析方法，意在找到延时的根源，基于Oracle的traceevents。它被描述成“基于时间响应性能提升方法，可以得到对业务的最大经济收益”，着重于识别和量化查询过程中所消耗的时间，虽然它是用于数据库研究领域，但是方法思想可以应用于所有系统，作为一种可能的研究手段，值得在此提及，

十四、事件跟踪

　　系统的操作就是处理离散的事件，包括CPU指令、磁盘I/O，以及磁盘令、 络包、系统调用、函数库调用、应用程序事件、数据库查询等等。性能分析通常会研究这些事件的汇总数据，诸如每秒操作数，每秒的字节数、或者延时的均值。有时一些重要的细节信息不会出现这些汇总之中，因此最好的研究事件的方法是逐个检查。

　　 络排错常常需要逐包检查，用的工具有tcpdump，下边这个例子将个个 络包归纳汇总成了一行行文字。

　　

　　tcpdump按照需要可以输出各类信息

　　存储设备I/O在块设备层可以用iosnoop来跟踪

 　　

 

　　这里打印出了一些时间戳，包括起始时间，终止时间，请求和完成之间的时间，以及服务这这次I/O的估计时间。

　　系统调用层是另一个跟踪的常用层，工具有Linux的strace和基于Solaris系统的truss。这些工具也有打印时间戳的选项。

　　当执行事件跟踪时，需要找到以下信息：

　　1、输入：事件请求的所有属性，即类型、方向、尺寸等等

　　2、时间：起始时间、终止时间、延时

　　3、结果：错误状态、事件结果

　　有时性能问题可以通过检查时间的属性来发现，无论是请求还是结果。事件的时间戳有利于延时分析，一般跟踪工具都会包含这个功能。上述的tcpdump用参数-ttt，输出所包含的DELTA时间，就测量了包与包之间的时间。

　　研究之前发生的事件也能提供信息。一个延时特别差的事件，通常叫做延时离群值，可能是因为之前的事件而不是自身所造成的。例如，队列尾部时间的延时可能会很高，但这是由之前队列里的事件造成的，而并非该时间本身。这种情况只能用事件跟踪来加以辨别。

十五、基础栈统计

　　把当前的性能指标与之前的数值做比较，对分析问题常常有启发作用。负载和资源使用的变化是可见的，可以把问题回溯到他们刚发生的时候。某些观测工具（基于内核计算器）能显示启动以来的信息统计，可以用来与当前的活动做比较。虽然这比较粗糙，但总好过没有。另外的方法就是做基础栈统计。

　　基础栈统计包括大范围的系统观测并将数据进行保存以备将来参考。与启动以来的信息统计不同，后者会隐藏变化，基础栈囊括了每秒的统计，因此变化是可见的。

　　在系统或应用程序变化的之前和之后都能做基础栈统计，进而分析性能变化。可以不定期的执行基础栈统计并把它作为站点记录的一部分，让管理员有一个参照。了解“正常”是什么样的。若是作为性能检测的一部分，可以每天都按固定的间隔执行这类任务。

十六、静态性能调整

　　静态性能调整处理的是架构配置的问题。其他的方法着重的是负载施加后的性能：动态性能。静态性能分析是在系统空闲没有施加负载的时候执行的。

　　做性能分析和调整，要对系统的所有组件确认以下问题：

　　1、该组件是需要的嘛/span>

　　2、配置是针对预期的工作负载设定的嘛/span>

　　3、组件的自动配置对于预期的工作负载时最优的嘛/span>

　　4、有组件出现错误吗在降级状态吗/span>

　　下面是一些在静态性能调整中可能发现的问题：

　　1、 络接口协商：选择100Mb/s而不是1Gb/s

　　2、建立RAID池失败

　　3、使用的操作系统、应用程序或固件是旧的版本。

　　4、文件系统记录的尺寸和工作负载I/O的尺寸不一致

　　5、服务器意外配置了路由

　　6、服务器使用的资源，诸如认证，来自远端的数据中心，而不是本地的。

　　幸运的是，这些问题都很容易检查。难得是要记住做这些事情。

十七、缓存调优

　　从应用程序到磁盘，应用程序和操作系统都会部署多层的缓存来提高I/O性能。这里介绍各级缓存的调优策略：

　　1、缓存的大小尽量和栈的高度一样。靠近工作执行的地方，减少命中缓存的资源开销。

　　2、确认缓存开启并确实在工作。

　　3、确认缓存的命中/失效比例和失效率

　　4、如果缓存的大小是动态的，确认它的当前尺寸。

　　5、针对工作负载调整缓存。这项工作依赖缓存的可调参数。

　　6、针对缓存调整工作负载。这项工作包括减少对缓存不必要的消耗，这样可以释放更多空间来给目标负载使用。

　　要小心二次缓存–比如，消耗内存的两块不同的缓存块，把相同的数据缓存了两次。

　　还有，要考虑到每一层的缓存调优的整体性能收益。调整CPU的L1缓存可以节省纳秒级别的时间，当缓存失效时，用的是L2。提升CPU的L3缓存能避免访问速度慢的多的主存，从而获得较大的性能收益。

十八、微基准测试

　　微基准测试测量的是施加的简单的人造工作负载的 性能。微基准测试可以用于执行科学方法，将假设和预测放到测试中验证，或者作为容量规划的一部分来执行。

　　这与业界的基准定标是不同的，工业的基准定标是针对真实世界和自然的工作负载。这样的基准定标执行时需要工作负载仿真，执行和理解的复杂度高。

　　微基准测试由于涉及的因素较少，所以执行和理解会较为简单，可以用微基准测试工具来施加工作负载并度量性能。或者用负载生成器来产生负载，用标准的系统工具来测量性能。两种方法都可以，但是稳妥的方法时使用微基准测试工具并用标准系统工具再次确认性能数据。

　　下边是一些微基准测试的例子，包括一些二维测试：

　　1、系统调用：针对fork（），exec（），open（），read（），close（）；

　　2、文件系统读取：从缓存过的文件读取，读取数据大小从1B变化到1MB；

　　3、 络吞吐量：针对不同的socket缓冲区的尺寸测试TCP端对端数据传输。

　　微基准测试通常在目标系统上的执行会尽可能快，测量完成大量上述的这类操作所要的时间，然后计算均值（平均时间=运行时间/操作次数）

　　

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8689 人正在系统学习中 相关资源：Veneer:文件屏蔽软件-开源-其它代码类资源-CSDN文库