《性能之巅：洞悉系统、企业与云计算》读书笔记-Part 1

本文是读书笔记第一部分，包括原书第一、二章。

绪论

性能是一门令人激动的，富于变化同时又充满挑战的学科。

系统性能

单台服务器上的通用系统软件栈

人员

系统性能是一项需要多类人员参与的工程。

事情

关于性能的理想执行顺序排列如下：

1. 设置性能目标和建立性能模型
2. 基于软件或硬件原型进行性能特征归纳
3. 对开发代码进行性能分析（软件整合之前）
4. 执行软件非回归性测试（软件发布前或发布后）
5. 针对软件发布版本的基准测试
6. 目标环境中的概念验证（Proof-of-concept）测试
7. 生产环境部署的配置优化
8. 监控生产环境中运行的软件
9. 特定问题的性能分析

容量规划：Capacity Planning，指的是一系列事前行动。在设计阶段，包括通过研究开发软件的资源占用情况，来得知原有设计在多大程度上能满足目标需求。在部署后，包括监控资源的使用情况，这样问题在出现之前就能被预测。

视角

两种性能分析的视角：负载分析(workload analysis)和资源分析(resource analysis)，二者从不同的方向对软件栈做分析。

性能调优充满挑战

系统性能是一门工程学，是主观的、复杂的、多问题并存的。

性能是主观的

性能常常是主观性的。开始着手性能问题时，对问题是否存在的判断都有可能是模糊的，在问题被修复时也同样如此：被一个用户认为是不好的性能，另一个用户可能认为是好的。

一个给定指标是好或坏，取决于应用开发人员和最终用户的性能预期。

系统是复杂的

性能问题可能出在子系统之间复杂的互联上，即便这些子系统隔离时表现得都很好。也可能由于连锁故障（cascading failure）出现性能问题，这指的是一个出现故障的组件会导致其他组件产生性能问题。要理解这些产生的问题，你必须理清组件之间的关系，还要了解它们是怎样协作的。

修复一个问题可能只是把瓶颈推向系统其他地方，导致系统的整体性能并没有得到期望的提升。

解决复杂的性能问题常常需要全局性的方法。整个系统——包括自身内部和外部的交互——都可能需要被调查研究。

可能有多个问题并存

真正的任务不是寻找问题，而是辨别问题或者说是辨别哪些问题是最重要的。

性能分析必须量化（quantify，如延时，latency）问题的重要程度。某些性能问题可能并不适用于你的工作负载或只在非常小的程度上适用。理想情况下，你不仅要量化问题，还要估计每个问题修复后能带来的增速。当管理层审查工程或运维资源的开销缘由时，这类信息尤其有用。

延时

延时：测量的是用于等待的时间，可以估计最大增速(Maximum Speedup)，

动态跟踪：Dynamic Tracing，可从任意感兴趣的点测量延时，还可以提供数据以显示延时完整的分布情况。

动态跟踪

动态跟踪技术把所有的软件变得可以监控，而且能用在真实的生产环境中。这项技术利用内存中的CPU指令并在这些指令之上动态构建监测数据。

在DTrace之前，系统跟踪（system tracing）常常使用静态探针（static probes）：置于内核和其他软件之上的一小套监测点；观测是有限的，一般用起来很费时，需要配置、跟踪、导出数据以及最后分析一整套流程。

DTrace：第一个适用于生产环境的动态跟踪工具，提供许多其他功能，甚至包括一套自用的编程语言，D语言。DTrace对用户态和内核态的软件都提供了静态跟踪和动态跟踪，并且数据是实时产生的。

云计算

云计算架构能让应用程序均衡分布于数目不断增多的小型系统中，这让快速扩展成为可能；降低对容量规划的精确程度的要求，因为更多的容量可以很便捷地在云端添加。对性能分析的需求更高：使用较少的资源就意味着系统更少。

云计算和虚拟化技术带来新的难题：如何管理其他租户（tenant，性能隔离(Performance Isolation)）带来的性能影响，以及如何让每个租户都能对物理系统做观测。举例，磁盘IO性能可能因为同邻近租户的竞争而下降，并不是每一个租户都能观察到物理磁盘的真实使用情况。

案例研究

缓慢的磁盘

在/proc目录里检查磁盘错误数。

