本文主要是介绍Linux性能优化--性能追踪3：系统级迟缓（prelink），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
12.0 概述
本章包含的例子说明了如何用Linux性能工具寻找并修复影响整个系统而不是某个应用程序的性能问题。阅读本章后，你将能够：
- 追踪是哪一个进程导致了系统速度的降低。
- 用strace调查一个不受CPU限制的进程的性能表现。
- 用strace调查一个应用程序是如何与Linux内核进行交互的。
- 提交描述性能问题的bug报告，以便创作者或维护者有足够的信息修改该问题。
12.1调查系统级迟缓
本章我们调查系统级迟缓。首先会发现系统行为逐渐变慢，我们将用Linux性能工具找到确切的原因。这种类型的问题经常发生。作为一个用户或系统管理员，有时你可能会注意到Linux机器变得缓慢，或者需要很长时间才能完成任务。能够弄清楚机器变缓的原因是很有价值的。
12.2确定问题
和前面一样，第一个步骤是准确找出我们要调查的问题。本例中，在使用Fedora Core 2桌面系统的条件下，我们将调查发生的周期性迟缓问题。通常情况下，桌面系统性能良好，但偶尔磁盘会开始不停地读盘，其结果就是菜单和应用程序打开的时间非常长。过一会儿，磁盘研磨消退，而桌面系统行为又恢复正常。本章我们将弄清楚究竟是什么导致了这个问题，以及其发生的原因。
这个问题的类型与前两章的问题都不一样，因为一开始我们完全不知道系统的哪部分引发了问题。而在调查GIMP和nautilus的性能时，我们是知道应由哪个应用程序对问题负责的。在这种情况下，我们只有一个表现不佳的系统，理论上来说，性能问题可能存在于系统的任何部分。这种情况也是常见的。当遇到它时，重要的是用性能工具去实际追踪问题的原因，而不是仅仅去猜测原因并尝试解决方案。
12.3找到基线/设置目标
还是和前面一样，第一步是确定问题的当前状态。
不过，对本例来说，这一点不容易做到。我们不知道问题什么时候发生或者它会持续多长时间，因此在没有进一步调查前，我们无法真正地设置基线。至于说到目标，理想状态下，我们希望问题完全消失，但是导致问题出现的可能是重要的OS功能，因此，可能无法完全消除它。
首先，针对问题为什么会出现我们需要多做一点调查，以便找到一个合理的基线。第一步是在迟缓发生时运行top。这会给我们提供一个可能导致问题的进程列表，或者甚至也可能直指内核自身。
在这种情况下，如清单12.1所示，运行top并要求它只显示非空闲进程(top运行时按<>)。
清单12.1中的top输出有几个有意思的特性。第一，我们注意到没有进程占用CPU,两个非空闲任务使用的CPU时间都不到2%。第二，系统花费了91%的时间等待I/O的发生。第三，系统没有使用任何交换空间，因此磨盘不是由交换导致的。最后，有一个未知进程prelink在问题发生时正在运行。由于不清楚这个prelink命令是什么，因此我们先记住应用的名字，之后再调查它。
我们的下一步是运行vmstat,看看系统做了什么。清单12.2给出了vmstat的结果，并确认了我们在top中看到的。也就是，大约90%的系统时间用于等待I/O。该清单还告诉我们磁盘子系统读数据的速度大概是1000块/秒。这个磁盘I/O量相当大。
现在我们知道磁盘被频繁使用，内核花费了很多时间等待I/O和未知应用程序prelink 的运行，我们可以开始弄清楚系统究竟在干嘛。
我们不能确认prelink是导致问题的原因，但是我们怀疑它是。明确prelink是否引起磁盘I/O的最简单方法就是“杀死”prelink进程，看看磁盘的使用是不是消失了。(这在生产用计算机上是不可能的，不过我们使用的是个人桌面系统，所以可以快一点儿，不那么严格。)清单12.3显示了vmstat的输出，在其中一半的地方，我们终止了prelink进程。如你所见，prelink被终止后，块读取降为零。
由于prelink看着像是事由应用程序，现在可以开始调查它到底是什么，以及它为什么运行。清单12.4请求rpm告诉我们哪些文件是prelink构成包的组成部分。
首先，我们注意到prelink包有一个日常运行的作业cron。这解释了为什么性能问题的发生是周期性的。其次，我们注意到prelink包含了描述其功能的手册页和文档。手册页将prelink描述为可以预链接可执行文件与库的应用程序，以此减少它们的启动时间。(有点讽刺意味的是，用于提高性能的应用程序正在拉低系统的速度。)prelink有两种运行模式。第一种模式使得所有指定的可执行文件和库都预链接，即使之前已经完成预链接了。(用–force或-f选项指定)。第二种是快速模式，prelink只需查看库与可执行文件的mtime与ctime,看看从上次预链接后是否发生了变化。(用–quick或-q选项指定。)通常，prelink会把已预链接的可执行文件的所有mtime和ctime写入它自己的缓存。然后在快速模式中使用这些信息，以避免对已经预链接过的可执行文件再执行预链接。
检查prelink包中的cron条目显示，默认情况下，Fedora系统同时使用了prelink的两种模式。每隔14天用完整模式调用prelink。而在此期间的每一天，prelink运行于快速模式。
对完整模式和快速模式下的prelink进行计时可以告诉我们最糟糕的情况有多慢(全预链接),以及使用快速模式后性能提升了多少。对prelink计时要小心，因为不同的运行可能会产生完全不同的时间。如果运行的应用程序使用了大量的磁盘I/O,就必须让它多运行几次以便获得对其基准性能的精确指示。磁盘密集型应用程序第一次运行时，许多数据从它的I/O加载到缓存。程序第二次运行时，其性能就会好很多，因为要使用的数据已经在缓存中了，不再需要从磁盘读取。如果用第一次运行作为基线，你会被误导，以为调整后性能就提升了，但其实提升的真正原因是预热了缓存。只有多运行应用程序几次，你才可以预热好缓存，获得准确的基线。清单12.5显示了运行多次后，两种模式下prelink 的结果。
清单12.5中首先要注意的事实是快速模式与完整模式相比，并没有都快得那么多。这点值得怀疑，需要更多的调查。第二点事实强调了top的报告。prelink只占用了一点CPU 时间，其余的全都用来等待磁盘I/O。
现在我们必须选择一个合理的目标。安装在prelink包中的PDF文件描述了预链接的过程。它也说明了完整模式需要花费几分钟，而快速模式需要花费几秒钟。作为目标，让我们试着把快速模式的时间减少到一分钟之内。即使我们可以优化快速模式，每隔14天仍然会遇到明显的磨盘，但是日常运行会有更多的改善。
12.4为性能追踪配置应用程序
调查的下一步是为性能追踪配置应用程序。prelink是一个小而独立的应用程序。事实上，它甚至不使用任何共享库。(它是静态链接的。)不过比较好的做法是，用全部的符号对其进行重编译，这样需要的时候就可以在调试器(gdb)中查看它。同样，这个工具用configure命令产生生成文件。我们必须下载源代码到prelink,并用符号对它重新编译。我们可以从Red Hat再次下载prelink的源rpm。源代码被安装在/usr/src/redhat/SOURCES 下。一旦解压了prelink的源代码后，就可以如清单12.6所示对其进行编译。
12.5安装和配置性能工具
追踪的下一步是安装性能工具。本例中，无论是ltrace还是oprofile都派不上用场。oprofile用于剖析使用了大量CPU时间的应用程序，而prelink在运行时只使用了3%的CPU时间，所以oprofile对我们没有帮助。而prelink二进制文件是静态链接的，且不使用任何共享库，所以1trace也帮不上我们。不过，系统调用追踪器strace可能会有帮助，因此我们需要安装它。
12.6运行应用程序和性能工具
现在，我们终于可以开始分析prelink在不同模式下的性能特征了。正如你刚才看到的，prelink没有花很多时间使用CPU,相反，它把所有的时间都花在磁盘I/O上了。prelink必须调用内核进行磁盘I/O,因此我们用性能工具strace应该能追踪它的执行。prelink的快速模式没有表现得比标准完整运行模式快很多，所以我们用strace比较这两个运行，看看是否有任何可疑行为出现。
首先，我们要求strace追踪较慢的完整运行prelink。该运行创建了初始缓存，它将在prelink运行于快速模式时使用。起初，我们让strace显示prelink的系统调用汇总，看看其中的每一个要花多长时间完成。实现该操作的命令如清单12.7所示。
清单12.7还是prelink输出的一个样本。在尝试预链接一些系统可执行文件和库时，prelink显得有些吃力。这个信息在后面会变得很有价值，所以要记住它。
清单12.8显示了由清单12.7中的strace命令生成的输出汇总文件。
如同清单12.8所示，相当多的时间花在了系统调用read上。这是免不了的，prelink需要找出哪些共享库被链接到了应用程序，这就要把部分可执行文件读入并进行分析。prelink 文档表明，当生成应用程序所需库的列表时，该程序实际上是由动态加载器用特殊模式启动的，之后用通道从可执行文件中读取信息。这就是为什么在分析中pread也很高的原因。与之相反，我们希望快速版本中这样的调用会很少。
要查看快速版本的分析有何不同，我们在prelink的快速模式下运行同样的strace命令。实现该操作的strace命令如清单12.9所示。
清单12.10显示了运行于快速模式的prelink的strace分析信息。
这篇关于Linux性能优化--性能追踪3：系统级迟缓（prelink）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
