性能追踪建议

常用建议

记大量的笔记（记录所有的事情）

在调查性能问题时，我们可以做的最重要的事情大概就是记录下看到的每一个输出、执行的每一条命令，以及研究的每一个信息。结构清晰的记录能让我们只查看记录就可以检验关于性能问题原因的猜想，而不是重新运行测试。这能节约大量时间。写下来并且创建性能记录。

在性能调查之初，通常会为其创建一个目录，在GUN Emacs中打开一个新的“Notes” 文件。建议将下面的内容添加到我们的性能调查文件和目录中：

• 记录硬件 / 软件的配置情况：记录下的信息包括硬件配置（内存容量、CPU类型、网络和磁盘子系统）和软件环境（OS 和软件的版本、相关配置文件）。这些信息看上去很容易在之后重现，但是在追踪问题时，我们可能会大幅度地修改系统配置。认真细致的比较有助于在特定的测试过程中弄清楚系统配置。

  示列：每次测试时，保存 cat /proc/pci、dmesg 和 uname -a的输出。

• 保存并组织性能结果：运行很长时间后还能评估性能结果是很有价值的。记录系统配置的同时，也记录测试结果。这使我们得以比较不同配置是如何影响性能结果的。如果需要，可以重新运行测试，但是测试一种配置是耗费时间的过程。只需让笔记保持条理清晰，避免重复工作则效率更高。

• 写下命令行调用：在运行性能工具时，常常需要用困难复杂的命令行来准确定位到我们感兴趣的系统区域进行测量。如果想重新测试，或在不同的应用程序上运行相同的测试，那么，复制这些命令行不仅令人厌烦，并且在初次尝试时，不容易做对。更好的办法是准确记录下我们输入的信息。这样在之后的测试中就能够完全重新命令行，而在回顾之前的测试结果时，也可以看到我们测量的内容。

• 记录研究信息和URL：调查性能问题时，将在互联网上发现相关信息记录下是很重要的，不论发现的途径是博客还是请教他人。

在收集和记录所有这些信息时，我们可能会疑惑：这样做指的吗？有些信息当下可能没有作用或者有误导性，但它在将来可能是有用的。在调查问题时，要牢记以下几点：

• 结果的含义可能是不明确的：性能工具给我们的信息并不总是清晰明了的。有时候，需要更多的信息才能理解某个结果的含义。之后，可以回过头以新的视角重新审视那些看似无用的测试结果。实际上，旧信息可能或驳斥或者证明关于性能问题本质的某个特定理论。
• 所有信息都是有用的（这也就是我们要记录的原因）：记录已运行的测试信息以及系统配置信息的原因不见得会立即明晰。通过记录和整理调查过程中所见的一切，我们就有证据支持特定理论，同时也具备大量的测试结果来证明或驳斥其他理论。
• 定期回顾笔记可以得到新的想法：当我们为性能问题积攒了大量的信息时，那就定期回顾它们。重新审视会让我们关注结果，而不是测试。当许多测试结果放在一起被同时查看时，问题的原因也许就会自动浮现。回顾我们收集的数据，就可以在不实际运行任何测试的情况下进行理论检验。

在调查问题时，重做一些工作虽然是不可避免的，但是，在重做工作上花费的时间越少，效率就越高。如果写了大量的比较，并有办法在发现信息时记录它们，那么就可以依赖已经做过的工作，而避免重复运行测试以及重复研究。保持比较的可靠性和一致性，从而节省时间较少挫折。

自动执行重复任务

当开始调整系统改进性能时，输入复杂命令很容易出现错误，而无意中使用的不正确参数和配置则会产生误导性的性能信息。因此，自动执行性能工具调用和应用程序测试是一个好办法：

• 性能工具调用：有些 Linux 性能工具的命令很复杂，给自己省点力，把它们保存到一个shell脚本中，或是将所有命令都放到可以进行剪切粘贴到参考文件中。这可以让我们少受些挫折，并且让我们多少有信心：用来调用工具的命令是正确的。
• 应用程序测试：大部分应用程序有复杂的配置，要么通过命令行，要么通过配置文件。我们会经常重新运行要多次测试的应用程序，若将调用保存为脚本，就能少走弯路。

尽可能多地自动执行，就能减少错误。使用脚本自动执行，可以节省时间，并有助于避免因不当工具和测试调用造成的误导性信息。

尽可能选择低开销工具

