前 言
为什么性能很重要？
如果你曾经坐等计算机完成工作（同时还伴随着敲打桌面、诅咒和好奇：“啥事儿要花这么长的时间？”），你就会知道有个速度快且性能优化良好的计算机系统是多么重要。尽管不是所有的性能问题都能轻易得到解决，但是，了解系统工作缓慢的原因，就意味着有可能采用不同的解决方法：修复软件问题，升级慢速硬件，或者干脆直接把计算机扔出窗外。幸运的是，大多数操作系统，尤其是Linux，都提供了工具用于检测机器运行缓慢的原因。使用一些基础工具，就可以确定系统中哪里速度慢，并修复那些运行效率低的部分。
虽然终端用户非常讨厌速度慢的系统，但对于应用程序开发者而言，他们有着更重要的理由对其程序进行性能调优：程序能够在多个系统上高效运行。如果你编写的程序运行缓慢，又需要快速的计算机，那么你就会排除掉那些拥有慢速计算机的用户。毕竟，并非所有人都具备最新的硬件。性能良好的应用程序能被更多的用户使用，从而带来更大的潜在用户群。另外，如果潜在用户必须在两个具有相似功能的不同应用程序中进行选择，他们通常会选择运行更快或效率更高的那一个。最后，长期使用的应用程序很可能会经过几轮优化，以便适应不同的用户需求，因此，关键是了解如何追踪性能问题。
如果你是系统管理员，那么对系统用户来说，你就有责任使系统在运行时保持适当的性能水平。若系统运行缓慢，用户就会抱怨。如果你能迅速找到并解决问题，他们就会停止抱怨。还有让人高兴的是，如果你能通过调整应用程序或操作系统来解决问题（从而使他们不用购买新的硬件），那么公司的会计就会很开心。知道如何有效使用性能工具就意味着，在性能问题上需要花费的时间是有区别的：几天，还是几个小时。
Linux：优势和劣势
如果你使用Linux，维护它并用其进行开发，你就会处于一种奇特但良好的处境中。你能访问和接触的源代码、开发者和邮件列表是前所未有的，通常，这些邮件列表中会记录着多年前的设计决策。Linux是发现和修复性能问题的优良环境。与之形成鲜明对比的是专有环境，在这种环境下，很难直接接触到软件开发者，同时也很难找到大多数设计决策讨论的书面记录，而访问源代码则几乎是不可能的。除了是一个高效环境外，Linux还具备强大的性能工具，使你能发现并修复性能问题。这些工具可以与那些专门的工具相媲美。
即使有着这些令人印象深刻的优势，Linux生态环境还是需要征服一些挑战。Linux性能工具分散性很强。不同的小组根据不同的目标开发工具，其结果就是，这些工具不一定集中在一个地方。有些工具已经包含在标准的Linux发行版中，如Red Hat、SUSE和Debian；而有些工具则分散在整个互联网上。如果你尝试解决一个性能问题，首先要做的是了解你需要的工具是否存在，然后再设法找到它们。由于没有哪一个Linux性能工具能够独立解决所有类型的性能问题，因此，还必须了解如何使用多个工具来确定问题出在哪儿。这可能需要点技巧，但是经验会让它变得容易些。虽然大多数常见的方法会有文档记录，但是Linux没有任何指南来告诉你如何整合性能工具以实际解决问题。很多工具或子系统都有调整特定子系统的信息，但是却没有说明如何将它们与其他工具一起使用。许多性能问题涉及系统的多个部分，如果不知道如何同时使用多个工具，就无法解决这些问题。
本书对你有何帮助？
从本书可以学到很多东西，包括：
各种性能工具能测量什么。
怎样使用每一种工具。
如何将工具组合起来解决性能问题。
如何从性能欠佳的系统入手，查明问题。
如何利用学到的方法来解决现实世界的问题（案例研究）。
利用本书提供的方法，你可以将组织严密的问题诊断说明发送给最初的开发人员。运气好的话，他们会帮你把问题解决掉。
为什么要学习使用性能工具？
为什么要花精力去调整系统或应用程序？
性能良好的系统能用更少的资源完成更多的工作。
性能良好的应用程序能在更老旧的硬件上运行。
性能良好的桌面系统能节约用户时间。
性能良好的服务器能为更多用户提供更高质量的服务。
了解如何高效地诊断性能问题，就可以用正确的方法来解决问题，而不是盲目地采取措施并希望它能起作用。如果你是应用程序开发者，就意味着你能快速发现是哪段代码引发了问题；如果你是系统管理员，就意味着你可以找到系统的哪个部分需要调整或升级，而不用浪费时间且徒劳无功地尝试各种解决方案；如果你是终端用户，你就能发现哪些应用程序速度滞后，并将问题报告给开发者（或者必要时更新你的硬件）。
Linux现在正处于十字路口。高效系统的大部分功能已经完成，对Linux及其应用程序来说，下一步就是调优以便与其他操作系统的性能进行竞争，并超越它们。有些性能优化早已开始。例如，SAMBA、Apache和TUX Web服务器项目已经花费了大量的时间，对系统和代码进行调整和优化。其他性能优化（如能显著提升线程性能的本地POSIX线程库（NPTL），以及能改善应用程序启动时间的对象预链接）正开始被整合到Linux中。Linux提升性能的时机已然成熟。
我也能进行性能调整吗？
性能优化最大的优点是：你无须了解整个应用程序或系统的详细信息，就可以有效地修复性能问题。性能优化所需的技术与典型应用程序开发者的技术是相辅相成的。
你需要的是细心和耐心。追踪并解决性能问题与其说需要的是程序员，还不如说需要的是侦探。发现并修复这些问题令人兴奋。开始的时候，系统会很糟糕。但是，当你找到原因，并将其连根拔掉后，运气好的话，系统运行速度能达到原来的两倍。完美！
要达到完美，就必须了解强大但有时又颇令人迷惑的Linux性能工具。这需要花些功夫，但最后你会发现一切都是值得的。性能工具能向你展示超乎你预期的应用程序和系统的方方面面。
谁应该读这本书？
本书帮助Linux软件开发人员、系统管理员和终端用户利用Linux性能工具在给定系统中找出性能问题。初级性能研究员能学习性能调查和分析的基础知识。中高级性能研究员，尤其是那些已具备其他专有操作系统性能经验的，能学习那些与他们已经熟悉的系统中的命令等价的Linux命令。
软件开发人员能学习如何精确定位引发性能问题的代码行。对系统进行性能调优的系统管理员，则能学习能说明系统变慢原因的工具，然后利用这些信息调整系统。最后，终端用户（虽然不是本书的主要对象）可以学习必要的基本技术以找出哪些应用程序正在消耗系统资源。
本书是如何组织的？
本书向具备不同程度经验的读者教授如何发现并修复性能问题。为了实现这个目标，读者可以挑选本书不同的部分进行阅读，而不必直接看完整本书。
第1章介绍查找性能问题的基本方法。其中包含一系列非Linux特有的技巧和建议，它们已被证明对追踪性能问题是有用的。这些指南是性能问题查找的常用建议，可以用于追踪任何类型计算机系统的性能问题。
第2章到第8章（本书主要部分）覆盖了各种工具，可用于度量Linux系统中不同的性能统计信息。这些章解释了不同工具度量的对象以及如何调用它们，并为每个工具提供了使用示例。每一章演示的工具分别度量了Linux系统的不同部分，如系统CPU、用户CPU、内存、网络I/O以及磁盘I/O。如果一种工具涉及多个子系统，它就会出现在多个章节中。每章都会介绍多个工具，但在给定章节中，只会描述适合特定子系统的对应的工具选项。描述格式如下：
1. 概述—这部分解释了工具度量的对象及其使用方法。
2. 性能工具选项—这里不是对工具文档的老调重弹。相反，它说明了哪些选项与当前主题相关，以及这些选项的含义是什么。比如，有些性能工具手册指明了工具度量的事件，但是却没有解释这些事件的含义。本书则说明了事件含义，以及事件与当前子系统的关系。
3. 示例—这部分为度量性能统计信息的工具提供一个或多个例子，展示了调用的工具以及生成的所有输出。
第9章针对Linux，它介绍了面对低性能Linux系统时要采取的一系列步骤，以及如何正确使用之前描述的Linux性能工具来查明产生性能问题的原因。如果你想从行为异常的Linux入手，仅仅只是进行问题诊断，而不想了解工具的详情，那么这一章就是最有用的一章。
第10章到第12章为案例研究，将前面章节描述的方法和工具结合起来，解决现实世界的问题。案例研究突出了用于发现和修复各类性能问题的Linux性能工具，包括以下几类： CPU密集型应用程序，延迟敏感型应用程序，以及I/O密集型应用程序。
第13章对性能工具进行了总结，并展望了Linux性能调优工具的发展机遇。
本书有两个附录：附录A用一个表格收录了书中介绍的性能工具，给出了每一种工具最新版本的URL，并指明了每种特定的工具都由哪些Linux发行版支持；附录B说明了如何安装oprofile，该工具包含在几个主要的Linux发行版中，其功能强大，但安装困难。
致 谢 Acknowledgements
首先，感谢Prentice Hall的优秀员工，他们是：Jill Harry，Brenda Mulligan，Gina Kanouse以及Keith Cline。
其次，感谢所有审阅了本书初稿，提出并添加了有价值的技术意见和建议的人，他们是：Karel Baloun，Joe Brazea，Bill Carr，Jonathan Corbet，Matthew Crosby，Robert Husted，Paul Lussier，Scott Mann，Bret Strong和George Vish II。我还想感谢所有向我传授性能知识并允许我进行Linux优化的人，即使当时Linux优化的价值还不明朗，他们是：John Henning，Greg Tarsa，Dave Stanley，Greg Gaertner，Bill Carr和全体BPE工具组（他们对我在Linux方面的工作给予了支持与鼓励）。
同时，我还要感谢SPEC的各位，他们的引导使我了解到，为什么做好基准测试程序会对整个行业有帮助。我尤其要感谢的是Kaivalya Dixit，他对基准测试的赤诚令人难忘。
感谢所有帮助我在Carcassonne和Settlers of Catan等游戏面前保持理智的人们，他们是：Sarah Ezolt，Dave和Yoko Mitzel，Tim和Maureen Chorma，Ionel和Marina Vasilescu，Joe Doucette，Jim Zawisza。
最后，感谢我的家人：Sasha和Mischief，他们总是提醒我，散步或使用牙线的时间不能省；Ron和Joni Elias，他们总是让我开心；Russell、Carol和Tracy Ezolt，他们对我的工作予以支持和鼓励；还有我的妻子Sarah，她是世界上最理解和支持我的人。
目录
第1章 性能追踪建议
第2章 性能工具：系统CPU
第3章 性能工具：系统内存
第4章 性能工具：特定进程CPU 61
4.1 进程性能统计信息 61
4.1.1 内核时间vs.用户时间 61
4.1.2 库时间vs.应用程序时间 62
4.1.3 细分应用程序时间 62
4.2 工具 62
4.2.1 time 62
4.2.2 strace 65
4.2.3 ltrace 67
4.2.4 ps（进程状态） 70
4.2.5 ld.so（动态加载器） 72
4.2.6 gprof 74
4.2.7 oprofile（II） 77
4.2.8 语言：静态（C和C++）vs.动态（Java和Mono） 82
4.3 本章小结 82
第5章 性能工具：特定进程内存 83
5.1 Linux内存子系统 83
5.2 内存性能工具 84
5.2.1 ps（II） 84
5.2.2 /proc/<PID> 85
5.2.3 memprof 88
5.2.4 valgrind（cachegrind） 90
5.2.5 kcachegrind 95
5.2.6 oprofile（III） 99
5.2.7 ipcs 103
5.2.8 动态语言（Java和Mono） 107
5.3 本章小结 107
第6章 性能工具：磁盘I/O 108
6.1 磁盘I/O介绍 108
6.2 磁盘I/O性能工具 109
6.2.1 vmstat（III） 109
6.2.2 iostat 113
6.2.3 sar（III） 115
6.2.4 lsof（列出打开文件） 117
6.3 缺什么 119
6.4 本章小结 119
第7章 性能工具：网络 120
7.1 网络I/O介绍 120
7.1.1 链路层的网络流量 121
7.1.2 协议层网络流量 122
7.2 网络性能工具 122
7.2.1 mii-tool（媒体无关接口工具） 123
7.2.2 ethtool 123
7.2.3 ifconfig（接口配置） 124
7.2.4 ip 126
7.2.5 sar（IV） 127
7.2.6 gkrellm 129
7.2.7 iptraf 131
7.2.8 netstat 132
7.2.9 etherape 134
7.3 本章小结 136
第8章 实用工具：性能工具助手 137
8.1 性能工具助手 137
8.1.1 自动执行和记录命令 138
8.1.2 性能统计信息的绘图与分析 138
8.1.3 调查应用程序使用的库 138
8.1.4 创建和调试应用程序 138
8.2 工具 139
8.2.1 bash 139
8.2.2 tee 140
8.2.3 script 141
8.2.4 watch 142
8.2.5 gnumeric 144
8.2.6 ldd 146
8.2.7 objdump 146
8.2.8 GNU调试器（gdb） 147
8.2.9 gcc（GNU编译器套件） 149
8.3 本章小结 152
第9章 使用性能工具发现问题 153
9.1 并非总是万灵药 153
9.2 开始追踪 153
9.3 优化应用程序 154
9.3.1 内存使用有问题？ 154
9.3.2 启动时间有问题？ 154
9.3.3 加载器引入延迟了吗？ 154
9.3.4 CPU使用（或完成时长）有问题？ 155
9.3.5 应用程序的磁盘使用有问题？ 155
9.3.6 应用程序的网络使用有问题？ 155
9.4 优化系统 155
9.4.1 系统是受CPU限制的吗？ 156
9.4.2 单个进程是受CPU限制的吗？ 157
9.4.3 一个或多个进程使用了大多数的系统CPU吗？ 157
9.4.4 一个或多个进程使用了单个CPU的大多数时间？ 157
9.4.5 内核服务了许多中断吗？ 157
9.4.6 内核的时间花在哪儿了？ 158
9.4.7 交换空间的使用量在增加吗？ 158
9.4.8 系统是受I/O限制的吗？ 158
9.4.9 系统使用磁盘I/O吗？ 158
9.4.10 系统使用网络I/O吗？ 158
9.5 优化进程CPU使用情况 159
9.5.1 进程在用户还是内核空间花费了时间？ 160
9.5.2 进程有哪些系统调用，完成它们花了多少时间？ 160
9.5.3 进程在哪些函数上花了时间？ 160
9.5.4 热点函数的调用树是怎样的？ 160
9.5.5 Cache缺失与热点函数或源代码行是对应的吗？ 161
9.6 优化内存使用情况 161
9.6.1 内核的内存使用量在增加吗？ 161
9.6.2 内核使用的内存类型是什么？ 161
9.6.3 特定进程的驻留集大小在增加吗？ 162
9.6.4 共享内存的使用量增加了吗？ 163
9.6.5 哪些进程使用了共享内存？ 163
9.6.6 进程使用的内存类型是什么？ 163
9.6.7 哪些函数正在使用全部的栈？ 163
9.6.8 哪些函数的文本大小最大？ 163
9.6.9 进程使用的库有多大？ 164
9.6.10 哪些函数分配堆内存？ 164
9.7 优化磁盘I/O使用情况 164
9.7.1 系统强调特定磁盘吗？ 165
9.7.2 哪个应用程序访问了磁盘？ 165
9.7.3 应用程序访问了哪些文件？ 165
9.8 优化网络I/O使用情况 165
9.8.1 网络设备发送/接收量接近理论极限了吗？ 166
9.8.2 网络设备产生了大量错误吗？ 167
9.8.3 设备上流量的类型是什么？ 167
9.8.4 特定进程要为流量负责吗？ 167
9.8.5 流量是哪个远程系统发送的？ 167
9.8.6 哪个应用程序套接字要为流量负责？ 167
9.9 尾声 168
9.10 本章小结 168
第10章 性能追踪1：受CPU限制的应用程序（GIMP） 169
10.1 受CPU限制的应用程序 169
10.2 确定问题 170
10.3 找到基线/设置目标 170
10.4 为性能追踪配置应用程序 171
10.5 安装和配置性能工具 172
10.6 运行应用程序和性能工具 172
10.7 分析结果 173
10.8 转战网络 177
10.9 增加图像缓存 179
10.10 遇到（分片引发的）制约 179
10.11 解决问题 180
10.12 验证正确性 181
10.13 后续步骤 181
10.14 本章小结 182
第11章 性能追踪2：延迟敏感的应用程序（nautilus） 183
11.1 延迟敏感的应用程序 183
11.2 确定问题 184
11.3 找到基线/设置目标 184
11.4 为性能追踪配置应用程序 186
11.5 安装和配置性能工具 186
11.6 运行应用程序和性能工具 187
11.7 编译和检查源代码 191
11.8 使用gdb生成调用跟踪 193
11.9 找到时间差异 197
11.10 尝试一种可能的解决方案 197
11.11 本章小结 199
第12章 性能追踪3：系统级迟缓（prelink） 200
12.1 调查系统级迟缓 200
12.2 确定问题 200
12.3 找到基线/设置目标 201
12.4 为性能追踪配置应用程序 204
12.5 安装和配置性能工具 204
12.6 运行应用程序和性能工具 205
12.7 模拟解决方案 209
12.8 报告问题 212
12.9 测试解决方案 214
12.10 本章小结 215
第13章 性能工具：下一步是什么 216
13.1 Linux工具的现状 216
13.2 Linux还需要什么样的工具 216
13.2.1 漏洞1：性能统计信息分散 217
13.2.2 漏洞2：没有可靠并完整的调用树 217
13.2.3 漏洞3：I/O的归因 218
13.3 Linux的性能调优 218
13.3.1 可用的源代码 218
13.3.2 容易联系开发者 218
13.3.3 Linux还年轻 219
13.4 本章小结 219
附录A 性能工具的位置 220
附录B 安装oprofile 222
