使用 USE 法快速定位服务器资源瓶颈

USE（Utilization Saturation and Errors）法可用于分析任何系统的性能，可用于快速定位服务器的资源瓶颈或错误。

介绍

当服务器出现严重的性能问题时，你首先会检查啥？

从何处下手是最难的。我推荐使用 USE 法则来快速解决常见的性能问题，不漏掉关键信息，就像飞行手册的应急检查表那样简单直接快速。USE 法已经在不同的生产还有云计算环境中被无数次被使用成功。它基于三种计量类型，投入 5% 的精力解决 80% 的服务器问题。

USE 法可以被归纳为：检查每个资源的使用率、饱和度和错误数。要在排查性能问题的早期使用，旨在定位系统瓶颈。

• 资源：字面意义上的服务器物理资源（CPU、内存、磁盘等）
• 使用率：资源投入服务的平均时长
• 饱和度：资源的繁忙程度、队列长度或资源已被使用的比例，比如 CPU 的平均运行队列长度为 4
• 错误数：错误事件的数量

低使用率 == 不饱和？

突发的高使用率可能会导致资源饱和与性能问题，即使在很长一段时间内的平均使用率都很低。举个栗子，CPU 饱和度有问题，尽管监控工具显示 CPU 使用率从未超过 80%，而这只是时长 5 分钟的平均数，在这期间有几秒钟 CPU 使用率达到 100%。

资源清单

以下是通用的服务器资源清单：

• CPU：核心、硬件线程
• 内存：容量
• 网卡
• 存储设备：I/O、容量

有些东西就忽略了，像硬件缓存（MMU TLB/TSB，CPU）。对于在高利用率或饱和度状态下出现性能问题导致瓶颈的情况，USE 法最为有效，缓存是锦上添花。缓存命中率和其他性能指标可以在 USE 法之后检查。如果你不确定要不要把某种资源算进来，那就先包含进来再说。

计量

利用率、饱和度和错误数

有些难以测量的就不列出来了，幸运的是易于计量的指标（CPU 饱和度、内存使用率、网卡使用率和磁盘使用率）能够覆盖大多数常见的问题

如何获取这些指标请自行 Google 或者查看我的博客。

实际上要读尽每一种指标耗时耗力。USE 法能够让你意识到是否有项目遗漏，一套组合拳下来也大概心里有数了，后面可以进行更彻底的分析。

软件资源

通常适用于构成软件的组件而不是整个应用程序：

• 互斥锁：使用率可定义为锁被持有的时间；饱和度是排队等锁的线程数量
• 线程池：使用率可定义为线程处理任务的时间；饱和度是等待线程池调度的请求数
• 进程/线程数量：系统（线程池）可能会限制进程/线程的数量，当前使用率就是使用率；饱和度就是等待分配；错误数是分配失败的情况
• 文件描述符数量：同上，只不过是文件描述符

解读

有了计量指标，下一步就是解读它们。有些明显有些则不然，可能取决于工作负载需求或期望。

• 使用率：百分百的使用率通常代表瓶颈（检查饱和度来确认）；高使用率（超过 70%）可能是问题出现的先兆：
  • 如果测算使用率的时间段比较长，70% 的平均使用率可能掩盖掉某次 100% 的突发状况。
  • 有些系统资源（比如硬盘）在操作时是不可以中断的，即使是高优先级的任务。当它们的使用率超过 70%，排队等待也就越频繁。而 CPU 在任何时间都可以被中断（抢占）。
• 饱和度：一般就用等待队列的长度或在队列中等待的时长来衡量，和现实生活差不多，排队没好事。
• 错误数：只要不是 0 就值得一看，不断增长的话就更要看了。

反过来说，我们搭建的系统要尽量做到不那么高的使用率、低饱和度和 0 错误。

云计算

在云计算环境中，一般会对租户限制。hypervisor 或者 cgroup 来限制 CPU、内存、网络和存储。每一种都可以使用 USE 法检查，和物理机差不多。

策略

USE 法流程图如下所示：

USE 法确实可以定位貌似系统瓶颈的问题，但是。。。系统可能存在不止一个问题，你发现的那个可能并不是关键问题。每一个扫到的雷都可以进一步排查和排除，然后根据实际情况使用 USE 方法来排查更多的资源，在完成这些工作后权衡到底是调整负载还是资源（加钱）。

结论

USE 法是一种简单的策略，可以用它来对系统的健康状况进行全面检查，找出常见的瓶颈和错误。一般在早期排查中使用，快速定位问题，如有必要，要用其他方法深入研究。它的优势在于速度和可视化：地毯式检查所有资源，不太有所忽略。然而它的应用面有点窄，只能找到某些类型的问题（瓶颈和错误），相当于前菜。