使用iostat(1)来测量IOPS、吞吐量、平均磁盘I/O延时和读写比。

软件变更

非回归性测试是用来确认软件或硬件的变更并没有让性能倒退的。

方法

在取得数据之前就把事情理论化是一个严重的错误。不理智的人扭曲事实来适应理论，而不是改变理论来适应事实。柯南·道尔《夏洛克·福尔摩斯—波西米亚丑闻》

面对一个性能不佳且复杂的系统环境时，首先需要知道的挑战就是从什么地方开始分析、收集什么样的数据，以及如何分析这些数据。

术语

核心术语：

• IOPS：每秒发生的输入/输出操作的次数，是数据传输的一个度量方法。对于磁盘的读写，IOPS指的是每秒读和写的次数；
• 吞吐量：评价工作执行速率，如数据传输速度（字节/秒或比特/秒）。在某些情况下（如数据库），吞吐量指的是操作的速度（每秒操作数或每秒业务数）；
• 响应时间：一次操作完成的时间。包括等待、服务、返回结果的时间；
• 延时：延时是描述操作里用来等待服务的时间。在某些情况下，它可以指的是整个操作时间，等同于响应时间；
• 使用率：对于服务所请求的资源，使用率描述在所给定的时间区间内资源的繁忙程度。对于存储资源来说，使用率指的就是所消耗的存储容量（例如，内存使用率）；
• 饱和度：指的是某一资源无法满足服务的排队工作量；
• 瓶颈：在系统性能里，瓶颈指的是限制系统性能的那个资源。分辨和移除系统瓶颈是系统性能的一项重要工作；
• 工作负载：系统的输入或者是对系统所施加的负载叫做工作负载。对于数据库来说，工作负载就是客户端发出的数据库请求和命令；
• 缓存：用于复制或者缓冲一定量数据的高速存储区域，目的是为了避免对较慢的存储层级的直接访问，从而提高性能。出于经济考虑，缓存区的容量要比更慢一级的存储容量要小。

模型

受测系统

SUT：System Under Test，如图：

扰动：perturbation，会影响结果，包括定时执行的系统活动、系统其他用户、其他工作负载。扰动来源可能不是很清楚，需要细致的系统性能研究才能加以确定。

现代复杂系统（环境）的困难是系统很可能由若干个网络化的组件组成，都用于处理输入工作负载，包括负载平衡、Web服务器、数据库服务器、应用程序服务器，以及存储系统。

排队系统

一个简易的排队模型如下图所示：

概念

延时

网络连接延时的定义，示意图如上，响应时间包括延时和操作时间。

延时可在不同点测量，所以通常需指明延时测量的对象。如网站的载入时间由三个从不同点测得的不同时间组成：DNS延时、TCP连接延时和TCP数据传输时间。

从不同的层次看，延时包括的环节也不尽相同。从用户角度来看，点击网站链接起到网页完全载入都可以当作延时，包括浏览器渲染生成网页的时间。

延时是一个时间上的指标，因此可能有多种计算方法。

其他指标也可转化为延时或时间，这样方便进行比较。比如磁盘I/O包含很多因素：网络跳数、网络丢包率和重传、I/O的大小、随机或顺序I/O、磁盘类型等。

时间量级

3.3GHz的CPU寄存器一次访问0.3ns。系统的各种延时如下表所示：

权衡三角

日常生活中常见的广告商品宣传语是：多快好省；对应到IT项目里，就是：及时（个人感觉，用便捷来理解更恰当）、性能和成本。如你我所见，大多数公司（至少是在前期）选择便捷和成本，把性能放到以后再说。

一个常见的性能调整的权衡是在CPU 与内存之间，因为内存能用于缓存数据结果，降低CPU 的使用。在有着充足CPU 资源的现代系统里，交换可以反向进行：CPU 可以压缩数据来降低内存的使用。

与权衡相伴而来的通常的是可调参数：

• 文件系统记录尺寸（或块大小）：小的记录尺寸，接近应用程序I/O大小，随机I/O工作负载会有更好的性能，程序运行的时候能更充分地利用文件系统的缓存。选择大的记录尺寸能提高流的工作负载性能，包括文件系统的备份。
• 网络缓存尺寸：小的网络缓存尺寸会减小每个连接的内存开销，有利于系统扩展；大尺寸能提高网络吞吐量。

