it系统技术评估分析系统性能瓶颈

漂亮女神 2023-04-18 03:27:16

地址：https://www.brendangregg.com/usemethod.html

利用率饱和和误差（USE）方法是一种分析任何系统性能的方法。它指导清单的构建，用于服务器分析可用于快速识别资源瓶颈或错误。它从提出问题开始，然后寻求答案，而不是从给定的指标（部分答案）开始并试图向后工作。

针对不同操作系统的 USE 方法派生清单列在左侧导航面板（Linux、Solaris 等）上。您可以为您的环境自定义这些工具，添加您的站点使用的其他工具。还有性能清单的罗塞塔石碑，从其中一些自动生成。性能监控产品可以通过易于使用的界面提供其指标，从而使 USE 方法更易于遵循。

介绍

出现严重的性能问题，您怀疑这是由服务器引起的。你先检查什么？

入门可能是最困难的部分。我开发了 USE 方法，教其他人如何快速解决常见的性能问题，而不会忽略重要领域。就像飞行手册中的紧急清单一样，它旨在简单、直接、完整和快速。USE方法已经在不同的企业环境，课堂环境（作为学习工具）以及最近的云计算环境中成功使用了无数次。

USE方法基于三种度量类型和接近复杂系统的策略。我发现它用 5% 的努力解决了大约 80% 的服务器问题，并且，正如我将演示的那样，它可以应用于服务器以外的系统。它应该被视为一种工具，一种更大的方法工具箱的一部分。它无法解决许多问题类型，这将需要其他方法和更长的时间跨度。

总结

USE方法可以概括为：

对于每个资源，检查利用率、饱和度和错误。

它旨在用于性能调查的早期，以确定系统瓶颈。

术语定义：
资源：所有物理服务器功能组件（CPU、磁盘、总线等）[1]
利用率：资源忙于服务工作的平均时间 [2]
饱和度：资源具有无法处理的额外工作的程度，通常排队
错误：错误事件的计数

[1] 考虑一些软件资源或软件施加的限制（资源控制）并查看哪些指标是可能的，这可能是有用的。[2] 还有另一个定义，利用率描述了使用的资源的比例，因此 100% 利用率意味着不能再接受更多的工作，这与上面的“忙碌”定义不同。

指标通常用以下术语表示：
利用率：作为时间间隔内的百分比。例如，“一个磁盘以 90% 的利用率运行”。
饱和度：作为队列长度。例如，“CPU 的平均运行队列长度为 4”。
错误：标量计数。例如，“此网络接口发生了 50 次后期冲突”。

应调查错误，因为它们会降低性能，并且在故障模式可恢复时可能不会立即注意到。这包括失败并重试的操作，以及失败的冗余设备池中的设备。
低利用率是否意味着没有饱和？
高利用率的突发可能会导致饱和和性能问题，即使长时间平均利用率时利用率较低。这可能是违反直觉的！

我有一个示例，其中客户遇到了 CPU 饱和（延迟）问题，即使他们的监控工具显示 CPU 利用率从未高于 80%。监控工具报告了五分钟的平均值，在此期间，CPU 利用率一次达到 100%，持续几秒钟。
资源列表
首先，您需要一个要循环访问的资源列表。以下是服务器的通用列表：
CPU：插槽、内核、硬件线程（虚拟 CPU）
内存：容量
网络接口
存储设备：I/O、容量
控制器：存储、网卡
互连：CPU、内存、I/O

某些组件是两种类型的资源：存储设备是服务请求资源（I/O）和容量资源（人口）。这两种类型都可能成为系统瓶颈。请求资源可以定义为排队系统，该系统可以对请求进行排队，然后对请求进行排队。

一些物理组件被排除在外，例如硬件缓存（例如，MMU TLB/TSB，CPU）。对于在高利用率或饱和下性能下降导致瓶颈的资源，USE 方法最有效。缓存可在高利用率下提高性能。

