1.1.常用建议
1.1.1.记大量的笔记(记录所有的事情)
在性能调查之初，我通常会为其创建一个目录，在GNU Emacs中打开一个新的“Notes”文件，开始记录系统的信息。之后，将性能结果保存到这个目录，并将有意思的和相关的信息保存到Notes文件。建议将下面的内容添加到你的性能调查文件和目录中：
1.记录软硬件情况，记录下的信息包括硬件配置(主存容量、CPU类型、网络和磁盘子系统)和软件环境(OS和软件的版本、相关配置文件)。示例：每次测试时，保存cat /proc/pci、dmesg和uname-a的输出。
2.保存并组织性能结果
3.记下测试命令，Linux命令script(详见第8章)或者从终端“剪切粘贴”都是完成这项工作的好方法。
4.记录研究信息和URL
在调查问题时，请牢记以下几点：
1.结果的含义可能是不明确的
2.所有的信息都是有用的，通过记录和整理调查过程中你所见的一切，你就有证据支持特定理论，同时也具备大量的测试结果来证明或驳斥其他理论。
3.定期回顾你的笔记可以得到新的想法
1.1.2自动执行重复任务
自动执行性能工具调用和应用程序测试是一个好办法：
1.性能工具调用——有些Linux性能工具的命令行相当复杂，给自己省点力，把它们保存到一个shell脚本中，或是将所有命令都放到可以进行剪切粘贴的参考文件中。
2.应用程序测试——大部分应用程序有着复杂的配置，要么通过命令行，要么通过配置文件。将调用保存为脚本，自动化。
1.1.3尽可能选择低开销工具
例如，对于正在使用的应用程序，工具ps能给出其主存数量和类型的相当不错但粗糙的概况。那些准确性更高，但是影响较大的工具，如memprof或valgrind,虽然也能提供这些信息，但是它们消耗的主存和CPU资源比只使用原始应用程序要大，因此会改变系统行为。
1.1.4使用多个工具来搞清楚问题
实际上，你使用的每一种工具都会为问题的原因提供线索，因此，你必须同时使用多个工具来真正搞清楚发生了什么。
1.1.5 相信你的工具
性能追踪的过程中，最令人兴奋又令人沮丧的时刻之一，就是工具显示了一个“不可能”的结果。某些“不会”发生的事情却明明白白地发生了。第一反应会认为工具坏了。不要被直觉愚弄了，工具是公正的。
1.1.6利用其他人的经验(慎重)
1.2性能调查概要
1.2.1找到指标、基线和目标
性能调查的第一步就是确定当前的性能，并明确其应提升的程度。如果你的系统明显性能不佳，你就可以确定值得花时间进行研究。但是，如果系统性能接近其峰值，那么就不值得研究。明确性能峰值有助于你设置合理的性能期望值，并能给你一个性能目标，这样你就知道何时应该停止优化。你可能总是没有目标地时不时对系统做一点调整，这会浪费大量的时间，只为得到一些额外的性能，即使你可能并不真的需要它们。
1.2.1.1 确定指标
要想知道什么时候结束优化，你必须为系统自行确立或是使用已发布的指标。例如，如果你要优化一个Web服务器，你就可以选择“每秒服务的Web请求数”。如果你没有一个客观的途径来度量性能，那么在调整系统的时候，你几乎无法确定是否取得了进展。
1.2.1.2确定基线
在你明确了如何度量特定系统或应用程序的性能之后，确定当前的性能等级就很重要了。在调整和优化之前，运行应用程序并记录其性能，这就是基线值，它是性能调查的起点。
1.2.1.3确定目标
你确定了性能指标和基线后，现在需要确定一个目标，这个目标引导你完成性能追踪。你可以无限期地调整系统，花费越来越多的时间来获得更加好一点的性能。如果你制定了目标，那么你就会知道什么时候该结束整个过程。要选择合理的目标，下面是一些好的起点：
1.寻找其他有相同配置的人，询问他们的性能指标
2.查找工业标准测试程序的结果，不过，很多基准测试网站给出了特定结果使用的配置，这些配置信息可以为你调整系统提供线索。
3.在不同的OS或应用程序上使用你的硬件
如果用现有的性能信息来指导你的目标，那么你有更好的机会来选择一个积极的，但也并非不可能达到的目标。
1.2.2 追踪近似问题
这里非常重要的一点是要有良好的书面记录来解释你认为问题是怎样的，以及什么样的测试使你得出了这个结论。
1.2.3查看问题是否早已解决
因为你的目的就是要改进系统性能，所以解决性能问题最好的办法就是依靠其他人已有的成果。尽管你很可能对性能问题的具体建议持保留态度，但是这些建议具有启发性，可以使你了解到其他人可能已经研究过相似的问题，他们是如何试着解决问题的，以及他们是否成功了。
下述这些地方也能寻求性能建议：
1.在Web上查找相似的错误信息/问题——这通常是我调查的第一步。
2.在应用程序邮件列表上求助。搜索一下邮件列表的存档，因为有人可能会问过相同的问题。而随后对原始消息的回复也许就描述了一个解决方案。如果没有这样的回复，就向最初提出这个问题的人发邮件，询问他是否找到了解决方法。如果这样也不行，或是没有其他人提出过相似的问题，那么在列表上发邮件说明你的问题，幸运的话，也许已经有人把这个问题解决了。
3.向开发人员发邮件——很多Linux软件在文档的某个位置包含了开发者的e-mail地址，如果在互联网和邮件列表中搜索失败，你可以尝试直接给开发者发邮件。虽然开发者关于性能问题原因的想法不见得正确，但是他们可能会给你指出一个富有成果的方向。
4.与内部开发人员交谈–如果产品是内部开发的。
依靠其他人的工作，你也许在性能调查开始之前就能解决问题。至少，你有可能找到一些有希望的方法来调查，所以，最好总是看看别人有什么发现。
1.2.4项目开始(启动调查)
1.分离问题，如果可能的话，删去任何运行于被调查系统的多余的程序或应用。运行许多不同应用程序的系统，其负载较重，会影响性能工具收集信息的准确性，并最终将你引导到错误的方向。
2.利用系统差异发现原因，如果你能发现一个相似的系统具有更好的性能，那么这对问题调试将是一个有力的帮助。使用性能工具的问题之一就是，你不一定有好的方法知道性能工具的结果是否指明了问题。如果你有一个好的系统和一个差的系统，你就可以在这两个系统上运行同样的性能工具，并比较它们的结果。如果结果不同，就可以通过找出系统差异来确定问题的原因。
3.一次只改变一件事，要真正确定问题出在哪儿，一次只能有一个变化。这可能会很花时间，并让你运行多个不同的测试，但它的确是发现你是否解决了问题的唯一途径。
4.始终在优化后重新测量。如果你稍稍调整了系统，那么在调整后对所有的事情重新进行测量是很重要的。当你开始修改系统配置时，所有之前生成的性能信息可能不再有效。通常，在你解决一个性能问题时，别的问题会随之而来。新问题可能与老问题有着极大的不同，因此，你真的需要重新运行性能工具来确保正在调查的问题没有出错。遵循这些建议能帮助你避免误导，并有助于确定性能问题的原因。
1.2.5 记录，记录 记录
如前所述，记录你所做的事情以便之后回顾和审查，这一点确实很重要。在解决问题后，花些时间重写你的发现以及为什么你认为这么做是对的。包括测量得到的性能结果和做过的实验。虽然看上去工作量很大，但却是非常值得的。
1.3本章小结
首先，确定是否有其他人遇见过相似的问题，如果有，尝试他们的解决方案。要对他们告诉你的保持怀疑，要寻找具有类似问题经验的人。为你的性能追踪设立合理的指标和目标，指标使你知道什么时候应该结束追踪。自动执行性能测试。生成测试结果和配置信息时，要确保将它们记录下来，以便之后可以审查这些结果。保持结果的条理性，记录下任何与你的问题相关的研究和其他信息。最后，定期回顾你的笔记，找出之前可能被漏掉的信息。如果遵循了这些原则，你的问题调查将会有一个明确的目标和一个清晰的过程。