调整的影响

性能调整发生在越靠近工作执行的地方效果最显著。

如上表所示，越靠近上层，能调优的空间越大（毕竟对于存储或文件系统，大多数情况下无能为力），调优获得的性能提升越大。

操作系统的性能分析能辨别出来的不仅是操作系统层级的问题，还有应用程序层级的问题；在某些情况下，甚至要比应用程序视角还简单。

合适的层级

性能调优，取决于性能技术投入的投资回报率，ROI。

性能建议的时间点

性能推荐，尤其是可调整的参数值，仅仅在一段特定时间内有效。

负载和架构

TODO

扩展性

负载增加下的系统所展现的性能，叫做扩展性。

系统负载增加后，吞吐量变化曲线如下图：

系统负载增加后，响应时间变化曲线如下图：

解读：

• 发生性能快速下降可能是
  • 由于内存负载增加，当系统开始换页（或使用swap）来补充内存时；
  • 磁盘I/O。随着负载（和磁盘使用率）的增加，I/O可能会排队，响应时间快速提升。
• 发生性能慢速下降则可能是由于CPU负载。

已知的未知

关于已知和未知的几个概念：

• 已知的已知：你知道你应该检查性能指标，你也知道它的当前值；
• 已知的未知：你知道可以检查一个指标或判断一个子系统是否存在，但是你还没去做；
• 未知的未知：有些东西你不知道你不知道。比如，你可能不知道设备中断会消耗大量CPU资源。

性能这块领域是：你知道的越多，你不知道的也就越多。这和学习系统是一样的原理：了解得越多，就能意识到未知的未知就越多，然后这些未知的未知会变成你可以去查看的已知的未知。

指标

常见的系统性能指标如下：

• IOPS：每秒的I/O操作数，也是度量吞吐量，只针对IO；
• 吞吐量：每秒数据量或操作量，取决于上下文环境；
• 使用率
• 延时

开销：性能指标的获取不是免费的午餐；收集和保存指标数据会消耗CPU资源等，对目标的性能会有负面影响。这种影响被称为观察者效应，observer effect。

问题：指标可能会是混淆的、复杂的、不可靠的、不精确的、甚至是错的。有时在某一软件版本上对的指标，由于没有得到及时更新，而无法反映新的代码和代码路径。

使用率

使用率可以有两个度量：

• 基于时间：使用排队理论来定义，公式$U=B/T$，U是使用率，T是观测周期，B是系统繁忙时间，
• 基于容量：系统或组件（例如硬盘）都能够提供一定数量的吞吐。100%使用率的磁盘不能接受更多的工作。若用时间定义，100%的使用率只是指时间上100%的忙碌。

非空闲时间。

饱和度

随着工作量增加而对资源的请求超过资源所能处理的程度，叫做饱和度。

解读：时间花在等待（延时）上，所以任何程度的饱和度都是性能问题。

对于基于时间的使用率（忙碌百分比），排队和饱和度可能不发生在100%使用率时，这取决于资源处理任务的并行能力。

剖析

即profiling，通常是按照特定的时间间隔对系统的状态进行采样，然后对这些样本进行研究。采样时间间隔，即采样率很关键。

缓存

多级缓存。

缓存命中率=命中次数/(命中次数+失效次数)。

缓存命中率和性能关系曲线图如上。解读：98%和99%之间的性能差异要比10%和11%之间的性能差异大很多。

缓存的失效率，指的是每秒钟缓存失效的次数。这与每次缓存失效对性能的影响是成比例（线性）关系的。

运行时间=(命中率×命中延时)+(失效率×失效延时)

缓存算法：

• MRU：最近最常使用算法，保留策略，决定什么样的数据会保留在缓存里：最近使用次数最多的数据
• LRU：最近最少使用算法，回收策略，
• MFU：最常使用算法
• LFU：最不常使用算法
• NFU：不常使用算法，LRU的一个花费不高但吞吐量稍小的版本；

缓存状态：

• 冷：冷缓存是空的，或者填充的是无用的数据。冷缓存的命中率为0（或接近0，当它开始变暖时）；
• 热：热缓存填充的都是常用的数据，并有着很高的命中率，例如超过99%；
• 温：温缓存指的是填充有用的数据，但是命中率还没达到预想的高度；
• 热度：缓存的热度指的是缓存的热度或冷度。提高缓存热度的目的就是提高缓存的命中率。

