Linux性能优化：性能追踪方法

Blog：博客园 我的

目录

• 记录
• 以脚本代替手动输入
• 选择低开销的工具
• 同时使用多个工具
• 肯定指标和基线
• 追踪近似问题
• 查看问题是否早已解决
• 分离问题
• 一次只改变一件事
• 始终在优化后从新测量

记录

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

每一步操做、每一个输出结果，能够直接截图或者复制保存在文档，便于后期对比分析。

以脚本代替手动输入

使用脚本自动执行，能够节省时间，并有助于避免因不当工具和测试调用形成的误导性信息。

举个例子，你想在特定工做负载下或某段时间内监控系统，可是在测试结束时，你可能不在现场。这种状况下，脚本就很好用了，在测试完成时，能够自动收集、命名、保存所有生成的性能数据，并将它们自动放到“Results”目录中。有了这些基础以后，你就能按照不一样的优化和调整从新运行测试，而且不用担忧数据是否已经保存好。你反而能够集中精力找出问题的缘由，而不是去管理测试结果。

选择低开销的工具

使用工具观察性能变化的同时，也会占用系统的资源，因此尽可能选择低开销的工具来下降对系统的影响。

有些性能工具可以给出高度精确的系统信息，但其检索信息的开销也很高。高开销工具对系统行为带来的变化大于低开销工具。若是你只须要了解系统的粗略信息，那么使用低开销的工具是更好的选择，即便它们不够准确。

同时使用多个工具

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

肯定指标和基线

明确性能峰值有助于你设置合理的性能指望值，并能给你一个性能目标，这样你就知道什么时候应该中止优化。你可能老是没有目标地时不时对系统作一点调整，这会浪费大量的时间，只为获得一些额外的性能，即便你可能并不真的须要它们。

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

在调整和优化以前，运行应用程序并记录其性能，这就是基线值，它是性能调查的起点。

追踪近似问题

经过初始的粗略尝试，你能对问题造成大体的见解。这个简单切口的目的就是收集足够的信息传递给程序的其余用户和开发者，以便他们提出意见和建议。这里很是重要的一点是要有良好的书面记录来解释你认为问题是怎样的，以及什么样的测试使你得出了这个结论。

查看问题是否早已解决

经过搜索引擎(谷歌、百度或国内常见的技术博客平台，好比博客园、CSDN等)查找类似的错误信息/问题。

Web搜索经常会揭示不少与应用程序以及你正在查找的具体错误状况相关的信息。它们还能够指向其余用户所尝试的系统优化，还可能提示哪些有做用、哪些没有做用。成功的搜索能够产生好几页可以直接用于你的性能问题的信息。

分离问题

若是可能的话，删去任何运行于被调查系统的多余的程序或应用。运行许多不一样应用程序的系统，其负载较重，会影响性能工具收集信息的准确性，并最终将你引导到错误的方向。

一次只改变一件事

这点很是重要。要真正肯定问题出在哪儿，一次只能有一个变化。这可能会很花时间，并让你运行多个不一样的测试，但它的确是发现你是否解决了问题的惟一途径。

始终在优化后从新测量

若是你稍稍调整了系统，那么在调整后对全部的事情从新进行测量是很重要的。当你开始修改系统配置时，全部以前生成的性能信息可能再也不有效。一般，在你解决一个性能问题时，别的问题会随之而来。新问题可能与老问题有着极大的不一样，所以，你真的须要从新运行性能工具来确保正在调查的问题没有出错。