性能分析、调整方法

 文章内容来自《性能之巅》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、是什么让你认为存在性能问题？

　　2、系统之前运行的好吗？

　　3、最近有什么改动？软件？硬件？负载？

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

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

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

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

六、科学法

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

　　1、问题

　　2、假设

　　3、预测

　　4、实验

　　5、分析

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

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

　　示例（观测性）：

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

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

　　

 

　　这个方法辨别出的很可能是系统瓶颈的问题，不过，一个系统可能不止面临一个性能问题，因此你可能一开始就能找到问题，但所找到的问题绝非你关心的那个。在根据需要返回use方法遍历其他资源之前，每个发现可以用更多的方法进行调查。

　　指标描述：

　　use方法的指标通常如下：

　　使用率：一定时间间隔内的百分比值

　　饱和度：等待队列的长度

　　错误：报告出的错误次数

　　虽然看起来有点违反直觉，但即便整体的使用率在很长一段时间都处于较低水平，一次高使用率的瞬时冲击还是能导致饱和度与性能问题的。某些监控工具汇报的使用率是超过5分钟的均值，举个例子：每秒CPU使用率可能变动的非常剧烈，因此5分钟的时长的均值可能会掩盖短时间内的100%的使用率，甚至是饱和的情况。

　　想想一些高速公路收费站，使用率就相当于有多少收费站在忙于收费。使用率100%意味着你找不到一个空的收费站，必须排在别人的后边（饱和的情况）如果我说一整天收费站的使用率是40%，你能判断当天是否有车在某一时间排过队吗？很可能在高峰时候确实排过队，那时的使用率是100%，但是在这一天的均值上是看不出的。

　　资源列表：

　　use方法的第一步是要建一张资源列表，要尽可能完整。下面是一张服务器通常的资源表，配有相应的例子：

　　cpu：插槽、核、硬件线程（虚拟cpu）

　　内存：dram；

　　网络接口：以太网端口

　　存储设备：磁盘

　　控制器：存储、网络

　　互联：cpu、内存、I/O

　　每个组件通常作为一类资源类型。例如，内存是一种容量资源，网络接口是一类I/O资源（IOPS或吞吐量）。有些组件体现出多种资源类型：例如，存储设备既是I/O资源也是容量资源，这时需要考虑到所有的类型都能造成性能瓶颈，同时，也要知道I/O资源可能进一步被当做排队系统来研究，将请求排队并被服务。

　　某些物理资源，诸如硬件缓存（如cpu缓存，可能不在清单中。）use方法是处理在高使用率或饱和状态下性能下降的资源最有效的方法，当然还有其他的检测方法。如果你不确定清单是否该包括一项资源，那就包括它，看看在实际指标中是什么样的情况。

 

　　原理框图

　　另一种遍历所有资源的方法是找到或者画一张系统的原理框图，正如下图示，这样的图还显示了组件的关系，这对寻找数据流动中的瓶颈是很有帮助的。

　　CPU、内存、I/O互联和总线常常被忽视。所幸的是，他们不是系统的常见瓶颈，因为这些组件本身就设计有超过吞吐量的余量。可能你需要升级主板，或者减小负载。例如：零拷贝就减轻了内存和总线的负载

　　

　　指标

　　一旦你掌控了资源的列表，就可以考虑这三类指标：使用率、饱和度以及错误。下表种列举了一些资源和指标类型，以及一些可能的指标。

　　这些指标要么是一定时间间隔的均值，要么是累计数目。

　　

 

　　　　　　　　　　　　双CPU系统原理框图示例

　　

　　

　　　　　　　　　　　use方法指标示例

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

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

　　

 

　　　　　　　　　　　　use方法指标的进阶示例

　　上述的某些指标可能用操作系统的标准工具是无法获得的，可能需要使用动态跟踪或者用到CPU性能计数器。

　　软件资源

　　某些软件资源的检测方法可能相似。这里指的是软件组件，而不是整个应用程序，示例如下：

　　1、互斥锁：锁被持有的时间是使用时间，饱和度指的是有线程排队在等锁