缓存命中率和其他性能属性可以在 USE 方法之后检查 - 在排除系统瓶颈之后。如果不确定是否要包含资源，请包含该资源，然后查看指标的运行情况。
功能框图
迭代资源的另一种方法是查找或绘制系统的功能框图。这些还显示了关系，这在查找数据流中的瓶颈时非常有用。以下是Sun Fire V480指南（第82页）中的一个例子：

我喜欢这些图表，尽管它们可能很难获得。硬件工程师可以是最好的资源 - 实际构建东西的人。或者您可以尝试绘制自己的。

在确定各种总线的利用率时，请在功能图上注释每条总线及其最大带宽。这会产生一个图表，在该图表中，可以在进行单次测量之前识别系统瓶颈。（在硬件产品设计期间，当物理组件可以更改时，这是一个有用的练习。
互连
CPU、内存和 I/O 互连经常被忽视。幸运的是，它们通常不是系统瓶颈。不幸的是，如果是，可能很难做很多事情（也许你可以升级主板，或减少负载：例如，“零拷贝”项目减轻内存总线负载）。使用USE方法，至少您可以意识到自己没有考虑的问题：互连性能。有关我使用 USE 方法确定的互连问题的示例，请参阅分析超级传输。
指标
给定资源列表，请考虑指标类型：利用率、饱和度和错误。

以下是一些示例。在下表中，考虑每种资源和指标类型，看看是否可以填写空白。将鼠标悬停在空单元格上将显示一些可能的答案，用通用的Unix / Linux术语描述（您可以更具体）：

资源类型度量

单击此处显示全部。我省略了时间：这些指标要么是每个间隔的平均值，要么是计数。我还省略了如何获取它们：对于您的自定义清单，包括要使用的操作系统工具或监控软件，以及要读取的统计信息。对于不可用的指标，请填写“？”。您最终会得到一个简单快捷的清单，并且对于您的系统来说尽可能完整。
更难的指标
现在对于一些更难的组合（再次，尝试先考虑这些！

资源类型度量

单击此处显示全部。这些通常更难测量，具体取决于操作系统，我经常需要编写自己的软件来执行它们（例如，分析HyperTransport中的“amd64htcpu”脚本）。

对所有组合重复此操作，并包含获取每个指标的说明。您最终会得到一个包含大约 30 个指标的列表，其中一些无法测量，其中一些很难测量。幸运的是，最常见的问题通常是通过简单的问题（例如，CPU饱和，内存容量饱和，网络接口利用率，磁盘利用率）找到的，可以先检查。

有关 Linux、Solaris、Mac OS X、FreeBSD 等的示例清单，请参阅本页顶部。
实践中
读取操作系统上每个组合的指标可能非常耗时，尤其是在您开始处理总线和互连指标时。您可能只有时间检查一个子集：CPU、内存容量、存储容量、存储设备 I/O、网络接口。这比听起来要好！USE方法让你意识到你没有检查的东西：曾经未知的未知现在是已知的未知的。在对公司来说至关重要的是导致性能问题的时候，您已经有一个已知额外工作的待办事项列表，可以执行这些工作以进行更彻底的分析，在真正需要的时候完成 USE 方法。

希望易于检查的指标子集随着时间的推移而增长，因为更多的指标被添加到操作系统中以使USE方法更容易。性能监控软件也可以提供帮助，添加USE方法向导来为您完成工作。
软件资源
可以以类似的方式考虑某些软件资源。这通常适用于软件的较小组件，而不是整个应用程序。例如：
互斥锁：利用率可以定义为锁的持有时间;那些排队等待锁的线程的饱和度。
线程池：利用率可以定义为线程忙于处理工作的时间;饱和度由等待线程池处理的请求数。
进程/线程容量：系统可能具有有限数量的进程或线程，其当前使用情况可以定义为利用率;等待分配可能饱和;错误是指分配失败（例如，“无法分叉”）。
文件描述符容量：与上述类似，但用于文件描述符。

