对 Linux 内核进行压力测试

Robert Williamson （robbiew@us.ibm.com）
软件工程师, Linux Technology Center, IBM
自动软件测试让您可以在一段时间内运行相同的测试，从而确保您所比较的内容具备真正的可比性。在本文中， Linux Test Project 团队的成员们分享了他们对 Linux? 内核进行压力所使用的测试的方法、原理以及脚本和工具。
在对 Linux 内核版本稳定性的测试中，需要明确地声明并证明为什么版本是稳定的或者是不稳定的。 然而还没有被证明和证实当前现有的系统范围内的压力测试可以测试 Linux 内核整体上的稳定性。 本文给出了一个创建系统范围内 Linux 压力测试并证明其结果正确性的方法。不同的 Linux 开发者、 用户和发行版本会使用他们自己的方法来测试内核的稳定性。不过，关于他们决定运行哪些测试、覆盖的代码、 达到的压力级别等的基础信息都没有发布，这就大大降低了结果的价值。
使用实验室的机器以及来自 Linux Test Project 测试套件的测试，我们基于系统资源的利用率统计开发了一个 测试的组合，为系统提供足够的压力。我们对这个组合测试进行了分析，以确定 Linux 内核的哪些部分在测试 执行中得到了使用。然后，我们修改了组合测试，在保持期望的高强度系统压力的同时提高代码覆盖率的百分比。 最终得到的压力测试涵盖了 Linux 内核的足够多部分，有助于稳定性声明，并且有系统使用情况和内核代码覆盖情况的数据来支持它。
这一组合测试方法的四个步骤是：测试选择、系统资源利用率评价、内核代码覆盖分析以及最终的压力测试评价。
选择测试
测试选择包括选择达成两方面目的的测试：
- 测试应该可以得到 CPU（s）、内存、I/O 和网络等主要内核区域的高水平的资源利用率。
- 测试应该充分地覆盖内核代码，以帮助支持自其结果中生成的稳定性声明。
只要有可能，都要使用自动化的或者易于修改的测试，以支持自动操作。自动操作可以使得测试 更快而且可以重复进行，并帮助降低人为错误的风险。选择合适的测试时需要考虑的另一个方面是， 使用可以自由发布结果的应用程序。最好是选择坚决拥护开旁创?敕椒?和/或 GPL 的测试和测试套件，以助于确保 发布过程的简便。
评价系统资源利用率
所选择的测试的组合必须给系统的资源带来足够的压力。Linux 内核的四个主要方面可以影响系统的 响应和执行时间：
- CPU：用于在机器的 CPU（s）上处理数据的时间。
- Memory：用于自真实存储器中读写数据的时间。
- I/O：用于自磁盘存储器读写数据的时间。
- Networking：用于自网络读写数据的时间。
测试设计者应该使用下面这两个著名的且广为应用的开放源代码 Linux 资源监控工具来评价资源利用率水平。 （请参阅本文稍后的 参考资料 以获得下载这些工具的链接。）
- top：由 Albert D. Cahalan 维护着的一个开放源代码工具， 包含于大部分 Linux 发行版本中，可用于当前的 2.4 和 2.6 内核。
- sar：另一个开放源代码工具；它由 Sebastien Godard 维护。 这个工具也包含于大部分 Linux 发行版本中，可用于当前的 2.4 和 2.6 内核。
方法中的系统资源利用率评价阶段通常需要多次尝试才能得到合适的测试组合，并得到期望水平的利用率。 当确定测试组合时，过度利用总是一个至关重要的问题。例如，如果选择的组合过于受 I/O 所限，可能会 导致 CPU 的测试结果不好，反之亦然。方法的这一部分主要是大量的试验和出错，直到所有资源达到期望 水平。
top 工具可用于迅速确定每个测试影响哪个资源（CPU、内存或者 I/O），并实时地显示出它们使用了多少资源。 sar 工具用于收集一段时间内的网络利用率统计数据，并将所有利用率数据的快照记录到一个文件。
当选定一个组合后，测试必须长时间运行以准确评价资源的利用率。测试运行的时间长短取决于每个测试的长度。 假如多个测试同时运行，则时间必须足够长以使得这些测试中最长的那个可以完成。在这个评价过程中，sar 工 具也应该在运行。在评价运行的结论中，您应该收集并评价所有四种资源的利用率水平。
下面的例子显示了 sar 输出的 CPU、内存和网络利用率：
清单 1. sar 的输出示例
10:48:27          CPU     %user     %nice   %system   %iowait     %idle
10:48:28          all      0.00      0.00      0.00      0.00    100.00
10:48:29          all      3.00      0.00      1.00      0.00     96.00
10:48:30          all    100.00      0.00      0.00      0.00      0.00
10:48:31          all    100.00      0.00      0.00      0.00      0.00

