书籍简介
《性能之巅》原名《System Performance：Enterprise and the Cloud》，作者Brendan是系统性能领域专家，曾供职与Sun和Oracle，也是动态追踪工具DTrace的主力开发人员。这本书以操作系统为背景讲解操作系统和应用程序的性能，本书的讲解和实例都是以Linux系统和Solaris系统为基础的，但是讲述的方法确是对各个系统都通用的。本书有很大部分内容都是和操作系统相关的，诸如CPU、内存、磁盘、文件系统等，一看目录你甚至觉得和大学课本《操作系统》的内容没有差异，但大学课本里的内容更偏学术，学完发现和实际软件开发联系不上，本书的内容则和实际的软件系统息息相关，也有详细的实例分析。
本书的开篇引用了美国国防部长唐纳德·拉姆斯菲尔德的一句话：“有已知的已知，有已知的未知，也有未知的未知”。对于性能分析，有些事情我们知道自己知道，有些事情我们知道自己不知道，但有更多的事情我们不知道自己不知道。即性能分析是很复杂的一件事情，我们不能奢求自己知道所有，只有我们掌握了方法，能以之去分析未知的事情，转换未知为已知即可。
性能分析概述
这部分即书中的“绪论”部分，主要介绍了一些与系统性能分析相关的事情。
- 系统性能涵盖内容
系统性能分析是对整个系统的性能研究，包括了所有的硬件组件和整个软件栈，整个软件栈包括应用程序层、数据库、操作系统内核。 - 系统性能涉及的人员
系统管理员、技术支持人员、应用开发者、数据库管理员和网络管理员。 - 系统性能涉及的事情
（1）设置性能目标和建立性能模型
（2）基于软件或硬件原型进行性能特征归纳
（3）对开发代码进行性能分析（软件整合之前）
（4）执行软件非回归性测试（软件发布前或者后）
（5）针对软件发布版本的基准测试
（6）目标环境中的的概念验证测试
（7）生产环境部署的配置优化
（8）监控生产环境中运行的软件
（9）特定问题的性能分析 - 性能分析视角
（1）资源分析
资源分析一般是系统管理员做，一般会分析资源的使用情况，看其是否是性能瓶颈，或者对其何时会耗尽做预测。涉及的系统资源有：CPU、内存、磁盘、网卡、总线以及之间的互联。适合资源分析的指标有：IOPS、吞吐量、使用率、饱和度。（下文会详细解释这些指标）。
（2）工作负载分析
工作负载分析是对应用程序施加负载，看其如何响应，一般是开发人员和技术支持人员做，工作负载分析的对象有：请求（所施加的工作负载），延时（响应时间），完成度（查找错误）。适合负载分析的指标有：延时，吞吐量。
性能分析相关术语
- IOPS
每秒发生的输入/输出操作的次数，是数据传输的一个度量方法。对于磁盘的读写，IOPS是指每秒读和写的次数。 - 吞吐量
评价工作执行的速率，尤其是数据传输方面，用于描述数据传输的速度（字节/秒，比特/秒）。在某些情况下（比如数据库），吞吐量是指操作的速度（每秒操作数/每秒业务数）。 - 响应时间
一次操作完成的时间，包括用于等待服务和返回结果的时间。 - 延时
操作里用来等待服务的时间，不包括发挥结果的时间。也可以指整个操作的时间，这时等同于响应时间。 - 使用率
使用率有有两种定义方法，一种是基于时间的，一种是基于容量的。
基于时间的定义：U=B/T，B表示忙碌时间，T表示观测周期，也称为忙碌百分比。这时当使用率为100%时，磁盘/cpu也能处理更多的任务。
基于容量的定义：系统或组件（例如硬盘）都能提供一定数量的吞吐，不论性能处于何种级别，系统或组件都工作在其容量的一定比例上。这个比例就成为使用率。这时候，当使用率为100%时，磁盘/cpu已不能处理更多的任务。 - 饱和度
随着工作量的增加而对资源的请求超过资源所能处理的程度叫饱和度，即某一资源无法满足服务的排队工作量，饱和度发生在资源使用率100%（基于容量）时。 - 瓶颈
限制系统性能的那个资源。 - 工作负载
系统的输入或者是对系统所施加的负载。对数据库来说，工作负载就是客户端发送的数据库请求和命令。 - 缓存
用于复制或者缓冲一定量数据的高速存储区域，目的是为了避免对较慢存储区层级的直接访问。
衡量缓存性能的指标：有命中率和失效率。
命中率=所需数据在缓存中找到的次数/（命中次数+失效次数），命中率越高越好。失效率指每秒钟缓存失效的次数。
缓存算法：最近最常使用算法（MRU），最近最少使用算法（LRU），这两种算法用来决定什么样的数据应该保留在缓存里，什么样的数据应该移除缓存。还有“最常使用算法”，“最不常使用算法”
缓存的热、温、冷：冷缓存是空的或者填充的数据是无用的，命中率为0或接近0；热缓存是指命中率很高的缓存，一般命中率高于99%；温缓存是指有用的缓存但命中率没达到预期的高度。
缓存的热度：即指缓存的冷、热、温，提高缓存的热度即提高缓存命中率
性能分析常用概念
- 时间量级
系统各个组件的操作时间存在很大的差异，比如CPU、磁盘、缓存的操作是纳秒级别的，而网络传输是是毫秒级别的，软件程序操作是秒级别的，系统重启则是分钟级别的。在性能分析的过程中，读这些操作的时间有一定概念是十分重要的。 - 权衡三角
系统性能总是在以下两个权衡三角中的三个因素中做取舍，只能择期二。
- 调整的影响
在性能分析找到问题之后，需要做一些调整已达到期望的性能。一般来说，性能调整发生在越靠近工作执行的地方效果越显著，即在应用层级的调整（比如数据库查询优化）带来的性能提升效果显著大于在存储设备层级（精简或提高存储I/O）。常用的调优对象如下图：
- 性能建议时间点
环境的特性会随着时间改变，更多的用户、新的硬件、升级后的软件或固件都是变化因素。性能推荐，尤其是调整的参数值，仅仅在一段特定时间内有效。在网上找到的推荐参数值有时可以快速起效，但有时根本没用，因为参数是和你的系统特性息息相关的。 - 负载vs架构
性能差的可能原因有二，一可能是由负载过大引起的，二可能是由架构引起的（包括软件架构和硬件架构）。 - 扩展性
负载增加下的系统表现的性能成为扩展性，性能快速下降的原因有二，cpu负载过高，磁盘I/O出现排队情况。 - 观察者效应
为了收集这些性能指标是有一定开销的，会对目标的性能产生一定影响，被称为“观察者效应”。
性能分析方法
- 街灯讹方法
随便找一个工具，用来分析性能，找到什么问题就解决什么问题，但不一定是你真正想要解决的问题。 - 随机变动讹方法
猜测问题可能存在的地方，然后做改动，然后测试，直到问题消失。即猜测—》改动—〉测试—》猜测—〉改动—》测试…这样做没有人真正了解其中的缘由，会有一个风险，就是当系统在搞负载的时候，又可能出现更恶劣的问题，所以保险起见需要准备一个回退方法。 - 责怪他人讹方法
找到一个不是自己负责的组件或环境（第三方），假定这个问题是他们引起的，然后让他们排查问题，如果不是，又找另一个第三方。 - ad Hoc核对清单法
在部署新环境时，技术支持人员会有一份系统在真实环境下的问题清单，然后一一核对检查。 - 问题陈述法
通过询问用户/客户来定位问题根因并找到解决方案。 - 科学法
描述问题–》提出假设–》预测问题根因–》做实验–》分析实验结果。 - 诊断循环
假设、仪器检验、数据、假设（和科学法类似）。 - 工具法
列出可能用到的测试工具—》对每一个工具，列出它提供的有用指标—〉对于每一个指标，列出阐释该指标可能的规则。工具太多，比较耗时；和街灯法一样，你并不清楚你问题根因所在，解决的问题可能并不是导致性能差的根因。 - USE方法（utilization、saturation、errors）
即对所有的资源查看其使用率、饱和度和错误。
常用指标：使用率、饱和度、错误，使用率的监测需要尽量细致一点，有的监测的是5min，可能会忽略瞬时的使用率达到100%的情况。
资源列表（尽可能完整）：cpu、内存、网路接口、存储设备（磁盘）、控制器（存储、网络）、互联（cpu、内存、I/O）
常用指标建议：使用率（100%的使用率通常是瓶颈的信号，使用率超过60%就有可能有性能问题）；饱和度（只要饱和度非0就都是问题，有饱和度即表明有排队的任务。）；错误（任何错误都是值得研究的） - 工作负载特征归纳
（1）工作负载是谁产生的？ 进程ID？用户ID？远端的IP地址？
（2）负载为什么会被调用？ 代码路径？堆栈跟踪？
（3）负载的特征是什么？IOPS、吞吐量、方向类型（I/O）？
（4）负载是怎样随着时间变化的，有日常模式吗？ - 向下挖掘分析
监测：用于持续记录。高层级的统计数据，如果问题出现，就予以辨别和报警（监控）。
识别：对于给定问题，缩小研究范围，找到可能的瓶颈。
分析：对特定的系统部分做进一步检查，找到问题根源并量化问题。 - 延时分析
分析检查完成一项操作所用的时间，然后把时间分成再小的时间段，接着对有着最大延时的时间段做再次的划分，最后定位到根因。与深度分析一样，延时分析也会深入到软件的各个层级区找到延时的原因。 - R方法
是针对Oracle数据库开发的性能分析方法，主要分析oracle数据库的查询和操作的延时 - 事件追踪
事件包括cpu指令、磁盘I/O、磁盘命令、网络包、系统调用、函数调用、应用程序事件、数据库查询等。通过工具去追踪这些事件的耗时，比如说tcpdump，iosnoop，strace，truss。 - 基础线统计
就是在进行性能测试前，要先做一个当前性能的统计记录作为基础线，这样才能与之后做性能调优之后的数据做对比。
可以不定期的做基础线统计，如果是监测的话可以按固定时间间隔做基础线统计。 - 静态性能调整
调整处理架构配置的问题。其他方法着重的是负载施加后 的性能，而静态调整是没有施加负载的情况下调整的。 - 缓存调优
（1）确认缓存的大小尽量和栈的高度一样，靠近工作执行的地方，减少缓存命中的开销。
（2）确认缓存开启并确实工作
（3）确认缓存的命中/失效比例和失效率
（4）如果缓存的大小是动态的，确认它当前的尺寸
（5）针对工作负载调整缓存
（6）针对缓存调整工作负载
（7）注意二次缓存，相同的数据被缓存了两次 - 微基准测试
人工施加负载进行测试
容量规划
容量规划可以检查系统处于负载的情况，以及系统如何随着负载的增加而扩展。容量规划的方法有资源极限和因素分析
- 资源极限
研究在负载之下可能会成为系统瓶颈的资源，步骤如下：
（1）测量服务器请求的频率，并监测请求频率随时间的变化；
（2）测量硬件和软件的使用，监测使用率随时间的变化；
（3）用资源的使用来表示服务器的请求情况；
（4）根据每个资源来推断服务器请求的极限。 - 因素分析
在部署和购买新系统的时候，通常需要调整诸多因素已达到理想的性能。一般来说需要以最小的成本来达到理想的性能。但因素太多，如果全都一个个试，成本太大，所以用因素分析来进行容量规划，步骤如下：
（1）测试所有因素都处于最大时的性能；
（2）逐一改变因素测试性能（应该是每一个因素的改动都会引起性能的下降）；
（3）基于测量结果，对每个因素的变化引起的性能下降百分比和节省的成本做统计；
（4）将最高的性能（成本）作为起始点，选择能节省成本的因素，同时确保组合后的性能下降仍满足所需的每秒请求数；
（5）重新测试改变过的配置，确认所交付的性能。 - 扩展方案
垂直扩展：为满足更高的性能要求，需要建立更大的系统
水平扩展：将负载分散给许多的系统，在这些系统前放置负载均衡器，但这些系统仍然看起来是一个系统
可视化
性能分析需要量化，更需要可视化，一般用为性能分析的可视化图有线图、散点图、热图、表面图。
总结
这本书的内容实在是很多，干货也很多，这篇博客里面的内容只包含了书中的第一章绪论和第二张方法的内容。对于系统性能的初学者而言，这两章的内容可以作为入门基础。博主是一个敏捷项目中的QA，非性能测试专职人员，也不是技术支持或运维人员，看这本书的初衷只是了解一些系统性能的基本知识，为了在今后的工作中听到人谈性能相关问题不至于两眼抹黑啥也不知道。性能分析或者性能测试是很复杂的一块内容，博主暂时没打算深入研究，所以这本书也就只读到第二章了，有想要深入研究的小伙伴可以下载该书仔细研究。