不要为这种类型出汗。如果指标运行良好，请使用它们，否则软件可以留给其他方法（例如，延迟）。
建议的解释
USE 方法可帮助您确定要使用的指标。在学习如何从操作系统读取它们之后，您的下一个任务是解释它们的当前值。对于某些人来说，解释可能是显而易见的（并且有据可查）。其他的，不是那么明显，可能取决于工作负载要求或期望。

以下是解释指标类型的一些常规建议：
利用率：100% 利用率通常是瓶颈的标志（检查饱和度及其影响以确认）。高利用率（例如，超过70%）可能开始成为一个问题，原因如下：
当在相对较长的时间段（多秒或多分钟）内测量利用率时，总利用率（例如 70%）可以隐藏 100% 利用率的短暂突发。
某些系统资源（如硬盘）在操作期间不能中断，即使对于优先级较高的工作也是如此。一旦它们的利用率超过 70%，排队延迟就会变得更加频繁和明显。将其与 CPU 进行比较，CPU 几乎可以随时中断（“抢占”）。
饱和度：任何程度的饱和度都可能是一个问题（非零）。这可以衡量为等待队列的长度，或在队列上等待所花费的时间。
错误：非零错误计数器值得研究，尤其是在性能较差的情况下它们仍在增加的情况下。

很容易解释负面情况：利用率低，没有饱和度，没有错误。这比听起来更有用 - 缩小调查范围可以迅速将焦点集中在问题区域。
云计算
在云计算环境中，可以实施软件资源控制来限制或限制共享一个系统的租户。这可能包括对内存、CPU、网络和存储 I/O 的虚拟机监控程序或容器（cgroup）限制。外部硬件也可能施加限制，例如网络吞吐量。可以使用 USE 方法检查这些资源限制中的每一个，类似于检查物理资源。

例如，在我们的环境中，“内存容量利用率”可以是租户的内存使用情况与其内存上限。“内存容量饱和”可以通过匿名分页活动看到，即使传统的Unix页面扫描程序可能处于空闲状态。
策略
USE方法如下图所示。请注意，可以在使用和饱和之前检查错误，作为次要优化（它们通常更快，更容易解释）。

USE 方法可识别可能是系统瓶颈的问题。不幸的是，系统可能会遇到多个性能问题，因此您发现的第一个问题可能是问题，但不是问题。每个发现都可以使用进一步的方法进行调查，然后根据需要继续使用 USE 方法以迭代更多资源。

进一步分析的策略包括工作负载特征描述和向下钻取分析。完成这些操作（如果需要）后，应有证据证明纠正措施是调整应用的负载还是调整资源本身。
阿波罗
我之前说过，USE方法可以应用于服务器之外。为了找一个有趣的例子，我想到了一个我完全没有专业知识，也不知道从哪里开始的系统：阿波罗登月舱制导系统。USE 方法提供了一个简单的尝试过程。

第一步是找到资源列表，或者更好的是，找到一个功能框图。我在“登月舱 - LM10 至 LM14 熟悉手册”（1969 年）中找到了以下内容：

其中一些组件可能不具有利用率或饱和特性。在遍历它们之后，可以将其重新绘制为仅包含相关组件。（我还会包括更多：内存的“可擦除存储”部分，“核心设置区域”和“vac区域”寄存器。

我将从阿波罗制导计算机（AGC）本身开始。对于每个指标，我浏览了各种 LM 文档，看看哪些可能有意义：
AGC 利用率：这可以定义为执行作业（不是“虚拟作业”）的 CPU 周期数除以时钟速率（2.048 MHz）。这个指标在当时似乎已经得到了很好的理解。
AGC 饱和度：这可以定义为“核心集区域”中的作业数，即存储程序状态的七组寄存器。如果更高优先级作业的中断到来，这些允许暂停作业（通过“EXECUTIVE”程序 - 我们现在称之为“内核”）。一旦耗尽，它将从饱和状态变为错误状态，AGC 报告 1202“执行溢出 - 无核心集”警报。
AGC 错误：定义了许多警报。除了 1202 之外，还有一个 1203 警报“候补名单溢出-任务太多”，这是一个不同类型的性能问题：在恢复正常作业调度之前正在处理太多定时任务。与 1202 一样，定义一个饱和度指标（即 WAITLIST 的长度）可能很有用，这样就可以在溢出和错误发生之前测量饱和度。