视角

这两个视角是工作负载分析和资源分析，可以分别对应理解为对系统软件栈自上而下和自底向上的分析。

资源分析

系统资源有：CPU、内存、磁盘、网卡、总线以及之间的互联。

操作：

• 性能问题研究：看是否某特定类型资源的责任；
• 容量规划：为设计新系统提供信息，或者对系统资源何时会耗尽做预测。

适合资源分析的指标：

• IOPS
• 吞吐量
• 使用率
• 饱和度

系统的统计工具：vmstat(1)、iostat(1)、mpstat(1)。

工作负载分析

工作负载分析检查应用程序的性能：所施加的工作负载和应用程序是如何响应的。

工作负载分析的对象：

• 请求：所施加的工作负载
• 延时：应用程序的响应时间
• 完成度：查找错误

研究工作负载请求一般会涉及检查并归纳负载的特点，即归纳工作负载属性的过程。举例，通过查找超过可接受阈值的延时，来定位延时的原因（向下挖掘分析），并确认在修复之后延时会有提升。

适合工作负载分析的指标：

• 吞吐量：每秒业务处理量
• 延时

方法

讹方法：anti-methodologies，反方法。

汇总如下：

分析性能问题，在使用其他方法前，首先应尝试的方法是问题陈述法。

街灯反方法

性能调整可以用一种试错的方式反复摸索，对所知道的可调参数进行设置，熟悉各种不同的值，看看是否有帮助。

街灯效应。

随机变动反方法

实验性质的反方法，用户随机猜测问题可能存在的位置，然后做改动，直到问题消失。

整个方法如下：

1. 任意选择一个项目做改动，如一项可变参数；
2. 朝某个方向做修改；
3. 测量性能；
4. 朝另一个方向修改；
5. 测量性能；
6. 步骤3或5的结果是不是要好于基准值？如果是，保留修改并返回步骤1。

这个过程可能最终获得的调整仅适用于被测的工作负载，方法非常耗时而且可能做出的调整不能保持长期有效。

责怪他人反方法

这个反方法包含以下步骤：

1. 找到一个不是你负责的系统或环境的组件；
2. 假定问题是与那个组件相关的；
3. 把问题扔给负责那个组件的团队。
4. 如果证明有错，返回步骤1。

为了避免成为牺牲品，向指责的人要屏幕截图，图中应清楚标明运行的是何种工具，输出是怎样中断的。你可以拿着这些东西找其他人征求意见。

ad hoc核对清单法

问题陈述法

科学法

科学法研究未知的问题是通过假设和试验，有以下步骤：

1. 问题
2. 假设
3. 预测
4. 试验
5. 分析

诊断循环

诊断周期与科学方法相似：假设→仪器检验→数据→假设。

上述两个方法，理论和数据都有很好的平衡。从假设发展到数据的过程很快，那么不好的理论就可尽早地被识别和遗弃，进而开发更好的理论。

工具法

工具为导向的方法如下：

1. 列出可用到的性能工具（可选的，安装的或者可购买的）；
2. 对于每一个工具，列出它提供的有用的指标；
3. 对于每一个指标，列出阐释该指标可能的规则。

这个视角的核对清单告诉你哪些工具能用、哪些指标能读、怎样阐释这些指标。但是，只依赖可用的（或知道的）工具，只能得到一个不完整的系统视野；与街灯反方法类似，用户不知道TA的视野不完整，而且可能自始至终对此一无所知。需要定制工具（如动态跟踪）才能发现的问题可能永远不能被识别并解决。

但是的但是，知道足够多的工具，了解、熟悉、并学会使用每个工具，又是非常耗时的。因为每个工具都有其擅长的某个方面，某些工具的功能又比较相似，某几个工具之间的优缺点对比情况会影响性能分析。

USE方法

USE：utilization、saturation、errors，应用于性能研究，用来识别系统瓶颈；对于所有的资源，查看它的使用率、饱和度和错误。

术语定义：

