正如最近的 Linux 历史所表明的那样（还记得 Mindcraft 吗？），性能不仅是良好的宣传，而且非常重要。然而，当前衡量性能的方法仅提供关于整个系统的全局统计数据，或关于孤立应用程序的非常精确的数据。此外，这些方法通常无法帮助程序员或系统管理员隔离由复杂的互联网应用交互引起的性能瓶颈，而这些应用正变得越来越普遍。Linux 跟踪工具包 (LTT) 解决了这些问题，并为用户提供了系统行为的独特视角，且性能开销极小（< 2.5%）。

为了可扩展并在不影响系统性能的情况下完成其任务，LTT 被设计成尽可能模块化。事实上，称其为“工具”是错误的，因为它由许多部分组成，这些部分组合在一起才能实现所需的功能。这个工具包由四个部分组成。首先，有一个 Linux 内核，它允许记录事件日志。其次，一个 Linux 内核模块负责将事件存储到其缓冲区中，然后在达到某个阈值时向跟踪守护程序发出信号。后者然后从模块读取数据，该模块从用户空间可见为一个字符设备。最后，但同样重要的是，数据解码器获取原始跟踪数据，并将其转换为人类可读的格式，同时执行一些基本和更高级的分析。正如将在后面讨论的那样，这个解码器充当工具包的图形和命令行前端。

LTT tar.gz 压缩包可以在 http://www.opersys.com/LTT/ 找到，其中包含以下项目

这些脚本旨在加速工具最常用的用法，但也可以直接调用工具，而无需任何脚本。

要安装 LTT，只需按照 LTT 包附带的说明进行操作。第一步也是最困难的一步是修补内核。完成此操作后，配置内核并编译它。请注意，有一个选项可以选择是否编译包含跟踪代码。当不包含跟踪代码进行编译时，生成的内核的运行方式就好像您没有对其应用任何补丁一样。接下来，编译跟踪守护程序和跟踪工具包图形前端，并将它们放在您喜欢的目录中（例如 /usr/bin 或 /usr/local/bin）。使用 LTT 补丁内核重新启动，您就可以开始了。

为了演示工具包的操作，我们跟踪了 10 秒的系统操作。在这 10 秒内，发出了两个命令：对自系统启动以来未访问过的目录（即，不在 dcache 中）执行 dir，以及对一个 10MB 文件执行 bzip2。系统在单用户模式下启动（为了尽可能少地运行应用程序，从而隔离观察到的应用程序的操作），使用修改后的内核。请注意，在跟踪守护程序使用 ioctl 系统调用向内核模块发出 start 命令之前，内核模块不会记录任何事件。发出以下命令以启动跟踪

trace 10 out140

trace 是一个脚本，它接受两个参数：跟踪应持续的秒数和输出文件的基本名称。将生成两个文件：out140.trace 和 out140.proc。前者保存内核模块记录的数据，后者保存跟踪开始时 /proc 的内容。使用这两个文件，我们知道系统在开始跟踪之前是什么样子，以及在跟踪期间发生了什么。因此，我们可以重建系统的行为。

请注意，跟踪守护程序接受许多命令行选项，用于配置内核跟踪模块。例如，可以指定要跟踪的事件和所需的详细程度。还可以指定是否应为 SMP 机器记录 CPU ID。由于 LTT 获取系统调用的调用地址，您可以指定应在哪个调用深度获取此地址，或者该地址属于哪个地址范围。

这是关于 LTT 最有趣的部分，也是它与其他工具的区别所在。即使当前的示例相当简单，也可以同样轻松地生成和分析更精细的跟踪。要在图形前端中查看跟踪，只需键入

traceview out140

traceview 脚本接受一个参数：生成的跟踪的基本名称。然后，它执行跟踪工具包前端，并将 out140.trace 和 out140.proc 文件传递给它。请注意，可以手动调用前端，也可以将其用作命令行工具。在后一种情况下，它可以用于以人类可读的格式转储跟踪内容，或执行详细的跟踪分析。完整选项在 LTT 随附的文档中进行了描述。

图 1 中可以看到前端的示例显示。与往常一样，有菜单、工具栏和数据。为了呈现数据，该工具使用了三个缩略图。第一个是“事件图”，以图形方式呈现事件。在左侧，列出了跟踪期间存在的所有进程。在右侧，可滚动的图形显示了标记正在显示的时间范围的转换。垂直转换意味着控制流已传递给另一个实体。用于转换的垂直线的颜色指示导致转换的事件类型。蓝色表示系统调用，灰色表示陷阱，白色表示中断。水平线表示执行代码所花费的时间属于进程列表中相同高度的实体。绿线表示应用程序代码，橙线表示内核代码。

