USE 方法
USE 方法（utilization、saturation、errors）应用于性能研究，用来识别系统瓶颈[Gregg 13]。一言以蔽之，就是：
对 于所有的资源，查看它的使用率、饱和度和错误。
这些术语定义如下。
● 资源：所有服务器物理元器件（CPU、总线……）。某些软件资源也能算在内，提供有用的指标。
● 使用率：在规定的时间间隔内，资源用于服务工作的时间百分比。虽然资源繁忙，但是资源还有能力接受更多的工作，不能接受更多工作的程度被视为饱和度。
● 饱和度：资源不能再服务更多额外工作的程度，通常有等待队列。
● 错误：错误事件的个数。
某些资源类型，包括内存，使用率指的是资源所用的容量。这与基于时间的定义是不同的，这在之前的2.3.11 节做过解释。一旦资源的容量达到100%的使用率，就无法接受更多的工作，资源或者会把工作进行排队（饱和），或者会返回错误，用USE 方法也可以予以鉴别。[2]
错误需要调查，因为它们会损害性能，如果故障模式是可恢复的，错误可能难以立即察觉。这包括操作失败重试，还有冗余设备池中的设备故障。
与工具法相反的是，USE 方法列举的是系统资源而不是工具。这帮助你得到一张完整的问题列表，在你寻找工具的时候做确认。即便对于有些问题现有的工具没有答案，但这些问题所蕴含的知识对于性能分析也是极其有用的：这些是“已知的未知”。
USE 方法会将分析引导到一定数量的关键指标上，这样可以尽快地核实所有的系统资源。在此之后，如果还没有找到问题，那么可以考虑采用其他的方法。
过程
图2.12 描绘了USE 方法的流程图。错误被置于检查首位，要先于使用率和饱和度。错误通常容易很快被解释，在研究其他指标之前，把它们梳理清楚是省时高效的。
图2.12 USE 方法流程
这个方法辨别出的很可能是系统瓶颈问题。不过，一个系统可能不只面临一个性能问题，因此你可能一开始就能找到问题，但所找到的问题并非你关心的那个。在根据需要返回USE 方法遍历其他资源之前，每个发现可以用更多的方法进行调查。
指标表述
USE 方法的指标通常如下。
● 使用率：一定时间间隔内的百分比值（例如，“单个CPU 运行在90%的使用率上”）。
● 饱和度：等待队列的长度（例如，“CPU 的平均运行队列长度是4”）。
● 错误：报告出的错误数目（例如，“这个网络接口发生了50 次滞后冲突”）。
虽然看起来有点违反直觉，但即便整体的使用率在很长一段时间都处于较低水平，一次高使用率的瞬时冲击还是能导致饱和与性能问题的。某些监控工具汇报的使用率是超过5 分钟的均值。举个例子，每秒的CPU 使用率可以变动得非常剧烈，因此5 分钟时长的均值可能会掩盖短时间内100%的使用率，甚至是饱和的情况。
想象一下高速公路的收费站。使用率就相当于有多少收费站在忙于收费。使用率100%意味着你找不到一个空的收费站，必须排在别人的后面（饱和的情况）。如果我说一整天收费站的使用率是40%，你能判断当天是否有车在某一时间排过队吗？很可能在高峰时候确实排过队，那时的使用率是100%，但是这在一天的均值上是看不出的。
资源列表
USE 方法的第一步是要建一张资源列表，要尽可能完整。下面是一张服务器通常的资源列表，配有相应的例子。
● CPU：插槽、核、硬件线程（虚拟CPU）
● 内存：DRAM
● 网络接口：以太网端口
● 存储设备：磁盘
● 控制器：存储、网络
● 互联：CPU、内存、I/O
每个组件通常作为一类资源类型。例如，内存是一种容量资源，网络接口是一类I/O 资源（IOPS 或吞吐量）。有些组件体现出多种资源类型：例如，存储设备既是I/O 资源也是容量资源。这时需要考虑到所有的类型都能够造成性能瓶颈，同时，也要知道I/O 资源可以进一步被当作排队系统来研究，将请求排队并被服务。
某些物理资源，诸如硬件缓存（如CPU 缓存），可能不在清单中。USE 方法是处理在高使用率或饱和状态下性能下降的资源最有效的方法，当然还有其他的检测方法。如果你不确定清单是否该包括一项资源，那就包括它，看看在实际指标中是什么样的情况。
原理框图
另一种遍历所有资源的方法是找到或者画一张系统的原理框图，正如图2.13 所示的那样。这样的图还显示了组件的关系，这对寻找数据流动中的瓶颈是很有帮助的。
CPU、内存、I/O 互联和总线常常被忽视。所幸的是，它们不是系统的常见瓶颈，因为这些组件本身就设计有超过吞吐量的余量。可能你需要升级主板，或者减小负载，例如，“零拷贝”就减轻了内存和总线的负载。
要了解互联的内容，参见第6章6.4.1 节中的CPU 性能计数器介绍。
指标
一旦你掌握了资源的列表，就可以考虑这三类指标：使用率、饱和度，以及错误。表2.5列举了一些资源和指标类型，以及一些可能的指标（针对一般性的OS）。
这些指标要么是一定时间间隔的均值，要么是累计数目。
图2.13 双CPU 系统原理框图示例
表2.5 USE 方法指标示例
续表
重复所有的组合，包括获取每个指标的步骤，记录下当前无法获得的指标，那些是已知的未知。最终你得到一个大约30 项的指标清单，有些指标难以测量，有些根本测不了。所幸的是，常见的问题用较简单的指标就能发现（例如，CPU 饱和度、内存容量饱和度、网络接口使用率、磁盘使用率），所以这些指标要首先测量。
一些较难的组合示例可见表2.6。
表2.6 USE 方法指标的进阶示例