02:27:31    kbmemfree kbmemused  %memused kbswpfree kbswpused  %swpused
02:29:31       200948     53228     20.94    530104         0      0.00
02:31:31       199136     55040     21.65    530104         0      0.00
02:33:31       198824     55352     21.78    530104         0      0.00
02:35:31       199200     54976     21.63    530104         0      0.00

02:27:31        IFACE   rxpck/s   txpck/s   rxbyt/s   txbyt/s
02:29:31         eth0    738.79    741.66  76025.55 136941.85
02:31:31         eth0    743.30    744.97  76038.82 136907.77
02:33:31         eth0    744.80    745.02  76135.53 136901.38
02:35:31         eth0    742.35    744.34  75947.45 136864.77
分析内核代码覆盖率
获得足够的内核覆盖率是系统压力测试的另一个职责。尽管所选的测试组合充分地利用了四种主要资源，它 也有可能只是执行了内核的一小部分。因而，您应该对覆盖率进行分析以确保组合可以成为一个系统压力 测试，而不是一个系统负载生成器。当前，有两个开放源代码工具可以帮助进行 Linux 内核的代码覆盖率分析：
- gcov：一个由 Linux Test Project 维护的开放源代码工具。 这个工具分析内核代码的覆盖率，并报告哪些行、函数和分支被覆盖以及它们被访问了多少次。
- lcov：另一个由 IBM 开发，由 Linux Test Project 维护的开放源代码工具。 这个工具由一组构建于基于文本的 gcov 输出之上的 Perl 脚本构成，以实现基于 HTML 的输出。 输出包括覆盖率百分比、图表以及概述页，可以快速浏览覆盖率数据。您可以自 Linux Test Project（LTP）主页 找到这两个工具（参阅 参考资料 以获得链接）。
gcov 模块加载以后，所有运行于系统压力测试组合中的测试都必须执行。尽管原来的系统压力测试可以同时执行， 也应该同时执行，但是这次运行应该是循环进行的。每个测试都应该运行一次直到结束，一个接一个地运行， 不能重复运行任何测试。单个地、循环地运行，是为了减少在同时运行多个系统压力测试时，内核尝试 去平衡它们的负载而导致的不可预知的和无目的的内核代码执行。您应该在最后一个测试运行结束后再进行 gcov 分析。由于最终是要格式化数据以进行分析，所以运行 lcov 工具并?载 gcov 模块。
lcov 工具会生成一棵完整的 HTML 树，其中包含有内核中代码的每一行以及关于每一行执行了 多少次的数据（如果有的话）。这个工具会量化覆盖率数据并生成关于内核中每一部分和 文件覆盖率的百分比数字。下面的例子展示了一个示例性的代码覆盖率输出：
图 1. gcov 输出示例

lcov 维护者定义了“足够的覆盖”（绿色的），因而这个 lcov 示例仅仅是一种评价。不过，所包括的 原始数据让任何浏览者都可以做出他或她自己的判断。在浏览了覆盖率分析后，测试创建者现在可以修改 测试的组合，以改变 和/或 增加所覆盖的代码的数量。
评价最终压力测试
之所以要执行方法中的这最后一步，是为了对系统压力测试进行核实。在一个被认为是稳定的内核上执行压力测试； 通常，发行版本中的内核可以满足这一要求，但不总是如此。要长时间地执行压力测试（推荐至少 24 个小时），同 时运行 sar 工具，原因有以下两点：
- 长时间运行有助于发现组合中的所有问题，否则，在短时间的“取样测试（sniff test）”中这些问题可能会被忽略。
- sar 生成的数据构成以后测试运行中进行比较的基线。
长时间运行结束后，您现在可以基于收集的所有数据来决定这个测试组合是否是系统压力测试的合适候选者。
图 2. 设计过程总结