　　2、线程池：线程忙于处理工作的时间是使用时间，饱和度指的是等待线程池服务的请求数目

　　3、进程/线程容量：系统的进程或线程的总数是有上限的，当前的使用数目是使用率，等待分配认为是饱和度，错误是分配失败

　　4、文件描述符容量：同进程/线程容量一样，只不过针对的是文件描述符

　　如果这些指标在你的案例里管用，就用它们；否则，用其他方法也是可以的，如延时分析。

　　使用建议：

　　对于使用上述这些指标类型，这里有一些总体的建议：

　　使用率：100%的使用率通常是瓶颈的信号（检查饱和度并确认其影响）。使用率超过60%可能会是问题。基于以下理由：时间间隔的均值，可能掩盖了100%使用率的短期爆发，另外，一些资源，诸如硬盘，通常在操作期间是不能被中断的，即使是做优先级较高的工作，随着使用率的上升，排队延时会变的更频繁和明显。

　　饱和度：任何程度的饱和都是问题（非零），饱和度可以用排队长度或者排队所花的时间来度量

　　错误：错误都是值得研究的。尤其是随着错误增加性能会变差的那些错误

　　低使用率、无饱和、无错误：这样的反例研究起来容易。这点要比看起来还有用--缩小研究的范围能帮你快速的将精力集中在出问题的地方，判断其不是某一个资源的问题，这是一个排除法的过程。

　　云计算

　　在云计算环境，软件资源控制在于限制或者给分享系统的多个租户设定阈值。在Joyent的公司，我们主要用os虚拟技术，来设定内存限制，cpu限制，以及存储I/O的门限制。每一项资源的限定都能用use方法来检验，与检查物理资源的方法类似。

　　举个例子，内存容量使用率是租户的内存使用率与其他内存容量的比值。内存容量饱和出现于匿名的分页活动，虽然传统的页面扫描此时可能是空闲的。

十、工作负载特征归纳

　　工作负载特征归纳是辨别这样一类问题简单而又高效的方法--由施加的负载导致的问题。这个问题关注于系统的输入，而不是所产生的性能。你的系统可能没有任何架构或者配置上的问题，但是系统的负载超出了它所能承受的合理范围。

　　工资负载可以通过回答下列问题来进行特征归纳：

　　1、负载是谁产生的？进行ID，用户ID，远端IP地址？

　　2、负载为什么会调用？代码路径、堆栈跟踪？

　　3、负载的特征是什么？IOPS、吞吐量、方向类型（读取/写入）？包含变动（标准方差），如果有的话

　　4、负载是怎样随着时间变化的？有日常模式吗？

　　将上述所有的问题都做检查会很有用，即便你对于答案会是什么已经有了很强的期望，但还是应做一遍，因为你可能大吃一惊。

　　请思考这么一个场景：你碰到一个数据库性能问题，数据库请求来自一个web服务器池，你是不是应该检查正在使用数据库的IP地址？你本认为这些应该都是web服务器，正如所配置的那样。但你检查后发现好像整个因特网都在往数据库扔负载，以摧毁其性能。你正处于dos攻击中！
　　最好的性能来自消灭不必要的工作，有时候不必要的工作室由于应用程序的不正常运行引起的，例如：一个困在循环的线程无端的增加CPU的负担。不必要的工作也有可能源于错误的配置--举个例子，在白天运行全系统的备份--或者是之前说过的dos攻击。归纳工作负载的特征能识别这类问题，通过维护和重新配置可以解决这些问题。

　　如果被识别出的问题无法解决，那么可以用系统资源控制来限制它。举个例子，一个系统备份的任务压缩备份数据会消耗CPU资源，这会影响数据库，而且还要用网络资源来传输数据。用资源控制来限定备份任务对CPU和网络的使用（如果系统支持的话）这样虽然备份还是会发生，但不影响数据库

　　除了识别问题，工作负载特征归纳还可以作为输入用于仿真基准设计。如果度量工作负载只是用的均值，理想情况，你还要收集分布和变化的细节信息。这对于仿真工作负载的多样性，而不是仅测试均值负载是很重要的。