一般情况下，观察系统会修改系统的行为。具体而言，在使用性能工具时，它们会改变系统的行为方式。调查问题的时候，想要看开应用程序是如何执行的，同时还必须处理性能工具引发的错误。这是不可避免的弊端，但是我们要知道它的存在，并努力将其最小化。有些性能工具能够给出高度精确的系统信息，但其检索信息的开销也很高。高开销工具对系统行为代理的变化大于低开销工具。如果只需要了解系统的粗略信息，那么使用低开销的工具是更换的选择，即使它们不够准确。

例如，对于正在使用的应用程序，工具ps 能给出其主存数量和类型的相当不错但粗糙的概况。那些准确性更高，但是影响较大的工具，如memprof 或 valgrind，虽然也能提供这些信息，但是它们消耗的主存和CPU 资源比只使用原生应用程序要大，因此会改变系统行为。

使用多个工具来搞清楚问题

虽然在找出性能问题原因的时候，如果只需要用一个工具那将是非常方便的，但这种情况相当少见。实际上，我们使用的每一种工具都会为问题的原因提供线索，因此，必须同时使用多个工具来真正搞清楚发生了什么。比如，一种性能工具会告诉我们系统存在大量的磁盘 I/O，而另一种工作则告诉我们系统使用了大量的交换。如果只以第一个工具的结论制定解决方案，可能会简单地选择更快的磁盘驱动器（然后发现性能问题仅仅改善了一点点）。而将两种工具的结果放在一起，就会判断出：大量的磁盘 I/O 是由大量使用的交换造成的。在这种情况下，就可能会买更多的主存以减少交换（这样就不会再有大量的磁盘I/O）。

比起单一地使用任何一种工具，同时使用多个性能工具通常能让我们对性能问题有更清晰的了解。

相信我们的工具

性能追踪的过程中，最令人兴奋又令人沮丧的时刻之一，就是工具显示了一个“不可能”的结果。某些 “不会” 发生的事情却明明白白地发生了。第一反应会认为工具坏了。不要被直觉影响了，工具是公正的。虽然它们可能会不准确，但这更有可能是应用程序做了不该做的事情。要使用工具来调查问题。

利用其他人的经验（慎重）

在调查任何一个性能问题时，可能会发现问题令人不知所措。不要独自面对它。问问其他人是否见过同样的问题。试着找到其他解决过我们所遇问题的人。在网上搜索类似的问题，并希望可以找到解决方案。

性能调查概要

由于终极目标是解决问题，因此最好的方法是在我们接触性能工具之前就开始研究问题。遵循如下特定步骤是解决问题的有效方法，并且不会浪费宝贵的时间。

找到指标、基线和目标

性能调查的第一步就是确定当前的性能，并明确其应提升的程度。如果我们的系统明显性能不佳，就可以确定值得花时间进行研究。但是，如果系统性能接近其峰值，那么就不值得研究。明确性能峰值有助于我们设置合理的性能期望值，并能给我们一个性能目标，这样就知道何时应该停止优化。我们可能总是没有目标地时不时对系统做一点调整，这会浪费大量的时间，只为得到一些额外的性能，即使我们可能并不真的需要它们，

确定指标

要想知道什么时候结束优化，就必须为系统自定确立或使用已发布的指标。指标是一种客观的度量，用于指示系统的执行情况。例如，如果要优化一个Web服务器，就可以选择 “每秒服务的Web请求数”。如果没有一个客观的途径来度量性能，那么在调整系统的时候，几乎无法确定是否取得了进展。

确定基线

在明确了如何度量特定系统或应用程序的性能之后，确定当前的性能等级就很重要了。在调整和优化之前，运行应用程序并记录其性能，这就是基线值，它是性能调查的起点。

确定目标

在确定了性能指标和基线后，现在需要确定一个目标，这个目标引导我们完成性能追踪。我们可以无限期地调整系统，花费越来越多的时间来获得更加好一点的性能。如果制定了目标，那么就会知道什么时候该结束整个过程。要选择合理的目标，下面是一些好的起点：

• 寻找其他有相同配置的人，询问他们的性能指标：这是理想状态。如果能发现某人用于相似的系统和更好的性能，则不仅能为我们的系统选定目标，还能与这个人一起工作：他可以确定为什么我们的配置更慢，以及该配置有何不同。在研究问题时，使用另一个系统作为参照被证明是非常有用的。
• 查找工业标准测试程序的结果：许多网站都比较了计算机系统各方面的基准测试结果。有些基准测试结果是经过异常的努力得到的，因此，它们可能不能代表真实的使用情况。不过，很多基准测试网站给出了特定结果使用的配置，这些配置信息可以为我们调整系统提供线索。
• 在不同的OS 或应用程序上使用的硬件：可能要在系统上运行不同的软件以实现相似的功能。比如，如果有两个不同的WEB服务器，其中一个运行较慢，那么就试试另一个，看它的性能是否好一些。或者，在另一个不同的操作系统上运行同一个应用程序。如果上述任一情况下系统执行表现得更好一些，那么，就会知道原来的应用程序还有改进的空间。