其中一些细节对于太空伦理学家来说可能很熟悉：1201（“无真空区域”）和1202警报在阿波罗11号下降期间发生了著名的警报。（“VAC”是“矢量累加器”的缩写，用于处理矢量数量的作业的额外存储空间;我认为维基百科对“空缺”的描述可能是不正确的）。

鉴于阿波罗 11 号的 1201 警报，分析可以继续使用其他方法，例如工作负载表征。工作负载主要通过中断应用，其中许多可以在功能图中看到。这包括用于跟踪指挥舱的会合雷达，即使LM正在执行下降，它也会中断AGC的工作。这是寻找不必要工作（或低优先级工作;雷达的一些更新可能是可取的，以便LM AGC可以在需要时立即计算中止轨迹和CM会合）的示例。

作为一个更难的例子，我将把会合雷达作为一种资源进行研究。错误是最容易识别的。有三种类型：“数据不好”、“无轨道”和“轴和耳轴误差”信号。利用更难：一种类型可能是驱动电机的利用 - 定义为它们忙于响应角度命令的时间（在功能图中通过“耦合数据单元”看到）。我需要阅读更多LM文档，以查看驱动电机或返回的雷达数据是否存在饱和特性。

在很短的时间内，使用这种方法，我已经从不知道从哪里开始，到有特定的指标来寻找和研究。
其他方法
虽然USE方法可以发现80%的服务器问题，但基于延迟的方法（例如，方法R）可以接近找到100%的所有问题。但是，如果您不熟悉软件内部，这些可能需要更多时间。它们可能更适合已经熟悉此情况的数据库管理员或应用程序开发人员。USE 方法更适合初级或高级系统管理员，其职责和专业知识包括操作系统（OS）和硬件。当需要快速检查系统运行状况时，这些其他员工也可以使用它。
工具方法
为了与 USE 方法进行比较，我将描述一种基于工具的方法（我称之为“工具方法”）：
列出可用的性能工具（可选择安装或购买更多）。
对于每个工具，列出它提供的有用指标。
对于每个指标，列出可能的解释规则。

其结果是一个规范性清单，显示要运行的工具、要读取的指标以及如何解释它们。虽然这可能相当有效，但一个问题是它完全依赖于可用（或已知）的工具，这些工具可以提供不完整的系统视图。用户也不知道他们的视图不完整 - 因此问题仍然存在。

相反，USE 方法遍历系统资源以创建要提出的问题的完整列表，然后搜索工具来回答这些问题。构建更完整的视图，记录未知区域并已知其存在（“已知未知”）。基于 USE，可以开发一个类似的清单，显示要运行的工具（如果可用）、要读取的指标以及如何解释它。

另一个问题可能是，当迭代大量工具会分散目标的注意力 - 找到瓶颈。USE 方法提供了一种策略，可以有效地查找瓶颈和错误，即使使用数量庞大的可用工具和指标也是如此。
结论
USE 方法是一种简单的策略，可用于执行完整的系统运行状况检查，识别常见的瓶颈和错误。它可以在调查的早期部署，并快速识别问题区域，然后如果需要，可以更详细地研究其他方法。USE的优势在于它的速度和可见性：通过考虑所有资源，您不太可能忽略任何问题。但是，它只会发现某些类型的问题 - 瓶颈和错误 - 并且应该被视为更大工具箱中的一个工具。

我在此页面上解释了 USE 方法，并提供了指标的通用示例。请参阅特定操作系统的左侧导航窗格中的示例清单，其中建议应用USE方法的工具和指标。

另请参阅基于线程的补充方法，即TSA 方法。
,