　　工作负载分析通过辨识出负载问题，有利于将负载问题和架构问题区分开。

　　执行工作负载特征归纳所用的工具和指标视目标而定。一部分应用程序所记录的详细的客户活动信息可以成为统计分析的数据来源。这些程序还可以提供每日或每月的用户试用报告，这也是值得关注的。

十一、向下挖掘分析法

　　深度分析开始于在高级别检查问题，然后依据之前的发现缩小关注的范围，忽视那些无关的部分，更深入发掘那些相关的部分。整个过程会探究到软件栈较深的级别，如果需要，甚至可以达到硬件层，以求找到问题的根源。

　　在《Solaris性能与工具》一书中，针对系统性能，深度分析方法分为以下三个阶段：

　　1、检测：用于持续记录高层级的统计数据，如果问题出现，予以辨别和报警

　　2、识别：对于给定问题，缩小研究的范围，找到可能的瓶颈

　　3、分析：对特定的系统做进一步的检查，找到问题根源并量化问题

　　检测是在公司范围内执行，所有服务器和云数据都会聚合在一起。传统的方法是使用SNMP，监控支持该协议的网络设备。数据可以揭示长期的变化特点，这些是无法由短时间内运行的命令行工具获得的。如果发现怀疑的问题，多数的检测方案会报警，此时及时分析进入下一阶段。

　　问题的识别在服务器上是交互执行的，用标准的检测工具来检查系统的组件：CPU、磁盘、内存等等。通常是用vmstat、iostat、mpstat这样的工具起一个命令行会话来完成的。还有一些较新的工具通过GUI支持的实时性能分析。

　　有些分析工具还具备tracing或者profiling的功能，用以对可疑区域做更深层次的检查。做这类深层的分析可能需要定制工具乃至检查源代码。大量研究的努力就花在这里，俺需要对软件栈的层次做分离来找出问题的根本原因。执行这类任务的工具包括stace、truss、pref、Dtrace

　　五个why

　　在分析阶段，你还有一个能用的方法，叫做“五个why”技巧：问自己why？然后作答：

　　1、查询多了数据库性能就开始变差。why？

　　2、由于内存换页磁盘I/O延时。why？

　　3、数据库内存用量变得太大了。why？

　　4、分配器消耗的内存比应该用的多。why？

　　5、分配器存在内存碎片的问题。why？

　　这是一个真实的例子，但出人意料的是要修复的是系统的内存分配库。是持续的质问和对问题实质的深入研究使得问题得以解决。

十二、延时分析

　　延时分析检查完成一项操作所用的时间，然后把时间再分成小的时间段，接着对有着最大的延时的分析时间段做再次的划分，最后定位并量化问题的根本原因。与深度分析相同，延时分析也会深入研究到软件栈的各层来找到延时问题的原因。

　　分析可以从所施加的工作负载开始，检查工作负载是如何在应用程序中处理的，然后深入到操作系统的库、系统调用、内核以及设备驱动。

　　举个例子、Mysql的请求延时分析可能涉及到以下问题的回答：

　　1、存在请求延时的问题吗？（是的）

　　2、请求时间大量花费在CPU上？（不在CPU上）

　　3、不花在CPU上的时间在等待什么？（文件系统I/O）

　　4、文件系统的I/O时间是花在磁盘I/O上还是锁竞争上？（磁盘I/O）

　　5、磁盘I/O主要是随机寻址的时间还是数据传输的时间？（数据传输的时间）

　　对于这个问题，每一步所提出的问题都讲延时划分成了两个部分，然后继续分析那个较大可能的部分：延时的二分搜索法，你可以这么理解，下图

　　一旦是被出A和B中较慢的那个，就可以对其做下一步的分析和划分，依此类推。

　　数据库查询的延时分析是R方法的目的。

　　

 

　　　　　　　　　　　　延时分析过程

十三、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、该组件是需要的嘛？

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

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

　　4、有组件出现错误吗？是在降级状态吗？

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

　　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端对端数据传输。

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