• 资源：所有服务器物理元器件。某些软件资源也能算在内，提供有用的指标。
• 使用率：在规定的时间间隔内，资源用于服务工作的时间百分比。虽然资源繁忙，但是资源还有能力接受更多的工作，不能接受更多工作的程度被视为饱和度。
• 饱和度：资源不能再服务更多额外工作的程度，通常有等待队列。
• 错误：错误事件的个数。

USE方法会将分析引导到一定数量的关键指标上，这样可以尽快地核实所有的系统资源。在此之后，如果还没有找到问题，那么可以考虑采用其他的方法。

USE方法流程

工作负载特征归纳

向下挖掘分析

深度分析开始于在高级别检查问题，然后依据之前的发现缩小关注的范围，忽视那些无关的部分，更深入发掘那些相关的部分。

针对系统性能，深度分析方法分为以下三个阶段：

1. 监测：用于持续记录高层级的统计数据，如果问题出现，予以辨别和报警；
2. 识别：对于给定问题，缩小研究的范围，找到可能的瓶颈；
3. 分析：对特定的系统部分做进一步的检查，找到问题根源并量化问题。

传统的监测方法是使用SNMP（简单网络管理协议），监控支持该协议的网络设备。

识别工具：Oracle ZFSStorage Appliance Analytics。

分析工具：strace(1)、truss(1)、perf和DTrace。

在分析阶段，可考虑使用五个Why方法。当然，5只是一个概数。简单的问题，3个Why可能就解决；复杂的问题，可以逐层地递进地更深入地问自己更多问题。

延时分析

延时分析检查完成一项操作所用的时间，然后把时间再分成小的时间段，接着对有着最大延时的时间段做再次的划分，最后定位并量化问题的根本原因。

延时分析过程如下图：

R方法

R方法是针对Oracle数据库开发的性能分析方法，意在找到延时的根源，基于Oracle的trace events，着重于识别和量化查询过程中所消耗的时间。

这个方法思想可用于所有系统。

事件跟踪

系统的操作就是处理离散的事件，包括CPU 指令、磁盘I/O，以及磁盘命令、网络包、系统调用、函数库调用、应用程序事件、数据库查询等。

网络排错常常需要逐包检查，可用工具：tcpdump，tcpdump(1)的参数-ttt输出所包含的DELTA时间，可测量包与包之间的时间。

存储设备I/O在块设备层可用iosnoop(1M)来跟踪。

系统调用层的跟踪工具：Linux的strace(1)和基于Solaris系统的truss(1)。

事件跟踪需找到下列信息：

• 输入：事件请求的所有属性，即类型、方向、尺寸等；
• 时间：起始时间、终止时间、延时（差异）；
• 结果：错误状态、事件结果（大小尺寸）。

研究之前发生的事件也能提供信息。一个延时特别差的事件，通常叫做延时离群值，可能是因为之前的事件而不是自身所造成的。

基础线统计

基础线统计包括大范围的系统观测并将数据进行保存以备将来参考。与启动以来的信息统计不同，后者会隐藏变化，基础线囊括每秒的统计，因此变化是可见的。

静态性能调整

两类：

• 静态性能调整：处理架构配置问题；静态性能分析是在系统空闲没有施加负载时执行的；
• 动态性能调整：看重的是负载施加后的性能。

缓存调优

各级缓存的整体调优策略：

1. 缓存的大小尽量和栈的高度一样，靠近工作执行的地方，减少命中缓存的资源开销；
2. 确认缓存开启并确实在工作；
3. 确认缓存的命中/失效比例和失效率；
4. 如果缓存的大小是动态的，确认它的当前尺寸；
5. 针对工作负载调整缓存。这项工作依赖缓存的可调参数。
6. 针对缓存调整工作负载。这项工作包括减少对缓存不必要的消耗，这样可释放更多空间来给目标工作负载使用。

小心二次缓存，比如消耗内存的两块不同的缓存块，把相同数据缓存两次。

还要考虑每一层缓存调优的整体性能收益。

微基准测试

可以用微基准测试工具来施加工作负载并度量性能。或者用负载生成器来产生负载，用标准的系统工具来测量性能。两种方法都可以，但最稳妥的办法是使用微基准测试工具并用标准系统工具再次确认性能数据。

例子：