Linux Test Project 在设计 Linux 内核压力测试脚本 ltpstress.sh 时使用了这一设计方法。 这个应用程序组合了来自 LTP 的测试套件不同方面的多个测试以及内存和网络传输负载生成器。 在执行之前，测试会根据系统中存在多少物理和虚拟内存来调整其总的内存使用情况。这个测试 脚本可以自 LTP 测试套件获得（见 参考资料）。为了确保结果的 准确性，这个脚本创建于受控的实验室条件下。
IBM Linux Technology Center Test 部门使用这个压力测试以及其他工具和测试作为帮助确认 Linux 内核发行版本稳定性的一个相对快速和简便的途径。为帮助确保得到足够的覆盖率，测试既 在实验室条件下也在模拟的用户情形下进行。
参考资料
- 在 Linux Test Project 主页 下载压力测试 shell 脚本以及其他一些实用的测试。
- IBM Linux Technology Center 的使命是 直接与 Linux 开发社区合作以共同促进 Linux 的成功。
- OSDL 的 Linux Kernel Scalable Test Platform（STP） 提供了一个框架，开发者可以通过它使用一个在线的性能和可扩展性套件来 测试内核补丁。
- LTP 压力测试使用的工具包括 top （procps 程序包的一部分）和 sar （systat 的一部分）。
- 此外，LTP 压力测试还充分利用了 GNU 测试覆盖率的程序 gcov 以及它的基于 Perl 的将 gcov 结果转化为 HTML 的工具（HTMLizer）lcov。
- 内核比较：从 2.4 到 2.6 内核开发中的改进 （developerWorks，2004 年 2 月）介绍了使得 2.6 比以前的任何内核更好的工具、 测试和技术。
- 内核比较：2.4 和 2.6 上的 Web 服务（developerWorks，2004 年 2 月） 描述了 IBM Linux Technology Center 的 Web 服务测试工作的成果。
- 在 改善 Linux 内核性能和可伸缩性（developerWorks，2003 年 1 月）中， Linux Technology Center Linux Kernel Performance 团队讨论了如何量化 Linux 性能以 比较一段时间内的测试结果。
- 测试 Linux 的可靠性 （developerWorks，2003 年 12 月） 为 IBM Linux Technology Center 所做的关于 Linux 内核和其他核心 OS 组件的测试结果与分析 提供了文件资料。
- Linux 内核调试器内幕（developerWorks，2003 年 6 月）向您展示了如何追踪 内核的执行并检查它的内存和数据结构。
- 在 developerWorks Linux 专区 可以找到 更多为 Linux 开发者准备的参考资料。
- 购买 Developer Bookstore Linux 区 打折出售的 Linux 书籍。
- 通过 developerWorks Subscription 使用最新的 IBM 工具和中间件来开发和测试您的 Linux 应用程序：您可以自 WebSphere?、DB2?、 Lotus?、Rational?和 Tivoli? 获取 IBM 软件，以及一个可以在 12 个月内使用这些软件的许可，所有的花费都比您想像的要低。
- 自 developerWorks 的 为您的 Linux 应用开发加油提速 专区下载可以运行于 Linux 之上的经过挑选的 developerWorks Subscription 产品免费测试版本，包括 WebSphere Studio Site Developer、WebSphere SDK for Web services、WebSphere Application Server、DB2 Universal Database Personal Developers Edition、Tivoli Access Manager 和 Lotus Domino Server。要更快速地开始上手，请参阅针对各个产品的 how-to 文章和技术支持。
关于作者
Robbie Williamson 是 IBM Linux Technology Center 的专职软件工程师。 他于 2000 年毕业于得克萨斯州立大学，获计算机科学学士学位。在他的职业生涯中， 他当过技术支持人员、验证工程师，以及各种 UNIX 实现的开发人员。Robbie 当前是 Linux Test Project 的维护者之一，可以通过 robbiew@us.ibm.com 与他联系。
注：本文只代表作者的观点，并不代表 IBM 的观点。本文中讨论的研究结果的基础是 一个在实验室环境下创建并测试的方案。这些研究结果可能不会在所有的用户环境中得到，而且， 在那些环境中实现需要进行另外的步骤、配置和性能分析。在这里给出的是原封不动的信息，没有保证、 说明或暗指。本资料不是任何 IBM 产品保证的说明或组成部分。解决方案的实现和证明由实现团队负责。
全文出自 : IBM developerWorks 中国网站