如何衡量Linux性能,避免最典型的错误:CPU篇

在本系列中,我们将讨论Linux性能衡量,以及如何正确测量它。 Linux性能是一个非常广泛的主题,因此,我们将重点关注通常会提高系统性能的四个主要资源--CPU,内存,磁盘存储和网络。

现在,当我们讨论组件相关的性能时,很多场景只需要你增加CPU的配额即可解决问题。但是这也许不是您想要做的,并且您想了解真正导致的原因以及解决方法。

您至少需要了解特定资源的资源利用率来自何处,因为这就是您可以更改应用程序工作负载的方式。

排队和并发

现在,我认为,要了解资源的另一件重要事情,就是要了解,当您拥有CPU资源时,它们具有某种自然并发性,我们可以利用它来执行工作负载。

因此,例如,如果您查看自己的CPU,它可能具有多个频率CPU内核,它们可以并行执行或多或少地执行。但是,如果您在CPU中有更多任务,则可以将它们排队。如果您有spinning磁盘,则它一次也只能执行一个I/O请求。

您的RAID卷或SSD可以一次执行更多操作。但是它们所有人都有某种并发性,它们可以很好地执行,随后发生排队。

排队有什么不好?排队增加了执行时间(延迟),而延迟正是您的最终用户体验性能的方式。

如果您想了解有关该方法的更多信息,则它不仅适用于Linux,还适用于其他系统,我建议您检查一下这种USE方法-利用率,饱和度和错误。

平均负载

让我们从Linux中常见的一些典型错误开始。我认为我们最常见的误解之一是平均负载。在很多情况下,我看到人们正在读取平均负载,也许对此进行了一些监视,然后说:“哦,这是个神奇的数字–如果平均负载大于5,那就不好了”。

我认为这是一个问题。例如,该服务器的平均负载相当高,在40到60之间浮动,但是我可以断定该服务器具有80个CPU内核,而且还算不算什么。

您能告诉我有关此服务器负载的哪些信息?

虽然可以使用平均负载来深入了解您的系统,但很多人并没有真正理解它,而是将其视为一个神奇的数字。

我们看到平均负载有哪些问题?

一是它确实将I/O和CPU使用率混合在一起。您可能需要非常大量的I/O工作量和非常大量的CPU工作量。他们俩的平均负载可能都很高,所以您真的不太清楚这是什么。

它没有真正标准化。正如我所提到的,您可以创建VM仅具有一个CPU内核,或者我们的生产系统具有100个CPU内核,存在两个数量级的差异。

确实,这意味着它们无法使用自己的“魔幻数字”,而十年前或更早的时候,当所有服务器都具有一个,两个或四个CPU内核时,我们可以使用它们。在这些情况下,平均负载20对于服务是不正常的。

它没有被标准化,并且还具有很多计算工件,尤其是在Linux中。如果您对这些计算工件感兴趣,请从Brandon Gregg的博客中查看。他做了所有出色的工作,而Linux平均负载是他最近写的一件事。

现在,我至少要做的是将I/O负载和CPU负载分开。这基本上是相同的平均负载,但平均分配,在这种情况下,我可以看到,如果我对CPU负载进行标准化,则实际上是很低的,没有等待任务,但是I/O波动不断。

PSI

查看CPU或/和其他一些资源利用率的更好方法是PSI。这是一个新工具。它是新内核中的一部分,它可能不适用于所有Linux发行版,因此,我认为,出于实际目的,它将在几年内有用。

它使我们能够从延迟角度真正了解给定的任务是由什么阻塞的,什么时候是由于空闲的CPU运行队列,等待磁盘I/O或由于内存压力而被阻塞的。

它为我们提供了有关性能及其对最终用户的影响的很好的信息,而不是关注人们通常想做的“魔术数字”。想了解更多可以阅读此博客

eBPF

您现在可以做的是使用eBPF,这对于监控来说是很棒的事情。您可以使用多种方式使用和使用该信息,例如,有一个Cloudflare导出器,您可以在其中将这些信息提供给Prometheus进行监视。

这是BCC工具集合中的一个命令行工具,您可以在其中实际查看运行队列延迟,或在CPU上计划任务之前需要花费多少时间。

如果应用几乎立即被调度,则意味着有可用的CPU,而且无论您使用哪种CPU使用率图,等待的时间不长。如果等待的实际很长,那么意味着很长一段时间你的程序都没有被调度。

在这种情况下,好事是他们会处理一些复杂的情况,仅CPU使用率不会显示。例如,Linux CPU调度程序是及其复杂的,尤其是在NUMA环境中。

因此,无论执行什么逻辑,如果花很长时间去调度,用户程序都会受到影响。您不能在CPU利用率图表中看到它,但是会在round-queue 延迟信息中看到它。

现在,这是另一个错误。这是Prometheus的一个示例,显然可以告诉我们不同节点的CPU使用率。

其中哪个对应于正在使用的CPU?

我在互联网上看到了很多关于图表的建议,并且可能说:“哦,让我们运行它的查询,所有非空闲状态都使用CPU。”

由于至少有两个重要的误解,实际情况并非如此:

1. iowait 是 idle

从CPU的角度来看,CPU为一种iowait状态时处于空闲状态。

是的,为方便起见,决定为该状态添加另一个状态-当没有磁盘I/O时的空闲状态,而当有磁盘I /O的空闲状态。

但是从CPU的角度来看,如果您的系统在I/O状态下显示99 CPU,那么这不是CPU瓶颈,而是I/O瓶颈。

2. steal 是虚拟机不可用的CPU

在VM环境和某些云环境中,steal与CPU相对应,CPU在您所做的任何事情上都没有被应用程序真正使用。

它指的是邻居的虚拟机。由于CPU在虚拟环境中共享,因此另一个VM可能正在同一CPU内核上从您身上steal CPU周期。

更多 CPU 带来的乐趣

了解CPU性能会带来更多乐趣。因此,例如,现代CPU随负载改变其频率。有时可能高达5倍。

另外,系统可提供的峰值核心频率取决于负载--特别是您在一个核心上运行的负载-以及使用的核心数量。

更不用说虚拟内核在实际内核方面并不相同。

从利用率的角度来看,在这种情况下,如果您的CPU使用率接近饱和,那么到处都会看到这种情况。

但是了解容量规划很重要,因为如果您知道应用程序随工作负载线性增长,并且可以看到CPU使用率仅为5%,则可能会猜到您的应用程序至少可以增长20倍。

对于如今如何扩展CPU的复杂数学而言,情况可能并非如此。

PS: 本文属于翻译,原文

发布于 2020-09-03 11:44