有已知的已知；有些事情我们知道自己知道。
我们也知道有已知的未知；这是指我们知道有些事情自己不知道。
但是还有未知的未知——有些事情我们不知道自己不知道。
——美国国防部长 唐纳德·拉姆斯菲尔德 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出版时，作者同时介绍了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 的示例展示的是你能向系统掷出的问题。这些问题以及提出这些问题的方法，常常才是最困难的。
目标受众
本书的目标受众主要是系统管理员以及企业与云计算环境的运维工程师。所有需要了解操作系统和应用程序性能的开发人员、数据库管理员和网站管理员都适合参阅本书。
作为云计算提供商的首席性能工程师，我的工作会与支持人员和顾客打交道，他们经常要承受巨大时间压力去解决多个性能问题。对于许多人来说，性能并不是他们的主要工作，但却需要了解足够多的性能知识来解决手头的问题。因为清楚读者学习本书的时间会非常有限，我将本书编写得尽可能简洁。但不会简短：有太多知识需要覆盖才能保证你是准备好了的。
另一个受众群体是学生：本书适合作为系统性能课程的补充教材。在本书的编写期间（以及开始动笔的多年以前）我就曾经教授过这样的课程，并帮助学生解决仿真的性能问题（事前不会公布答案！）。这段经历帮我弄清了什么样的材料能最好地引导学生解决性能问题，这也成就了本书的部分内容。
无论你是不是学生，每章的习题都会带给你一个审视和应用知识的机会。其中有一些可选的高阶练习，可能你完成不了（也许做不到，但至少可以启发思维）。
本书涵盖了足够的知识细节，无论是大公司还是小公司，乃至雇用了不少性能专职人员的公司，本书都可以满足其需要。对于众多的小型公司，日常用到的可能只是书中的某些部分，但本书作为参考也可备不时之需。
排版约定
本书贯穿始终用到的排版约定如下：
netif_receive_skb() 函数名
iostat(1) Man 手册
Documentation/ . . . Linux 文档
CONFIG_ . . . Linux 配置选项
kernel/ . . . Linux 内核源代码
fs/ Linux 内核源代码，文件系统
usr/src/uts/ . . . 基于Solaris 内核源代码
# 超级用户（root）shell 提示符
$ 普通用户（non-root）shell 提示符
^C 命令被中断（Ctrl＋C）
[...] 文本截断
mpstat 1 键入的命令或高亮的文字
致谢
Deirdré Straughan 再次提供了不可思议的帮助，使我对技术教育的热忱得以延伸至另一本书。从想法到手稿，从最开始就帮助我构想这本书是什么样子，到花费了无数的时间编辑和讨论每一页的内容，找出了许多我没有解释清楚的部分。至今我和她已经合作了超过了2000 页的技术内容（加上博客），能得到如此大的帮助我深感荣幸。
Barbara Wood 作为拷贝编辑，花了大量的时间在本书的细节上，做了无数的修改，文字才有了现在的质量、可读性和连贯性。考虑到本书的长度和复杂性，这项工作绝不简单，我非常感谢Barbara 的帮助和他辛勤的工作。
对于每一位给予本书反馈的人，我都心怀感激。这是一本深层次的技术书，有很多新内容需要严谨的审阅——经常需要频繁地反复确认和理解不同内核的内核代码。
不管是深层次的技术还是材料的组织和展示，Darryl Gove 都给予了无与伦比的反馈意见。他本身就是一个作家，看到他是如此迫切地向我们的读者提供最好的内容，我非常期待着他将来的著作。
我还非常感谢Richard Lowe 和Robert Mustacchi，他们通审了整本书，发现了我所缺失的内容和一些需要做更好阐述的部分。Richard 对不同内核的内部机理的理解令人震惊，厉害得甚至有点可怕。Robert 对云计算章节给予了极大的帮助，他还将自己在KVM 上的工作专长转移到了illumos 上。
感谢Jim Mauro 和Dominic Kay 的反馈意见：我曾经与他们一起出过书，理解艰深的技术内容，再把这些内容解释给读者，他们是此中的天才。
Jerry Jelinek 和Max Bruning，两人都有着内核工程的专长，提供了多章的详尽反馈。
Adam Leventhal 对“文件系统”一章和“磁盘”一章给予了专家级建议，特别是帮我理解了闪存当前的细微差别——他在这个领域有着长期的经验，在Sun 公司的时候就发明过不少闪存创新性的使用方法。
David Pacheco 对“应用程序”一章给予了极好的反馈， Dan McDonald 则是对“网络”那一章，我很幸运可以让他们在自己如此了解的领域把他们自己的技术展示出来。
Carlos Cardenas 看过了整本书，在统计分析方面给予了独特的建议，这些建议正是我之前一直所追寻的。
我很感激Bryan Cantrill、Keith Wesolowski、Paul Eggleton、Marsell Kukuljevic-Pearce 和Adrian Cockcroft，为他们的反馈和贡献。Adrian 的意见促使我重新排列章节顺序，这让读者可以更好地关联所覆盖的内容。
我感谢在我之前的作者们，他们的名字都列在了参考附录之中，是他们铺就了通往系统性
能的道路并把自己的发现记录了下来。感谢与我一同工作多年的性能专家们，包括Bryan Cantrill、Roch Bourbonnais、Jim Mauro、Richard McDougall，等等。我从他们身上学到了很多很多。
感谢Bryan Cantrill 对这个项目的支持，感谢 Jason Hoffman 的热忱。
感谢Claire、Mitchell 和其他家人朋友为支持我这个项目所做出的牺牲。
特别要感谢Pearson 公司的高级总监Greg Doench，感谢他的帮助、耐心和对项目的建议。
我很享受本书编写的过程，即使期间也有过不时的气馁。要是十年前的话，我写起来会容易得多，那时候我对复杂性和系统性能微妙的所知不及现在，我在企业、存储和云计算领域做过软件工程师、内核工程师和系统工程师。无论是栈的各个层级，还是从应用程序到硬件，在所有这些地方我都处理过性能问题。这些经历，我知道还有好多都还没有记录下来。所有这些既让我受过挫，也激励着我把它们写下来。这本书是我一直想要写就的，本书的完成是我莫大的安慰。
译者序
作为一名运维工程师，系统出现一些“诡异”问题的情况并不罕见。有些时候面对束手无策的问题着实让人头痛，这时我总会感慨，学生时代课本上计算机科学那些诸多的概念和理论所呈现出的完美感觉更多是在书本上，在真实系统中往往更多是另外一幅更为“现实”的景象。工作多年后，我自发形成了一个简单的认知：当系统庞大到一定程度时，其复杂性会变得不容易控制是一件很正常的事情。用技术手段把这些“失控”的点妥善摆平就是工程师价值的体现。在翻译本书的过程中，我对这个问题又有了不同的认识：
“已知的已知，已知的未知，未知的未知。”
这是本书多次提到过的概念，说的是有些事情我们知道自己知道，有些事情我们知道自己不知道，还有些事情我们不知道自己不知道。这个概念就系统（特别是复杂系统，诸如云计算或大数据）而言，特别贴切：就系统内部来说，无论用到的是某一操作系统，还是某一编程语言，其实本身就已经是复杂度较高的实体，要透彻掌握并非易事，何况系统皆由这些技术组合构建而成，方方面面无所不知是不可能做到的事情，这里的未知源于技术本身的复杂；就系统外部来说，如今时事变化一日千里，现在系统要处理的外界变化，可能最初的系统设计者都从未想过，这里的未知来源于未来的不定。所以，有让你手足无措的问题出现其实是一种很正常的状态，对此的恐惧只是人施加给自己的情感层面的东西。与此相反，始终对未知心生敬畏才是对待未知正常的态度，更是本应有的觉悟。
这里并不是说我们要对未知“投降”，而是说对“未知”有正确的认识才是我们取得进步的前提。其实我们多数人对“系统的未知”存在误区，我们常常将系统等同于具象的技术实体，例如某种编程语言、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 月
