PMM中的饱和度量值（Saturation Metrics）

PMM 1.2添加新图形之一是饱和度度量（Saturation Metrics）标准。这篇博文解释如何使用这些图表提供的信息。

您可能听说过Brendan Gregg的USE方法（利用率 – 饱和度 – 误差）作为分析任何系统性能的方法。我们在PMM中的目标是随着时间的推移完全支持这种方法，这些图表使我们向前迈进了一步。

在利用率方面，PMM中有许多图表。有CPU使用情况图：

 还有磁盘IO利用率：

还有网络流量：

如果您想查看饱和度类型，则有经典的负载平均图：

虽然Load Average有助于理解系统饱和度，但它并不能真正区分CPU或磁盘是否饱和。正如名称所说，Load Average已经平均，所以我们无法真正观察到负载平均值的短暂饱和尖峰。最后，Load Average的问题是它没有考虑到CPU核心/线程的数量。例如，假设我的CPU负载平均值为16。如果你有两个CPU线程，这是一个相当的负载，并会导致高饱和度和排队。但是如果你有64个线程，那么16就变成了一个无关紧要的负载。

我们来看看饱和度量图：

它为我们提供了两个指标：一个显示CPU负载，另一个显示IO负载。这些值大致对应于VMSTAT输出中的“r”和“b”列：

每秒采样一次，然后在报告间隔内进行平均。这里主要说明一下’r’和’b’列含义，为下面工作做铺垫。

r：表示运行队列，就是说多少个进程真的分配到CPU，当这个值超过了CPU数目，就会出现CPU瓶颈了。top命令显示的负载类似每秒的运行队列。如果运行队列过大，表示你的CPU很繁忙，一般会造成CPU使用率很高。

b：表示阻塞的进程，一般为0，如果这个值大于0就证明CPU过载了。

我们通过将正在运行进程数除以多个可用线程来标准化CPU负载。“Rocky”有56个线程，这就是为什么标准化的CPU负载大约为1，即使VMSTAT显示的系统运行进程的数量大约为50。

但我们没有标准化IO负载，因为系统可以有多个IO设备，并且他们可以并行处理多少请求在很大程度上是未知的。如果您想了解特定的IO设备性能，则应查看磁盘性能仪表板。

在实践中测试饱和度量

让我们看看饱和度图是否确实向我们展示了何时CPU饱和度成为问题。我将使用sysbench CPU测试进行说明，运行如下：

这将使用多个线程来执行计算作业，每个计算作业将计算素数的数量（cpu-max-prime用来指定最大的素数）。如果我们有足够的CPU资源可用，没有饱和，执行这些请求的延迟应该大致相同。当我们系统过载时，所以没有足够的CPU执行单元来处理并行中的所有内容，平均延迟时间应该会增加。

正如我们在一个线程中看到的那样，处理单个请求所需的平均时间是23ms。显然，在这种情况下没有发生饱和：

测试主机有四个CPU核心，正如您所看到的，标准化CPU负载保持在一个以下。你可能想知道为什么在这种情况下它不接近0.25，当只有一个活动线程和四个核心可用时？原因恰恰在于度量值被捕获的时候，通常会出现另外两到三个线程来激活该进程。它们只在很小的时间内处于活动状态，所以不会产生太多的负载，但它们往往会使标准化CPU负载值倾斜一点点。

现在我们运行四个线程，线程数量与可用的CPU核心数量相匹配（还未超线程）。在这种情况下，不要期望事件处理时间增加太多。

正如您所看到的，测试证实了这一理论，我们的平均延迟增加了大约6％，而饱和度指标中的标准化CPU负载大部分徘徊在1到2之间：

现在让我们用16个线程进行测试，这是可用CPU核心的四倍。由于CPU过载（或饱和），我们应该看到延迟急剧增加。如果你有比CPU更多的并发性，你的CPU绑定的MySQL查询也会发生同样的情况。

由于CPU过载和排队，我们可以看到处理每个请求需要四倍的时间。让我们看看饱和度指标告诉我们什么：

正如您所看到的，标准化CPU负载在图形上的四到五之间浮动，与我们观察到的饱和度一致。

您可能会问，CPU利用率图可以帮助我们吗？不是真的，对于4线程和16线程的运行，您将看到100％的CPU使用率，而请求延迟则完全不同。

总结

从我们的测试中可以看出，标准化CPU负载对于了解CPU何时过载非常有用。过载的CPU会导致响应时间增加，性能下降。此外，你可以用它来（粗略地）看看过载有多严重。作为一个经验法则，如果您看到标准化的CPU饱和度超过2，则表示您的CPU过载。

<原文>

http://www.brendangregg.com/usemethod.html

https://www.percona.com/blog/2017/08/04/saturation-metrics-in-pmm-120/

喜欢 (0)赏

[资助本站您就扫码 谢谢]

分享 (0)