上述的某些指标可能用操作系统的标准工具是无法获得的，可能需要使用动态跟踪或者用到CPU 性能计数工具。
附录A 是针对Linux 系统的一个USE 方法核对清单的范例，囊括了硬件资源和Linux 观测工具集的所有组合。附录B 提供的内容一样，不过针对的是基于Solaris 的系统。两个附录还包含了一些软件资源。
软件资源
某些软件资源的检测方式可能相似。这里指的是软件组件，而不是整个应用程序，示例如下。
● 互斥锁：锁被持有的时间是使用时间，饱和度指的是有线程排队在等锁。
● 线程池：线程忙于处理工作的时间是使用时间，饱和度指的是等待线程池服务的请求数目。
● 进程/线程容量：系统的进程或线程的总数是有上限的，当前的使用数目是使用率，等待分配认为是饱和度，错误是分配失败（例如，“cannot fork”）。
● 文件描述符容量：同进程/线程容量一样，只不过针对的是文件描述符。
如果这些指标在你的案例里管用，就用它们；否则，用其他方法也是可以的，诸如延时分析。
使用建议
对于使用上述这些指标类型，这里有一些总体的建议。
● 使用率：100%的使用率通常是瓶颈的信号（检查饱和度并确认其影响）。使用率超过60%可能会是问题，基于以下理由：时间间隔的均值，可能掩盖了100%使用率的短期爆发，另外，一些资源，诸如硬盘（不是CPU），通常在操作期间是不能被中断的，即使做的是优先级较高的工作。随着使用率的上升，排队延时会变得更频繁和明显。有更多关于60%使用率的内容，参见2.6.5 节。
● 饱和度：任何程度的饱和都是问题（非零）。饱和程度可以用排队长度或者排队所花的时间来度量。
● 错误：错误都是值得研究的，尤其是随着错误增加性能会变差的那些错误。
低使用率、无饱和、无错误：这样的反例研究起来容易。这点要比看起来还有用——缩小研究的范围能帮你快速地将精力集中在出问题的地方，判断其不是某一个资源的问题，这是一个排除法的过程。
云计算
在云计算环境，软件资源控制在于限制或给分享系统的多个租户设定阈值。在Joyent 公司我们主要用OS 虚拟技术（SmartOS Zones），来设定内存限制、CPU 限制，以及存储I/O 的门限值。每一项资源的限定都能用USE 方法来检验，与检查物理资源的方法类似。
举个例子，“内存容量使用率”是租户的内存使用率与他的内存容量的比值。“内存容量饱和”出现于匿名的分页活动，虽然传统的页面扫描器此时可能是空闲的。
