1. USE 方法概述
USE 方法（Utilization、Saturation、Errors）是由 Brendan Gregg 提出的一种面向系统资源的性能检查方法论。它通过三个核心指标——利用率、饱和度和错误数——对每一个硬件或软件资源进行快速评估，从而定位性能瓶颈。该方法特别适用于基础设施层（CPU、内存、磁盘、网络、控制器等）的节点资源评审。
1.1 起源与背景
在分布式系统和云计算环境中，运维人员面对大量节点和复杂资源栈，传统“逐层排查”效率低下。Brendan Gregg 在 2013 年总结出 USE 方法，旨在提供一种可重复、可教学、高覆盖率的检查框架。其核心假设是：任何资源在成为瓶颈时，必然表现为高利用率、高饱和度或持续错误中的至少一种。
适用场景：物理服务器、虚拟机、容器节点、存储阵列、网络交换机等所有具备可量化资源的系统。不适用于应用程序内部逻辑（如代码效率、算法复杂度）的排查。
1.2 核心思想：三个指标
| 指标 | 英文 | 定义 | 典型问题 |
|---|---|---|---|
| 利用率 | Utilization | 资源处于“忙碌”状态的时间占比（通常以百分比表示） | CPU 使用率 95%，磁盘 I/O 等待时间占比高 |
| 饱和度 | Saturation | 资源无法及时服务的额外请求队列长度或等待程度 | CPU 运行队列长度 > 核心数，内存 swap 使用量 |
| 错误数 | Errors | 资源操作中发生的错误事件计数或频率 | 磁盘坏道、网络丢包、内存 ECC 错误 |
三个指标之间存在递进关系：高利用率通常先出现，若持续过载则产生饱和度（排队），最终可能触发错误（超时、重试、硬件故障）。
1.3 USE 方法工作流程
- 枚举资源：列出节点中所有物理和虚拟资源（CPU、内存、磁盘、网络接口、控制器、锁等）。
- 定义指标：对每个资源，明确其利用率、饱和度、错误数的具体测量方式。
- 采集数据：使用系统工具（如
top、iostat、vmstat、sar）获取实时或历史数据。 - 判断瓶颈：若任一指标超过阈值（如利用率 > 80%、队列持续增长、错误率 > 0），则标记为待优化资源。
- 交叉验证：结合应用层性能指标（如延迟、吞吐量）确认影响。
评审要点：在节点资源评审中，USE 方法帮助评审者快速聚焦“哪个资源在什么维度上出了问题”，避免在无关指标上浪费时间。
1.4 USE 方法适用场景对比
| 场景 | 适用性 | 说明 |
|---|---|---|
| 物理服务器性能排查 | ★★★★★ | CPU、内存、磁盘、网络全覆盖 |
| 虚拟机/容器节点 | ★★★★☆ | 需注意宿主机与 Guest 的资源映射 |
| 存储阵列/网络设备 | ★★★★☆ | 端口利用率、缓冲区饱和度、CRC 错误 |
| 数据库实例内部 | ★★★☆☆ | 适用于缓冲池、日志等资源，不适用于 SQL 优化 |
| 应用代码逻辑 | ★☆☆☆☆ | USE 方法不分析代码路径或算法效率 |
1.5 USE 方法核心关系图
1.6 常见误区与避坑
- 误区一：只关注利用率，忽略饱和度和错误数。例如 CPU 使用率 50% 但运行队列很长，说明已经饱和。
- 误区二：将 USE 方法用于应用层指标（如请求延迟、错误率）。USE 方法只针对资源，不针对服务。
- 误区三：认为所有资源都必须同时监控三个指标。部分资源（如内存）的利用率定义需谨慎（已用 vs 活跃），饱和度可通过 swap 或 OOM 事件判断。
评审提醒：在节点资源评审中，务必先完成 USE 方法的“枚举资源”步骤，列出所有资源后再逐项检查，避免遗漏关键组件（如 NUMA 互联、PCIe 带宽）。