• 系统调用：针对fork()、exec()、open()、read()、close()；
• 文件系统读取：从缓存过的文件读取，读取数据大小从1B变化到1MB；
• 网络吞吐量：针对不同的socket缓冲区的尺寸测试TCP端对端数据传输。

建模

三类性能评估方法：

• 观测：测量
• 仿真：实验性测试
• 分析建模

上述三者至少择其二可让性能研究最为透彻。

企业和云

利用云计算技术，任意规模的环境都可以短期租用——用于基准测试。

可视化识别

几个性能扩展性曲线：

X轴是扩展的维度，Y轴是相应的性能（吞吐量、每秒事务数）：

• 线性扩展：性能随着资源的扩展成比例地增加。这种情况并非永久持续，但这可能是其他扩展情况的早期阶段；
• 竞争：架构的某些组件是共享的，而且只能串行使用，对这些共享资源的竞争会减少扩展的效益；
• 一致性：由于要维持数据的一致性，传播数据变化的代价会超过扩展带来的好处；
• 拐点：某个因素碰到扩展制约点，从而改变扩展曲线；
• 扩展上限：到达一个硬性极限。该极限可能是设备瓶颈，如总线或互联器件达到吞吐量的最大值，或是一个软件设置的限制（系统资源控制）。

Amdahl扩展定律

通用扩展定律

排队理论

排队理论是用数学方法研究带有队列的系统，提供对队列长度、等待时间（延时）、和使用率（基于时间）的分析方法。在计算领域的许多组件，无论硬件还是软件，都能建模成为队列系统。多条队列系统的模型叫做队列网络。

容量规划

容量规划可以检查系统处理负载的情况，以及系统如何随着负载的增加而扩展。

方法：

• 研究资源极限
• 因素分析
• 负载均衡器
• 分片sharding

资源极限

因素分析

扩展方案

统计

统计的类型包括平均值、标准方差，以及百分位数。

量化性能

要比较问题和对于问题排优先级，需要对问题和问题修复后所带来的性能的潜在提升做量化。一般可用观测或实验的方式做。

平均值

几种平均值：

• 算术平均值：简称平均，数据的总值除以数据的个数；
• 几何平均值：数值乘积的n次方根，n是数值的个数；
• 调和平均值：数值的个数除以所有数值的倒数之和，更适用于利用速率求均值；
• 随着时间变化的平均值：平均值会掩盖瞬时峰值；
• 衰退平均值：用时间间隔测量，但最近时间的权重要比之前时间的权重高。这样做的目的是减小（衰减）短期波动给平均值带来的影响。

标准方差、百分位数、中位数

标准方差：度量数据离散程度；
百分位数：提供数据分布信息；
中位数：大部分数据在哪里。

变异系数

变异系数：CoV、CV，标准方差除以平均值，数值越小意味着数据变异越小。

多重模态分布

系统性能常常出现双模态的情况，比如缓存命中时是低延时，缓存失效时是高延时。

要警惕平均值：

有人在渡平均深度6英寸的河流时淹死。

异常值

异常值：非常少量的极高或极低的数值，看起来并不符合所期望的分布（单一模态或多重模态）。

监视

监视记录数据，可用于容量规划、量化增长、显示峰值的使用情况

基于时间的规律

规律类型：

• 每小时
• 每天
• 每周
• 每月
• 每季度

监测产品

用SNMP协议，系统只要支持SNMP，就可避免在系统上运行客户端程序。

启动以来的信息统计

检查系统自带的自启动以来的信息统计。

可视化

比编码简单且高效。

线图

折线图，X轴是时间，Y轴是平均延时。

散点图

散点图能揭示异常值的存在。数据太多，或太靠近横轴不易于分析。

热图

热图通过把X和Y轴的区域分组量化，解决散点图的扩展问题，所分成的组称为桶，桶带涂色，颜色是依据落在X和Y轴区域内的事件数目而定的。这样量化既解决散点图可视化密度上的限制，又使得热图不管显示的是单个系统还是成千上万个系统，都可以用一样的方法。热图能用于分析延时、使用率等指标。

问题是它并不像线图那么直观，分析有一定门槛。

表面图

表面图呈现的是一个三维的平面。

如果需要的话，色度和饱和度也能被用上，为可视化增加第四和第五维度的数据值。

可视化工具

包括：Joyent、DTrace