描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121267925
大型企业服务、云计算和虚拟计算系统都面临着严重的性能挑战。如今，国际知名的性能专家Brendan Gregg将业界验证的方法、工具和指标融汇在一起，足以应对*为复杂环境的分析和调优工作。《性能之巅》着力讲述Linux和Unix的性能，但所论述的性能问题适用于所有操作系统。你将洞察到系统是如何工作与执行的，学习到如何分析和改进系统和应用程序性能的方法。
Gregg书中的示例都通过裸机和云端虚拟机做演示，所运行的系统包括基于Linux的Ubuntu、Fedora、CentOS和基于Illumos的Joyent SmartOS和OminiTI OmniOS。无论是CPU、内存、磁盘与网络的“传统”分析，还是像云计算和动态跟踪这类新领域，本书系统地覆盖了现代系统性能的方方面面。这本书还帮助你识别复杂性能中“未知的未知”——在你不知道的地方出现的瓶颈。本书还收纳了一个详实的研究实例，向你展示一个真实云计算问题是如何从头到尾做分析的。
□ 现代性能分析与调优：术语、概念、模型、方法和技术
□ 动态跟踪技术与工具，收录DTrace、SystemTap和Perf示例
□ 内核内幕：揭示OS在做什么
□ 如何使用系统观测工具、接口和框架
□ 理解和监控应用程序性能
□ 优化CPU：处理器、核、硬件线程、缓存、互联与内核调度
□ 内存优化：虚拟内存、换页、交换、内存架构、总线、地址空间与分配器
□ 文件系统I/O，包括缓存
□ 存储设备/控制器、磁盘I/O工作负载、RAID，以及内核I/O
□ 网络相关性能问题：协议、套接字、网卡和物理连接。
□ OS和基于硬件虚拟化的性能实现，以及云计算所遇到的新问题
□ 基准测试：如何得到精确的结果并避免一般性的错误
《性能之巅：洞悉系统、企业与云计算》是企业和云计算环境运维人员的指导：系统管理员、网络管理员、数据库管理员和Web管理员、开发工程师以及其他专业人员。对于新接触性能优化的学生等人员，本书还提供了饱含Gregg丰富的教学经验的练习题目。
大型网络、云计算、大数据和虚拟计算机系统的快速部署已经为性能优化带来了新的挑战。本书为此提供了解决方案。国际知名的性能优化专家Brendan Gregg汇集了***的技术和工具来分析调优大型网络或云计算的环境。本书的内容包括现代化的性能分析和容量规划；与云计算相关的新性能和可靠性挑战；方法、概念、术语、工具和指标；负载与结构问题的权衡；调整操作系统、CPU、内存、文件系统、磁盘、网络和总线；调整虚拟系统；性能相关的编程语言问题，对C、 C 、 Java和node.js编写的应用程序分析。
第1章 绪论 1
1.1 系统性能 1
1.2 人员 2
1.3 事情 3
1.4 视角 4
1.5 性能是充满挑战的 4
1.5.1 性能是主观的 4
1.5.2 系统是复杂的 5
1.5.3 可能有多个问题并存 6
1.6 延时 6
1.7 动态跟踪 7
1.8 云计算 8
1.9 案例研究 8
1.9.1 缓慢的磁盘 9
1.9.2 软件变更 10
1.9.3 更多阅读 12
第2章 方法 13
2.1 术语 14
2.2 模型 14
2.2.1 受测系统 15
2.2.2 排队系统 15
2.3 概念 16
2.3.1 延时 16
2.3.2 时间量级 17
2.3.3 权衡三角 18
2.3.4 调整的影响 19
2.3.5 合适的层级 19
2.3.6 性能建议的时间点 20
2.3.7 负载vs.架构 20
2.3.8 扩展性 21
2.3.9 已知的未知 22
2.3.10 指标 23
2.3.11 使用率 24
2.3.12 饱和度 25
2.3.13 剖析 26
2.3.14 缓存 26
2.4 视角 28
2.4.1 资源分析 28
2.4.2 工作负载分析 29
2.5 方法 30
2.5.1 街灯反方法 31
2.5.2 随机变动反方法 32
2.5.3 责怪他人反方法 32
2.5.4 ad hoc核对清单法 33
2.5.5 问题陈述法 33
2.5.6 科学法 34
2.5.7 诊断循环 35
2.5.8 工具法 35
2.5.9 USE方法 36
2.5.10 工作负载特征归纳 42
2.5.11 向下挖掘分析 43
2.5.12 延时分析 44
2.5.13 R方法 45
2.5.14 事件跟踪 45
2.5.15 基础线统计 47
2.5.16 静态性能调整 47
2.5.17 缓存调优 47
2.5.18 微基准测试 48
2.6 建模 49
2.6.1 企业vs.云 49
2.6.2 可视化识别 49
2.6.3 Amdahl扩展定律 51
2.6.4 通用扩展定律 52
2.6.5 排队理论 52
2.7 容量规划 56
2.7.1 资源极限 56
2.7.2 因素分析 58
2.7.3 扩展方案 58
2.8 统计 59
2.8.1 量化性能 59
2.8.2 平均值 60
2.8.3 标准方差、百分位数、中位数 61
2.8.4 变异系数 62
2.8.5 多重模态分布 62
2.8.6 异常值 63
2.9 监视 63
2.9.1 基于时间的规律 63
2.9.2 监测产品 65
2.9.3 启动以来的信息统计 65
2.10 可视化 65
2.10.1 线图 65
2.10.2 散点图 66
2.10.3 热图 67
2.10.4 表面图 68
2.10.5 可视化工具 69
2.11 练习 70
2.12 参考 70
第3章 操作系统 72
3.1 术语 72
3.2 背景 73
3.2.1 内核 73
3.2.2 栈 76
3.2.2 中断和中断线程 77
3.2.4 中断优先级 78
3.2.5 进程 78
3.2.6 系统调用 80
3.2.7 虚拟内存 82
3.2.8 内存管理 82
3.2.9 调度器 83
3.2.10 文件系统 84
3.2.11 缓存 86
3.2.12 网络 87
3.2.13 设备驱动 87
3.2.14 多处理器 87
3.2.15 抢占 88
3.2.16 资源管理 88
3.2.17 观测性 89
3.3 内核 89
3.3.1 UNIX 90
3.3.2 基于Solaris 90
3.3.3 基于Linux 93
3.3.4 差异 95
3.4 练习 96
3.5 参考 96
第4章 观测工具 98
4.1 工具类型 98
4.1.1 计数器 99
4.1.2 跟踪 100
4.1.3 剖析 101
4.1.4 监视（sar） 102
4.2 观测来源 103
4.2.1 /proc 103
4.2.2 /sys 108
4.2.3 kstat 109
4.2.4 延时核算 111
4.2.5 微状态核算 112
4.2.6 其他的观测源 112
4.3 DTrace 114
4.3.1 静态和动态跟踪 115
4.3.2 探针 116
4.3.3 provider 116
4.3.4 参数 117
4.3.5 D语言 117
4.3.6 内置变量 118
4.3.7 action 118
4.3.8 变量类型 119
4.3.9 单行命令 121
4.3.10 脚本 121
4.3.11 开销 122
4.3.12 文档和资源 123
4.4 SystemTap 124
4.4.1 探针 124
4.4.2 tapset 125
4.4.3 action和内置变量 125
4.4.4 示例 125
4.4.5 开销 127
4.4.6 文档和资源 128
4.5 perf 128
4.6 观测工具的观测 129
4.7 练习 130
4.8 参考 130
第5章 应用程序 131
5.1 应用程序基础 131
5.1.1 目标 132
5.1.2 常见情况的优化 133
5.1.3 观测性 134
5.1.4 大O标记法 134
5.2 应用程序性能技术 135
5.2.1 选择I/O尺寸 135
5.2.2 缓存 136
5.2.3 缓冲区 136
5.2.4 轮询 136
5.2.5 并发和并行 137
5.2.6 非阻塞I/O 139
5.2.7 处理器绑定 139
5.3 编程语言 140
5.3.1 编译语言 140
5.3.2 解释语言 141
5.3.3 虚拟机 142
5.3.4 垃圾回收 142
5.4 方法和分析 143
5.4.1 线程状态分析 143
5.4.2 CPU剖析 146
5.4.3 系统调用分析 148
5.4.4 I/O剖析 154
5.4.5 工作负载特征归纳 155
5.4.6 USE方法 155
5.4.7 向下挖掘法 156
5.4.8 锁分析 156
5.4.9 静态性能调优 159
5.5 练习 160
5.6 参考 161
第6章 CPU 162
6.1 术语 163
6.2 模型 163
6.2.1 CPU架构 163
6.2.2 CPU内存缓存 164
6.2.3 CPU运行队列 165
6.3 概念 165
6.3.1 时钟频率 165
6.3.2 指令 166
6.3.3 指令流水线 166
6.3.4 指令宽度 167
6.3.5 CPI，IPC 167
6.3.6 使用率 167
6.3.7 用户时间/内核时间 168
6.3.8 饱和度 168
6.3.9 抢占 168
6.3.10 优先级反转 169
6.3.11 多进程，多线程 169
6.3.12 字长 170
6.3.13 编译器优化 171
6.4 架构 171
6.4.1 硬件 171
6.4.2 软件 179
6.5 方法 184
6.5.1 工具法 184
6.5.2 USE方法 185
6.5.3 负载特征归纳 186
6.5.4 剖析 187
6.5.5 周期分析 188
6.5.6 性能监控 189
6.5.7 静态性能调优 189
6.5.8 优先级调优 189
6.5.9 资源控制 190
6.5.10 CPU绑定 190
6.5.11 微型基准测试 191
6.5.12 扩展 191
6.6 分析 192
6.6.1 uptime 192
6.6.2 vmstat 194
6.6.3 mpstat 195
6.6.4 sar 197
6.6.5 ps 198
6.6.6 top 199
6.6.7 prstat 200
6.6.8 pidstat 201
6.6.9 time和ptime 202
6.6.10 DTrace 203
6.5.11 SystemTap 209
6.6.12 perf 209
6.6.13 cpustat 215
6.6.14 其他工具 216
6.6.15 可视化 216
6.7 实验 219
6.7.1 Ad Hoc 219
6.7.2 SysBench 220
6.8 调优 220
6.8.1 编译器选项 221
6.8.2 调度优先级和调度类 221
6.8.3 调度器选项 221
6.8.4 进程绑定 223
6.8.5 独占CPU组 224
6.8.6 资源控制 224
6.8.7 处理器选项（BIOS调优） 224
6.9 练习 225
6.10 参考资料 226
第7章 内存 228
7.1 术语 229
7.2 概念 229
7.2.1 虚拟内存 230
7.2.2 换页 230
7.2.3 按需换页 231
7.2.4 过度提交 233
7.2.5 交换 233
7.2.6 文件系统缓存占用 233
7.2.7 使用率和饱和度 234
7.2.8 分配器 234
7.2.9 字长 234
7.3 架构 234
7.3.1 硬件 235
7.3.2 软件 239
7.3.3 进程地址空间 244
7.4 方法 248
7.4.1 工具法 249
7.4.2 USE方法 249
7.4.3 使用特征归纳 250
7.4.4 周期分析 25
前言
有已知的已知；有些事情我们知道自己知道。
我们也知道有已知的未知；这是指我们知道有些事情自己不知道。
但是还有未知的未知——有些事情我们不知道自己不知道。
——美国国防部长 唐纳德拉姆斯菲尔德 2002年2月12日
虽然上述的发言在新闻发布会上引来了记者的笑声，但是它总结出了一个重要的原则，适用于任何如地缘政治般复杂的技术系统：性能问题可能来源于任何地方，包括系统中因你一无所知而不曾检查的地方（未知的未知）。本书将揭示许多这样的领域，并为其分析提供方法和工具。
关于本书
欢迎来到《系统性能：企业与云计算》！本书以操作系统为背景讲解操作系统和应用程序的性能，针对企业环境和云计算环境编写而成。本书的目的是帮助你更好地利用自己的系统。
当你的工作与持续开发的应用程序软件为伍，你可能会认为内核经过几十年的开发调整，操作系统的性能已是一个解决了的问题了，但事情并非如此！操作系统是一个复杂的软件体，管理着各种不断变化的物理设备，应对着不同的新应用程序的工作负载。内核也在持续地发展，不断增加新的特性以提高特定的工作负载的性能，随着系统继续扩展，所遇到的瓶颈被逐一移除。改进操作系统性能需要不断的分析和努力，这样才能带来性能的持续提升。应用程序的性能也可以在操作系统的背景下做分析，此点本书也覆盖了。
操作系统范围
本书的重点就是系统性能的研究，所用的工具、示例，乃至可调的参数都是Linux系统和基于Solaris的系统里的。除非注明，在示例中所用到的操作系统的特定发行版并不重要。基于Linux的系统，示例所含的范围从各种裸机系统到虚拟化的运行着Ubuntu、Fedora或CentOS的云租户。对于基于Solaris的系统，示例也是裸机系统以及基于Joyent SmartOS或OmniTI OmniOS的虚拟化系统。SmartOS和OmniOS用的是开源的illumos内核：这是OpenSolaris内核的一个活跃的分支，所基于的开发版本后来成为了Oracle Solaris 11。
覆盖两种不同的操作系统给每位读者提供了一个新的视角，帮助读者可以更深入地理解这两种系统的特点，尤其是二者设计不同的地方，并且可以帮助读者更全面地理解性能，而不只局限于某个单一的系统，这样读者可以更加客观地思考操作系统。
过去，开发者对基于Solaris的系统做了较多的性能工作，让其成为某些情形下更好的选择。Linux的情况也有了很大的改观。在十多年前的System Performance Tuning [Musumeci 02]出版时，作者同时介绍了Linux和Solaris，但是更侧重后者。作者的理由是：
Solaris机器更多地注重性能。我怀疑这是因为Sun的系统平均来说要比同等的Linux系统贵得多。这带来的结果是，花大价钱的人更倾向于挑剔性能，因此Solaris在这个领域做的工作更多。如果你的Linux机器性能不够好，你可以再买一台并对工作负载做切分——毕竟便宜。如果花了你几百万美金的Ultra Enterprise 10000性能不好，你公司也因此会每时每刻都在承受不小的损失，你会打Sun的服务电话寻求答案。
上面这段解释了Sun注重性能的历史传统：Solaris的利润是与硬件销售绑定的，不少资金频繁地花在性能的提升上。Sun需要，也付得起，雇用超过100名的全职性能工程师（包括我自己和穆苏梅奇（Musumeci Gian））。与Sun的内核工程师团队一起，我们在系统性能领域取得了许多进展。
Linux在性能工作和观测工具这一块走了很长的路。尤其是现在，Linux正在应用到大型的云计算环境之中。本书涵盖了许多Linux的性能特性，这些特性都是在过去五年里开发起来的。
其他内容
示例会包括性能工具的截屏，这样做不仅是为了显示数据，而且是为了对可用的数据类型做阐释。一般来说工具展现数据的方式更为直观，很多UNIX早期风格的工具生成的输出都是相近的，意义常常可以不言自明。这意味着屏幕截图可以很好地传递这些工具的意图，只有某些需要极少的附加说明。（如果一款工具需要费力的说明，这就很可能是一个失败的设计！）
技术的历史演化所展示出的洞察力能深化你的理解，这些都会在书中一一讲到。除此之外，了解一些这个行业的重要人物也是很用的（这个世界很小）：你很可能会碰到他们或者接触到他们在性能领域的工作成果。附录G是一张“谁是谁”的清单。
什么未提及
本书着眼于性能。如果你要执行所有的示例任务，有时可能需要做些系统管理员的工作，包括软件的安装或编译（这些本书没有提及）。尤其是在Linux上，你需要安装sysstat软件包，还有很多书中用到的工具也有同样的要求。
书中关于操作系统内部总结的内容会在单独的篇章中有详尽的介绍。对性能分析高阶专题的概述，是为了让你知道这些内容的存在，以便在需要的时候依靠其他的知识来源做进一步的学习。
本书的结构
本书的内容如下。
第1章，绪论。介绍系统性能分析，总结关键的概念并展示了与性能相关的一些例子。
第2章，方法。性能分析和调整的背景知识，包括术语、概念、模型、观测和实验的方法，容量规划，分析，以及统计。
第3章 ，操作系统。总结了内核内部的性能分析。对于解释和理解操作系统行为，这些是必要的背景知识。
第4章，观测工具。介绍系统观测工具的类型，以及构建这些工具所基于的接口和框架。
第5章，应用程序。讨论了应用程序性能的内容，并从操作系统的角度观测应用程序。
第6章，CPU。内容包括处理器、硬件线程、CPU缓存、CPU互联，以及内核调度。
第7章，内存。虚拟内存、换页、swapping、内存架构、总线、地址空间和内存分配器。
第8章，文件系统。文件系统I/O性能，包括涉及的不同缓存。
第9章，磁盘。内容包括存储设备、磁盘I/O工作负载、存储控制器、RAID，以及内核I/O子系统。
第10章，网络。 网络协议、套接字、接口，以及物理连接。
第11章，云计算。介绍广泛应用于云计算的操作系统级和硬件级虚拟化方法，以及这些方法的性能开销、隔离和观测特征。
第12章，基准测试。介绍如何精确地做基准测试，如何解读别人的基准测试结果。这是一个棘手的话题，这一章会告诉你怎样避免常见的错误，并试图理解这一点。
第13章，案例研究。包含一个系统性能的案例研究，讲述了如何从始至终地分析一个真实的云客户案例。
第1～4章提供了必要的背景知识。阅读完这几章后，你可以根据需要参考本书的其余部分。
第13章的写法是不同的，该章用讲故事的方法描绘了性能工程师的工作场景。如果你是性能分析的新手，想先了解个大概，可能会想先读读这一章，当读完其他章的时候还可以再次重温。
作为未来的参考
通过着力于系统性能分析的背景知识与方法，本书的编写经得起推敲。
为了做到这一点，许多章都被分为了两个部分。一部分的内容组成是术语、概念和方法（一般附有标题），这些内容许多年后应该还依然中肯适用。另一部分的内容是前一部分如何实现的示例：架构、分析工具，还有可调参数。这部分内容即便有朝一日淘汰了，作为示例讲解也是依然有用的。
跟踪示例
我们经常需要深入探索操作系统，这项工作要用到内核跟踪工具。有很多这样的工具，它们所针对的开发阶段也各不相同，例如，ftrace、perf、DTrace、SystemTap、LTTng和ktap。其中有一款工具被选择用在了绝大多数的跟踪示例中，并在Linux和基于Solaris的系统上都有演示：它就是DTrace。该工具提供了这些示例所需要的功能，并且关于它还有大量的外部参考资料，包括可以用于高级跟踪的脚本。
你可能需要或愿意选用别的跟踪工具，这很好。DTrace的示例展示的是你能向系统掷出的问题。这些问题以及提出这些问题的方法，常常才是*困难的。
目标受众
本书的目标受众主要是系统管理员以及企业与云计算环境的运维工程师。所有需要了解操作系统和应用程序性能的开发人员、数据库管理员和网站管理员都适合参阅本书。
作为云计算提供商的首席性能工程师，我的工作会与支持人员和顾客打交道，他们经常要承受巨大时间压力去解决多个性能问题。对于许多人来说，性能并不是他们的主要工作，但却需要了解足够多的性能知识来解决手头的问题。因为清楚读者学习本书的时间会非常有限，我将本书编写得尽可能简洁。但不会简短：有太多知识需要覆盖才能保证你是准备好了的。
另一个受众群体是学生：本书适合作为系统性能课程的补充教材。在本书的编写期间（以及开始动笔的多年以前）我就曾经教授过这样的课程，并帮助学生解决仿真的性能问题（事前不会公布答案！）。这段经历帮我弄清了什么样的材料能**地引导学生解决性能问题，这也成就了本书的部分内容。
无论你是不是学生，每章的习题都会带给你一个审视和应用知识的机会。其中有一些可选的高阶练习，可能你完成不了（也许做不到，但至少可以启发思维）。
本书涵盖了足够的知识细节，无论是大公司还是小公司，乃至雇用了不少性能专职人员的公司，本书都可以满足其需要。对于众多的小型公司，日常用到的可能只是书中的某些部分，但本书作为参考也可备不时之需。
致谢
Deirdré Straughan再次提供了不可思议的帮助，使我对技术教育的热忱得以延伸至另一本书。从想法到手稿，从*开始就帮助我构想这本书是什么样子，到花费了无数的时间编辑和讨论每一页的内容，找出了许多我没有解释清楚的部分。至今我和她已经合作了超过了2000页的技术内容（加上博客），能得到如此大的帮助我深感荣幸。
Barbara Wood作为拷贝编辑，花了大量的时间在本书的细节上，做了无数的修改，文字才有了现在的质量、可读性和连贯性。考虑到本书的长度和复杂性，这项工作绝不简单，我非常感谢Barbara的帮助和他辛勤的工作。
对于每一位给予本书反馈的人，我都心怀感激。这是一本深层次的技术书，有很多新内容需要严谨的审阅——经常需要频繁地反复确认和理解不同内核的内
我做分布式机器学习系统有八年了，其间很多时候要面对系统分析的问题。但是坦诚的说，大部分情况下我都只能尽快地找一个“近似”方法，处在没有时间深入琢磨上述系统问题的窘境。看到《系能之巅：洞悉系统、企业与云计算》一书之后，不禁眼前一亮。这本书从绪论之后，就开始介绍“方法”——概念、模型、观测和实验手段。作者不仅利用操作系统自带的观测工具，还自己开发了一套深入分析观测结果的脚本，这就是有名的DTrace Toolkit（大家可以直接找来使用）。《性能之巅》一书介绍的实验和观测方法，包括内存、CPU、文件系统、存储硬件、网络等各个方面。而且，在介绍方法之前会深入介绍系统原理——我没法期望更多了！
——王益 Linkedin高级主任分析师
书的作者Gregg先生是业内性能优化方面大名鼎鼎的人物，早年在Sun公司的时候是性能主管和内核工程师，也是大名鼎鼎的DTrace的开发人员，要知道DTrace可是众多trace类工具中*著名的，并且先后被移植到了很多别的OS上。全书统篇都在讨论性能优化，对于所有相关问题的认识，我相信读者在通读全书后会有不一样的感觉。记住，不要只读一遍，每一遍都必有不同的体会。
——丛磊 新浪SAE创始人/总负责人
与软件瑕疵类似，性能问题也可能危害巨大！更可怕的是，性能方面的问题容易促发隐藏在软件深处的瑕疵，直接导致软件崩溃或者其它无法预计的故障。不论调试，还是调优，对软件工程师的技术要都求很高。很高兴看到有这样一本关于系统优化的好书引进到国内。
——张银奎 资深调试专家，《软件调试》和《格蠹汇编》作者 2015年7月22日于上海格蠹轩
纵观全书，作者建立了系统性能优化的体系框架，并且骨肉丰满。很明显，他不仅擅长某方面的性能优化，更是全方位的专家，加之作为DTrace（一种可动态检测进程等状态的工具）主要开发者，使得本书的说服力和含金量大增。本书让我们有机会系统学习和掌握性能优化的各方面，有机会建立一种高屋建瓴的全局观，在面对复杂系统问题时再不会手足无措，或只能盲人摸象。Linux系统演化至今，*基础的体系架构和关键组件并未发生多大改变，这使得这本好书即使再历经多年，价值毫无衰减，反而历久弥新。
——萧田国 触控科技运维总监 高效运维社区创始人
《性能之巅》以一种奇妙而到位的方式，把高屋建瓴的视角和脚踏实地的实践结合了起来，对性能这一复杂、微妙甚至有些神秘的话题进行了外科手术式的解析，读来真是让人感觉豁然开朗。
全书以罕见的遍历式结构，对软件系统的每一个部件都如庖丁解牛般加以剖析，几乎涉及到业务的每一个细节。然而，这些细节并非简单的罗列，而是每一段论述都与具体的角色和场景紧密结合，取舍之间极见智慧。方法论更是不单说理，而是通过一个又一个的具体实例，逐步地建构起来，并反复运用于各个部件之上，使读者明白原理普适性的同时也知道怎样举一反三。
——高博 青年计算机学会论坛（YOCSEF）会员，文津奖得主，《研究之美》译者
性能问题一直是个热门话题，分布式系统时代更成为摆在开发运维人员面前的巨大难题。本书采用了自下而上的结构，从底层的操作系统、CPU、磁盘等基础元素开始，到工作原理层面分析性能受到的各种不同影响，以及如何评估、衡量各项性能指标，让读者知其所以然，在面对实际情况时能够更有针对性地做出判断和决定，而不是机械地、教条地行事。本书提供案例，手把手展示实际性能问题的排查调优过程。读者可据此结合业务系统实际情况展开工作。本书还对常用性能分析工具的使用和扩展做了详细介绍，这对日常工作效率的提升有很大的帮助。无论开发还是运维人员，无论设计、编码或排查调优，本书都能发挥重要的参考作用，尤其适合常备案头。
——林应 *技术部高级技术专家
推荐序1
大数据、云计算和人工智能都是热门概念，也是现实问题。很多团队都面对类似的技术抉择：如何用开源软件构架机群，如何选择云服务，如何设计高效的分布式Web 服务，或者如何开发高效的分布式机器学习系统？当面对这些问题的时候，**能从一些重要的可度量的方面给出定量分析和比较。可是哪些方面重要，以及如何度量呢？
古往今来有很多重要的系统度量问题，比如“如何度量网络繁忙程度”，“如何得知某台机器还活着吗”，“服务中断是因为某个进程死锁了，还是机器出问题了”，或是“我们的机群中用SSD 替换硬盘的比例应该多大”，等等。
这些问题的答案都不简单——正确答案往往构建在对操作系统的深刻理解上，甚至构建在统计学和统计实验基础上。可是通常我们是在繁重的业务压力下应对这些问题的，所以只能尽快找一个“近似”测量办法。这终非长久之计——在我们在经历了很多问题之后，可能会发现自己从未深刻理解问题，没有深入思考，没有沉淀经验，没有获得成长。
如果有意深入理解问题，借助前人经验是可以事半功倍的。只是关于操作系统的教科书却不能为我们提供足够的基础知识。操作系统是如此复杂，几乎涉及计算机科学的所有方面。学校教育往往只能基于极简化的示范系统，比如Minix。但实际使用的操作系统，比如Linux 和Solaris，有更多需要学习和理解的地方。
我做分布式机器学习系统有八年了，其间很多时候要面对系统分析的问题。但是坦诚的说，大部分情况下我都只能尽快地找一个“近似”方法，处在没有时间深入琢磨上述系统问题的窘境。看到《系能之巅：洞悉系统、企业与云计算》一书之后，不禁眼前一亮。这本书从绪论之后，就开始介绍“方法”——概念、模型、观测和实验手段。作者不仅利用操作系统自带的观测工具，还自己开发了一套深入分析观测结果的脚本，这就是有名的DTrace Toolkit（大家可以直接找来使用）。《性能之巅》一书介绍的实验和观测方法，包括内存、CPU、文件系统、存储硬件、网络等各个方面。而且，在介绍方法之前会深入介绍系统原理——我没法期望更多了！
很高兴看到这一经典名著的中文版问世。因为被邀作序，有幸近水楼台先得月，深受教益。感谢译者和编辑的努力。相信读者朋友们定能从中受益。
——王益Linkedin 高级主任分析师
推荐序2
收到侠少的邀约来写序，多少有点忐忑和紧张。忐忑是因为平时太多时间总是在解决各类问题，没有时间好好沉淀下来读一读书，总结一下发现问题和解决问题的方法；紧张是因为我好像很久没有写字了，上一次写长篇大论还是N 年前，怀疑自己是不是能够在有限的文字内把系统性能的问题解释清楚。于是，就在这样的背景下，我从出版方那里拿到了书稿，迫不及待地读了起来。
书的作者Gregg 先生是业内性能优化方面大名鼎鼎的人物，早年在Sun 公司的时候是性能主管和内核工程师，也是大名鼎鼎的DTrace 的开发人员，要知道DTrace 可是众多trace 类工具中*著名的，并且先后被移植到了很多别的OS 上。书的全篇都在讨论性能优化，我想了想，我每天从事的工作不就是这个吗？SAE 上成千上万的开发者们，他们每天问的问题几乎全部和
性能相关：为什么我的App 打开比较慢，为什么我的网站访问不了，怎么才能看我的业务哪个逻辑比较慢？对于这些问题，其实难点并不在于解决它，*难的在于发现并定位它，因为一旦定位了故障点或者性能瓶颈点，解决起来并不是很复杂的事情。
对于性能优化，**的挑战就是性能分析，而性能分析要求我们对于操作系统、网络的性能要了如指掌，明晰各个部分的执行时间数量级，做出合理的判断，这部分在书中有很详细的讨论，让读者可以明确的将这些性能指标应用在80:20 法则上。
工欲善其事，必先利其器，了解系统性能指标后，就需要找到合适的工具对可能存在的瓶颈进行分析，这要求我们具备全面的知识，涉及CPU 性能、内存性能、磁盘性能、文件系统性能、网络协议栈性能等方方面面，好在本书详细介绍了诸如DTrace、vmstat、mpstat、sar、SystemTap 等工具利器，如何将这些工具组合，并应用在适合的场景，是一门学问，相信读者会在书中找到答案。顺便说一句，Dtrace SystemTap 帮助SAE 解决过非常多的性能疑难杂症，一定会对读者的业务分析产生帮助！
单个进程的性能分析是简单的，因为我们可以定位到system-call 或者library-call 级别，然后对照代码很快解决，但整个业务的性能分析是复杂的，这里面涉及多个业务单元、庞大的系统组件。*麻烦的是，往往造成性能问题的还不是单元本身，而是单元和单元相连接的网络服务。这就要求我们必须要有一套科学的分析方法论，来帮助我们找到整个系统业务中的瓶颈所在。书中就此介绍了包括随机变动、诊断循环等多个方法，并且介绍了涉及分析的数学建模和概念。不要忽视数学在性能分析中的作用，在实际应用中，我就利用方差和平均值的变化规律科学的分辨一套系统到底是否应该扩容。
找到了性能瓶颈，下一步就是解决问题。当然解决问题的**办法就是改代码，但是，在你无法短时间内修改代码的时候，对系统进行优化也可以实现这一目的。这就要求我们对于系统的各个环节都要明白其工作原理和联系。本书第三章详细讨论了操作系统，这对于读者是很有用的。因为很多时候我们在不改代码的情况下优化系统，就是优化内存分配比例，就是优化CPU 亲密度，就是尝试各种调度算法，就是做操作系统层面的各种网络参数调优。
对于上述所有问题的认识，我相信读者在通读全书后会有不一样的感觉。记住，不要只读一遍，每一遍都必有不同的体会。不多说了，我要赶紧再去读一遍:)
——丛磊 新浪SAE 创始人/总负责人
推荐序3
人类正在用软件重构这个世界。从上世纪四十年代电子计算机出现，到个人电脑风靡、互联网大行其道，再到如今正兴旺的云计算加移动互联网，还有起步中的物联网，所有这些表面上看是计算机硬件变得无处不在，而实质上是软件一步步掌管起了这个世界。噫吁戏，短短七十几年，软件轻松征服世界！渗透渗透再渗透，已经进入所有人的生活。
不言而喻，软件对这个世界和人类的重要性也越来越大。我很负责任地说，软件的健康与否关系着世界的安危。君不见，几多时，一个软件漏洞便让全球惊慌。不经意间，我们与软件的关系变得休戚与共。
不幸的是，软件的总体健康状况并不乐观，问题很多。
瑕疵（BUG）是软件行业的一个永恒话题，是破坏软件质量的头号大敌。但迄今为止，完全发现和彻底消除瑕疵还只是奢望，是不可能实现的目标。换句话来说，掌管着我们生活的所有软件都是在带着瑕疵运行，真正的带“病”工作。因为每个软件内部都有纵横交错的无数条道路，CPU 经常奔跑的那些路径上的瑕疵早被发现和移除，所以软件大多时候并不发“病”。但也有时候，CPU 会遭遇软件中的瑕疵，发生意外。目前，我们能做的只有努力多发现瑕疵，并尽可能找到根源，将其去除。但这并不是件容易的事情。
除了瑕疵，性能问题是威胁软件健康的另一个大敌。简单来说，我们把软件中的错误归入瑕疵一类。把那些在速度、资源消耗、工作量等方面的不满意表现纳入性能问题一类。用员工考核做比喻，瑕疵是把一件事做错了，而性能问题是虽然做对了，但是做得不够好，可能开销太大，用的资源太多，可能完成速度太慢，用的时间太久，可能完成的工作量太少，活干的不够多，总之是结果不令人满意，还有必要改进。
举例来说，某支付软件在性能方面就存在问题。一旦运行，会频繁促发大量的缺页异常，消耗的CPU 时间过多，导致不必要的能源浪费。随着软件变得无处不在，软件的耗电问题已经引起越来越多的关注。在笔者写作这几行文字时，该软件的几个进程仍在一刻不停地触发着缺页异常，过去两天的累积数量已经超过千万，消耗CPU 的净时间已经超过一小时。粗略估计，这几个进程至少已经消耗了0.01 度电。不要忽视0.01 这个看似微小的数字，把它乘以全国的总用户数，立刻就变成一个庞大的数字了。
与软件瑕疵类似，性能问题也可能危害巨大！更可怕的是，性能方面的问题容易促发隐藏在软件深处的瑕疵，直接导致软件崩溃或者其它无法预计的故障。
发现瑕疵根源的过程一般称为调试（Debug）。纠正性能问题，提高软件性能的努力被称为调优（Tune）。不论调试，还是调优，都不是简单的事。对软件工程师的技术要求很高。一些复杂的问题，常常需要多方面的知识，需要对系统有全面了解，既有大局观，能俯瞰全局，又能探微索隐，深入到关键的细节，可谓是 “致广大而尽精微”。
如果一定要把调试和调优的难度比一下，调优的难度更大。简单的解释是，调试的主要目标是寻找瑕疵，瑕疵固定存在软件中的某一个点。因此，调试时可以通过断点等技术把软件静止下来，慢慢分析。而调优必须关注一个动态的过程，观察一段时间内的软件行为。这样一来，调优时常常不可以把软件中断下来静止分析，而需要以统计学的方法或者其它技术对软件做长时间监视。
记得两年前，曾经有一个同行以饱经沧桑的神情问我：“在中国这样的软件环境里，做技术的工程师应该如何发展呢？难道都得像你那样写一本书么？”坦率说，我当时没能给出让这位同行很满意的回答。因为这个问题确实不太容易回答。此事之后，我常常想起这个困扰着很多同行的问题。多次思考后，我似乎有了个比较好的答案。首先要确认自己是喜欢软件技术的，愿意在技术方向上持续发展。接下来的问题是如何在技术方向上不断前进。“日日新，又日新”。我的建议是，逐级攀登软件技术的三级台阶：编码、调试和调优。
代码是软件的根本，一个好的软件工程师必须过代码这一关，写代码时如行云流水，读代码时穿梭自如，如履平川。以调试器为核心的调试技术是对抗软件瑕疵的*有力工具，是每个技术同行都应该佩戴的一把利剑。调优技术旨在发现软件的性能障碍，让软件跑的更好。随着对软件性能问题的重视，调优技术的发展也越来越快，新的工具层出不穷。调优方面的工作和创业机会也在不断增加。几年前，我写作《软件调试》时，很多人还不太重视调试，但*近几年，软件调试已经逐渐从藏在背后的隐学逐步走向前台，成为一门显学。可以预见，性能调优也会受到越来越多的重视。大家加油！
学习调优技术有很多挑战，很高兴看到有这样一本关于系统优化的好书引进到国内。好友侠少诚邀作序，盛情难却，仓促命笔，词不达意，请诸君海涵，是为序。
——张银奎 资深调试专家，《软件调试》和《格蠹汇编》作者 2015 年7 月22 日于上海格蠹轩
推荐序4
性能调优是每一个系统工程师*重要的技能，也是衡量其水平高低的不二法门。Linux 是开源的操作系统，这也意味着本身可调整范围比较大。近十几年来，硬件设备日益复杂，互联网应用场景及Web 2.0 蓬勃发展的同时，也带了各种高并发的业务应用，有些复杂的分布式数据分析系统，单集群的物理服务器数量甚至超过1 万台。这使得对系统运行环境的一点点优化，带来的收益都可能非常可观。
性能调优这个事情，大家往往都有话想说，技术专家们也都有些秘而不宣、甚至奉为压箱底儿的“活儿”。但这些“活儿”，往往来自Case By Case 所获得的经验。例如解决了某大型电商网站的Nginix 服务器问题，某MySQL 数据库集群性能问题等。这些特定的大型案例，促使参与其中的技术人员，在某个或某些系统性能优化方面，具有较高水平、甚至一定造诣。
但即使这些技术专家，也难以解决所有性能问题。这有两方面原因，一方面自身缺乏对整个系统运行环境的全局把控能力。技术专家们能力的获得，是基于某些问题点扩散开来的，并非基于事先构建好的系统优化的全局观（这也和国内环境有关，大家往往大学毕业后就直接开始从事相关工作，缺少底层、结构性的学习，即使参与了某些培训课程）。
这种系统优化的全局观之所以难以形成，一个原因在于“未知的未知”，也就是说我们不知道自己不知道。比如，我们可能不知道设备中断其实会消耗大量CPU 资源，因而忽略了解决问题的关键线索。再比如，作为初中级DBA 并不知道应用程序连接Oracle 时，每一个数据库连接（Session）实际上都非常消耗物理内存，成百上千个数据库连接长期驻留（看上去状态还是非活动的），PGA 被消耗殆尽，引起各种异常，成为性能问题的罪魁祸首。
另一方面在于性能问题的根源太过复杂。诚如作者所说，一来性能是主观的，连是否有性能问题，都因人而异。例如，磁盘平均读写相应时间为1ms，这是好还是不好？是否需要调优？实际上取决于开发人员和*终用户（有时还包括领导）的性能预期。二来系统是复杂的。例如，本来CPU/磁盘/内存各司其责，有了内存缓存（SWAP）机制，内存不够时可以使用部分硬盘空间来顶替。这看上去很好，但对于数据库系统而言，SWAP 是否启用，本身就是一个问题。再比如，对于云计算而言，多虚拟机共享物理机，这进一步增加了问题的复杂度。资源隔离是个技术活，现有技术很难做到磁盘IO 完全隔离。另外，*近非常流行的容器技术如Docker 等，让问题变得尤为复杂。容器即进程，不像KVM 等虚拟机（KVM 至少还进行资源隔离）自带操作系统。容器并不是为IaaS 而生，仅靠cgroup 等隔离技术能做的非常有限。三来有可能有多个问题并存。有时终端用户抱怨系统慢，很可能不仅由是单个原因引起。例如，业务负载猛增，内网1000Mps 其实已经不够，但没引起注意；或是整体对外交付能力貌似还正常，但数据库磁盘IO 非常繁忙，还可能正偷偷地进行大量SWAP 交换。
这两方面原因，使得大部分技术专家，即使对系统优化的某些领域确有独到见解，但说到能否解决所有系统性能问题，其实会有些底气不足。但本书作者看起来是个例外。纵观全书，作者建立了系统性能优化的体系框架，并且骨肉丰满，很明显，他不仅擅长某方面的性能优化，而是全方位的专家，加之作为DTrace（一种可动态检测进程等状态的工具）主要开发者，使得本书的说服力和含金量大增。
本书首先提及性能优化的方法论和常见性能检测工具的使用，具体内容更是涉及到可能影响Linux 系统性能的方方面面，从操作系统、应用程序、CPU、内存、文件系统、磁盘到网络，无所不包。在以上这些话题的探讨中，作者的表述方法值得称道——每个章节都程式化的介绍术语、模型、概念、架构、方法、分析工具和调优建议，这对于长期工作形成一定强迫症的某些技术人员如我自己，阅读起来赏心悦目，也从侧面体现了作者的深厚功底和驾驭能力。
本书提供的性能优化方法论也令人印象深刻，包括几种常见的错误思考，如街灯法、随意猜测法和责怪他人法。街灯法来自一个著名的醉汉的故事——醉汉丢了东西，就只会在灯光*亮的地方着手。这种头疼医头脚痛医脚、错把结果当原因的事情，相信很多人都过类似经验。大型业务系统上线，大家都围着DBA 责问数据库为什么崩溃了。但数据库出问题是结果，数据库本身一定是问题根源么？是否更应该从业务负载、程序代码性能、网络等方面联合排查？在列举各种不正确的方法后，作者建议采用科学法，科学法的套路是：描述问题→假设→预测→试验→分析。这种办法的好处是，可以逐一排除问题，也可以降低对技术专家个人能力和主观判断的依赖。
本书用单独章节系统性介绍了操作系统、性能检测方法和各种基准测试，特别是作者主导开发的DTrace（本书例子中用DTrace 监控SSH 客户端当前执行的每个命令并实时输出）。这使得本书作为工具书的价值更得以彰显。云计算的出现，对系统优化带来新的挑战。作者作为某云计算提供商的首席性能工程师，带来一个真实的云客户案例分析，包括如何利用本书提及的技术、方法和工具，一步一步分析和解决问题。
很多时候，受限于语言障碍，系统工程师往往通过国内BBS、论坛等获得知识，只是在性能问题确实棘手时，被迫找些英文资料，寻找技术解决思路。
博文视点推出的本书中文版，对国内广大运维同仁而言，实属幸事。这让我们有机会系统学习和掌握性能优化的各个方面，有机会建立一种高屋建瓴的全局观。这样，在面对复杂系统问题时，不至于手足无措，或只能盲人摸象般试探。另外，虽然面对日益复杂的硬件设备和高并发的业务应用，问题不是变得简化而是更为复杂，但Linux 系统演化至今，其*基础的体系架构和关键组件并未发生多大改变，这使得这本好书即使历经多年，价值毫无衰减，反而历久弥新。
总的来说一句话：如果早些接触到本书，该有多好！
——萧田国 触控科技运维总监 高效运维社区创始人
推荐序5
性能的话题，从一开始就是复杂的。性能是一种典型的非功能需求，然而又贯穿在任何一种功能需求中，直接影响系统运行效率和用户体验。也正是由于这一特性，性能无法简单地通过单一的、直线式的思维来度量和管理，而注定需要以系统工程的方法来掌握和调整。绝大多数的图书在谈到性能问题的时候，都是仅从片面的若干现象出发来触及问题的冰山一角，抑或干脆语焉不详甚至避而不谈。这也难怪，因为这个话题一旦展开，就会占用极大篇幅，相对于原先的论题而言就显得喧宾夺主。然而更重要的原因，也在于对性能问题有着全面认识，并且能够给出一个系统化的分析和全栈式的论述的作者实在不多。相关的要求近乎苛刻：既要对系统的每一个部件都了如指掌，又要深入理解部件之间的协作方式；既要精通系统运行的细节，又要明白取舍逻辑的大局观；既要懂得现象背后的原理，又要把握从开发部署的工作人员直至终端应用用户的需求乃至心态。
《性能之巅》以一种奇妙而到位的方式，把高屋建瓴的视角和脚踏实地的实践结合了起来，对性能这一复杂、微妙甚至有些神秘的话题进行了外科手术式的解析，读来真是让人感觉豁然开朗。
全书以罕见的遍历式结构，对软件系统的每一个部件都如庖丁解牛般加以剖析，几乎涉及到业务的每一个细节。然而，这些细节并非简单的罗列，而是每一段论述都与具体的角色和场景紧密结合，取舍之间极见智慧。方法论更是不单说理，而是通过一个又一个的具体实例，逐步地建构起来，并反复运用于各个部件之上，使读者明白原理普适性的同时也知道怎样举一反三。
本书也是难得的UNIX/Linux 系统管理员和运维工程师的百科全书式参考手册，相对于工作于Windows 上的同行而言，他们获得的知识更加零碎，甚至很多场合下不得不求助于网络上的只言片语，并只能通过耗时的、高风险的生产环境实验来取得一手经验数据。本书当然提供了不少趁手的软件工具供人使用，然而其更大的价值在于心法的传授，亦即怎样利用工程师现在就熟悉、现在就可用的工具来迅速地进行性能建模，完成故障排除和调优的关键步骤。书中的内容非常新，作者见过大世面，是从*与时俱进的大型云计算系统为出发点来落笔的，对付日常的性能问题完全没有压力，即使**的硬件也能找到对应的解决方案。
本书的译者团队阵容强大，皆是在底层系统有多年一线工作经验的运维工程师和开发工程师。徐章宁同志几乎是以一己之力支撑起PB 级数据运维的明星DevOps，而另外两位也都是手工实现过复杂生产环境中文件系统和网络协议的大牛。可以说，他们对于性能的认识是经过多年实际工作的考验的，是深刻而且务实的，这为本书翻译在专业性方面提供了坚实的保证。加上他们多年养成的认真严谨的工作习惯，和深厚的中文功底，更是为该译本的可读性锦上添花。
希望所有的IT 从业者都能从本书受益，让天下的系统都能达到性能之巅！
——高博 青年计算机学会论坛（YOCSEF）会员，文津奖得主，《研究之美》译者
推荐序6
性能问题一直是个热门话题，在单机时代我们就已经投入了不计其数的人力物力进行研究。但是随着互联网行业的发展，分布式系统开始大量投入应用，对于性能问题的分析、调优提出了很多前所未有的新挑战。特别是如何做到单机性能与集群整体性能的平衡，以及在各种影响性能的要素之间进行取舍，成为摆在开发运维人员面前的巨大难题。
本书采用了自下而上的结构，从底层的操作系统、CPU、磁盘等基础元素开始，到工作原理层面分析性能受到的各种不同影响，以及如何评估、衡量各项性能指标，让读者知其所以然，在面对实际情况时能够更有针对性地做出判断和决定，而不是机械地、教条地行事。本书还提供了案例，手把手地展示了实际性能问题的排查调优过程。读者可以根据案例，结合业务系统实际情况展开工作。此外，本书还对常用的性能分析工具的使用和扩展做了详细介绍，对于日常工作效率的提升也有着很大的帮助。
译者徐章宁曾与我在EMC 的云存储部门共事多年，在系统性能排查、调优方面有着丰富的经验，很高兴他能参与此书的翻译。审稿过程中我感觉译者不仅忠实地还原了原著的精华，也融合了自己多年工作中积累的经验教训。
我坚信，本书无论对于开发还是运维人员，无论对于设计、编码或者排查调优，都能发挥重要的参考作用，尤其适合常备案头。在此诚挚向大家推荐。
——林应 淘宝技术部高级技术专家
译者序
作为一名运维工程师，系统出现一些“诡异”问题的情况并不罕见。有些时候面对束手无策的问题着实让人头痛，这时我总会感慨，学生时代课本上计算机科学那些诸多的概念和理论所呈现出的完美感觉更多是在书本上，在真实系统中往往更多是另外一幅更为“现实”的景象。工作多年后，我自发形成了一个简单的认知：当系统庞大到一定程度时，其复杂性会变得不容易控制是一件很正常的事情。用技术手段把这些“失控”的点妥善摆平就是工程师价值的体现。在翻译本书的过程中，我对这个问题又有了不同的认识：
“已知的已知，已知的未知，未知的未知。”
这是本书多次提到过的概念，说的是有些事情我们知道自己知道，有些事情我们知道自己不知道，还有些事情我们不知道自己不知道。这个概念就系统（特别是复杂系统，诸如云计算或大数据）而言，特别贴切：就系统内部来说，无论用到的是某一操作系统，还是某一编程语言，其实本身就已经是复杂度较高的实体，要透彻掌握并非易事，何况系统皆由这些技术组合构建而成，方方面面无所不知是不可能做到的事情，这里的未知源于技术本身的复杂；就系统外部来说，如今时事变化一日千里，现在系统要处理的外界变化，可能*初的系统设计者都从未想过，这里的未知来源于未来的不定。所以，有让你手足无措的问题出现其实是一种很正常的状态，对此的恐惧只是人施加给自己的情感层面的东西。与此相反，始终对未知心生敬畏才是对待未知正常的态度，更是本应有的觉悟。
这里并不是说我们要对未知“投降”，而是说对“未知”有正确的认识才是我们取得进步的前提。其实我们多数人对“系统的未知”存在误区，我们常常将系统等同于具象的技术实体，例如某种编程语言、OS 内核、网络。总觉得系统出问题肯定是我某些技术知识有漏洞没学好。可惜“学海无涯，而吾生有涯，以有涯随无涯，殆矣”，拘泥于各种眼花缭乱的技术只会让自己迷失造成时间的浪费。技术都是末节，真正要把握的主体其实只是系统本身。道理虽简单，但舍本逐末的事情却还是屡见不鲜。
要做好这一点，首要的是要有全局的系统观。更准确地说，是要有对系统各层知识的理解和实践能力，要有对系统架构的认知和理解的能力。只有对系统了如指掌，才有希望将已知的未知转化为已知的已知，将未知的未知转化为已知的未知，进而增加对系统的掌控能力，避免盲人摸象的悲剧。事实的真相是也本应是这样：技术的价值依附于系统及其价值，没有孤立存在的技术，一切价值的体现都在于系统本身。唯有立足系统本身，工程师才能打通性能这条经脉，领略到性能之巅的风采！
回观《性能之巅》这本书，全书的安排也深有此意。本书第1~5 章可谓是精华部分，讲述了与系统性能相关的通用模型和通用方法；第6~12 章才落实到具体的知识细节，讲述各性能组件（CPU、内存等）的知识（第6~10 章）、云计算的基础（第11 章），基准测试的方法（第12 章）。本书*后一章是一个性能分析的实例，若是让长期与系统打交道的工程师读来，必然感同身受；若是性能新手阅读，则可以对性能工作的日常状况有个基本的了解。
本书是一座桥梁，作者Brendan 是在系统性能领域耕耘多年的技术专家，在Sun 和Oracle公司有过卓越的贡献，动态跟踪工具DTrace 就是他主力开发的，他用自己多年的经验和实践归纳并总结出了系统性能的理论和方法，这些理论和方法的作用就像桥梁，把业界可用的工具（或是你自己开发的工具）与系统内部的原理机制联通让它们有机地结合起来，让与性能相关的工作（无论是性能分析还是性能调优）做到有的放矢、有章可循！这与单纯提供知识的技术书籍截然不同，“授人以鱼不如授人以渔”，其立意确实难能可贵。
现代IT 技术的源头并非中国，但IT 技术在这片土地上生根发芽，欣欣向荣。如今国人日常生活中所依赖的系统服务已经比比皆是，不信者打开自己的手机数数所装的App 自然清楚，这些App 背后多半都有远在某个数据中心的一个或多个系统作为支撑。随着互联网技术向各行业以及生活各方面的渗透，这样的系统今后会越来越多。加之伴随着云计算和大数据技术的兴起和蓬勃发展，除了系统越来越多之外，系统自身还会变得越来越庞大和复杂。在这么一个总的大趋势下，系统性能的重要性自然不言而喻。你会发现Brendan 所著的《性能之巅》是如此地契合我们这个时代，本书不是**本论述系统性能的书，但本书对现有系统性能的方法和理论所做的提炼、概括和归纳，不敢说后无来者，但**可以称得上是前无古人的了。
全书翻译由EMC 资深软件工程师吴寒思、点融网资深运维工程师陈磊与我共同完成，在此感谢二位的辛苦耕耘和我们作为团队三人之间彼此的精诚合作，一年多的翻译历程，大量的时间和精力的投入自是不提，但回过头来看整个过程于我们译者自觉仍是获益良多的。本书内容量大涉及面广，尽管我们付出了许多的辛苦和努力，还是难以避免错误的出现，仍会存在一些不尽如人意的地方，欢迎广大读者批评指正，以便改进。
感谢博文视点出版社主编张春雨对本书出版的大力支持，感谢编辑贾莉对本书的悉心校对；感谢高博学长在翻译道路上给予我的指引；在本书成稿过程中，感谢EMC 蔡小华、EMC 陈立、EMC 胡世杰、百度冯玮、百度林向东、百度文立经理、淘宝的林应经理，还要感谢我所在的团队上海百度研发中心离线运维组的同事们。另外，更要感谢我的父母和女友吴颖对我的理解和支持。愿这本书的出版给你们带来快乐。
徐章宁
于百度上海研发中心
2013 年7 月
评论
还没有评论。