图 1. LTT 前端

在图 1 中，我们可以看到 sh 正在运行，并且发生了页面错误。控制权转移到内核，内核执行了一些操作，然后将控制权返回给 sh。后者执行了一段时间，然后进行了 wait4 系统调用。这反过来又将控制权返回给内核。经过几次操作后，内核决定执行任务切换，并将控制权交给进程 152 bzip2。当 bzip2 运行时，又发生了一个陷阱。在跟踪结束时，我们可以看到 bzip2 发出了 getpid 系统调用，并在返回后继续执行。

图 2 展示了一个更有趣的情况。为了说明目的，跟踪部分被缩小了；一些图标重叠，但含义相当简单明了。在这里，bzip2 尝试读取某些内容，但内核找不到它。bzip2 开始等待 I/O（输入/输出），内核调度空闲任务。两毫秒后，硬盘发送一个中断信号，表示它已完成读取（那是带有芯片和感叹号的图标，旁边是 14，14 是 IDE 磁盘 IRQ）。然后重新调度 bzip2，停止等待 I/O 并恢复正常执行。在这里，我们可以准确地看到 bzip2 花费了多少时间等待 I/O，以及导致它失去 CPU 控制权并重新获得控制权的确切事件时间顺序。当试图理解任务之间复杂的交互时，这种类型的信息可能至关重要。

图 2. 事件图

第二个缩略图“进程分析”提供了不同的视角，它为我们提供了对跟踪期间存在的每个进程的深入分析以及对系统的全局分析。图 3 展示了此分析的示例。在左侧，显示了进程树。树的顶部是空闲任务（PID 0），它被表示为 全能者。由于空闲任务从不做任何值得跟踪的事情，因此它用于呈现关于整个系统的数据：跟踪开始时间、跟踪结束时间、持续时间、空闲时间（空闲任务被调度为运行）。然后，呈现关键事件的发生次数。请注意，此处给出的一些事件无法通过使用 /proc 中的信息来解释。

图 3. 进程分析

列表 1

当选择 dir 和 bzip2 进程时，将显示列表 1 中的信息。请注意，运行时间（内核调度为拥有 CPU 控制权的时间）与实际执行属于应用程序的代码的时间之间的百分比差异。在 bzip2 的情况下，差距非常小，这准确地描述了 bzip2 作为 CPU 密集型程序的行为；而在 dir 的情况下，它被调度的时间中只有不到一半的时间用于执行自己的代码，其余时间用于内核例程。

另请注意等待 I/O 的时间和运行时间之间的差异。dir 花费在等待 I/O 上的时间比它花费在执行上的时间还要多。bzip2，另一方面，与它处于运行状态的时间相比，花费在等待 I/O 上的时间很少。此信息不是使用系统时钟上的采样来收集的，就像当前通过 /proc 可获得的信息那样。此信息是使用跟踪信息计算出来的，因此是关于观察到的任务的精确信息。

最后但并非最不重要的一点，第三个缩略图呈现了原始跟踪。图 4 展示了原始跟踪的一部分。事件按发生的时间顺序呈现。对于每个事件，都给出了以下信息：发生事件的处理器 CPU-ID、事件类型、发生的准确时间（精确到微秒）、事件所属任务的 PID、内核模块中为完整记录事件而占用的条目大小以及事件的描述。请注意，如何显示发出系统调用的地址。这最终可以用于与从应用程序内部记录的数据相关联，或者仅仅是为了了解代码的哪个部分进行了调用。与 ptrace 等其他跟踪方法不同，除了最小的事件数据收集延迟外，对应用程序的行为没有影响。

图 4. 原始跟踪的一部分

正如本文所示，LTT 是一个用于记录关键系统信息的有效工具。此外，它相当易于使用，并且所呈现的信息对于社区的很大一部分人来说是可访问的。在学术环境中，LTT 可以用于操作系统课程，帮助学生获得使用实时操作系统以及它如何与不同应用程序交互的第一手经验。

鉴于其功能、模块化、可扩展性和最小的开销，我们希望看到跟踪代码很快成为主流 Linux 内核的一部分（可能不是目前处于功能冻结状态的 2.3/2.4，而是在下一个开发分支中）。LTT 的另一个可能的应用，引起了很多兴趣，是将其用作具有 Tripwire 类型功能的安全审计系统的一部分。在撰写本文时，作者知道至少有一个 Linux 发行版计划将 LTT 作为其标准发行版的一部分包含在内。