抓住低处的果实
性能追踪的另一种方法是选择在特定时间段内进行追踪，而不是选择一个目标，在这段时间内尽可能地针对性能进行优化。如果应用程序从未被优化过，那么通常在给定工作负载下，会有一些问题相对容易解决。这些容易被修复的问题被称为“低处的果实”。

追踪近似问题

使用性能工具为确定问题原因打开第一个口子。通过初始的粗略尝试，能对问题形成大致的看法。这个简单切口的目的就是收集足够的信息传递给程序的其他用户和开发者，以便他们提出意见和建议。这里非常重要的一点是要有良好的书面记录来解释我们认为问题是怎样的，以及什么样的测试使我们得出了这个结论。

查看问题是否早已解决

我们的下一个目标是确定是否有其他人已经解决了这个问题。性能调查可能是一个冗长且费时的事情，如果我们正好可以利用其他人的工作，那么在开始之前就将抢占先机。因为我们的目的就是要改进系统性能，所以解决性能问题最好的办法就是依靠其他人已有的成果。

尽管我们很可能对性能问题的具体建议保持保留态度，但是这些建议具有启发性，可以使我们了解到其他人可能已经研究过相似的问题，他们是如何试着解决问题的，以及他们是否成功了。

项目开始（启动调查）

下面有的方法能让我们的工作效果更好：

• 分离问题：如果可能的话，删去任何运行于被调查系统的多余的程序或应用。运行许多不同应用程序的系统，其负载较重，会影响性能工具收集信息的准确性，并最终将你引导错误的方向。
• 利用系统差异发现原因：如果能发现一个相似的系统具有更好的性能，那么这对问题调试将是一个有力的帮助。使用性能工具的问题之一就是，不一定有好的方法知道性能工具的结果是否指明了问题。如果有一个好的系统和一个差的系统，就可以在这两个系统上运行同样的性能工具，并比较它们的结果。如果结果不同，就可以通过找出系统差异来确定问题的原因。
• 一次只改变一件事：这点非常重要。要真正确定问题出在哪儿，一次只能有一个变化。这可能会很花时间，并让我们运行多个不同的测试，但它的确是发现我们是否解决了问题的唯一途径。
• 始终在优化后重新测量：如果调整了系统，那么在调整后对所有的事情重新进行测量是很重要的。当开始修改系统配置时，所有之前生成的性能信息可能不再有效。通常，在解决一个性能问题时，别的问题会随之而来。新问题可能与老问题有着极大的不同，因此真的需要重新运行性能工具来确保正在调查的问题没有出错。

记录、记录、记录

记录我们所做的事情以便之后回顾和审查，是很重要的。如果已经开始追踪性能问题，那么在脑海里就会有大量的新增笔记和URL。它们可能杂乱无章，混成一团，但现在我们明白它们的意思，知道它们的组织结构。在解决问题后，花写时间重写我们的发现以及为什么认为这么做是对的。包括测量得到的性能结果和做过的实验。虽然看上去工作量很大，但却是非常值得。几个月后，曾经做过的测试很容易就会被忘记，如果没有将结果记录下来，最终可能会重新做测试。如果在这些测试还记忆犹新的时候写了笔记，就不用重做这些工作，而只需要依靠这些记录就行。

总结

追踪性能问题应该是个令人满意且兴奋的过程。如果用正确的方法去研究和分析，问题追踪将会事半功倍。首先，确定是有其他人遇到过类似的问题，如果有，尝试他们的解决方案。要对他们告诉的保持怀疑，要寻找具有类似问题经验的人。为我们的性能追踪设立合理的指标和目标，指标使我们知道什么时候应该结束追踪。自动执行性能测试。生成测试结果和配置信息，要确保将它们记录下来，以便之后可以审查这些结果。保持结果的条理性，记录下任何与问题相关的研究和其他信息。最后，定期回顾笔记，找出之前可能被漏掉的信息。如果遵循了这些原则，问题的调查将会有一个明确的目标和清晰的过程。