磁盘延迟导致 EC2 实例上的 CPU 峰值

Posted 2023-03-17

【中文标题】磁盘延迟导致 EC2 实例上的 CPU 峰值

【英文标题】：Disk latency causing CPU spikes on EC2 instance

【发布时间】：2020-10-07 03:50:28

【问题描述】：

我们遇到了一个有趣的问题，我们在 EC2 实例上看到 CPU 峰值，同时我们看到磁盘延迟峰值。这是 CPU 峰值的模式

CPU 在 30 秒内从 50% 飙升至 100% 在两分钟内保持 100% 利用率 CPU 利用率在 10 秒内从 100 下降到几乎为 0。同时几乎磁盘延迟也恢复正常

这个问题在不同的 AWS ec2 实例上已经在一周内发生了几次，并且仍然在发生。在所有情况下，我们都会看到 CPU 峰值以及磁盘延迟，其中 CPU 峰值具有与上述类似的模式。

我们使用了进程监控工具来检查是否有任何特定进程占用了 CPU。该工具显示 ec2 实例上的每个进程开始占用大约两倍的 CPU。例如，我们的应用服务器 CPU 利用率从 .75% 增加到 1.5 。 nginx 和其他进程的类似观察。没有一个进程占用超过 8% 的 CPU。我们研究了我们的交通模式，没有什么异常会导致这种情况。所以问题是

磁盘延迟增加会导致 CPU 峰值模式如上所述，或者磁盘延迟通常会导致 CPU 峰值

【问题讨论】：

当然有可能，但对于表现良好的代码听起来不太可能。你能提供更多细节吗？例如什么程序正在运行，你如何测量这些东西？你有什么东西同时出现在日志中吗？例如您的代码之前正在执行的操作，或者某个守护进程正在唤醒？

能否提供您的 EC2 和 EBS 设置？ （实例类型、EBS 类型和大小...）

【参考方案1】：

这是我的赌注：您正在运行 t2 / t3 机器，它们是可突发的实例。您可以始终访问 30% 的 CPU，信用系统为剩余的 70% 创建公平使用可预测模式。您通过运行实例获得积分，超过 30% 的 CPU 使用率则失去积分。

您的积分用完了，然后 AWS 减少了您对 CPU 的访问。当积分添加到您的余额时，系统会再次运行顺畅。

t2和t3没有系统信用体系，详情请看：CPU Credits and baseline

您有两种解决方案：

以更大的实例为例，这样您将获得更多的每小时积分和更好的基线或其他系列，如 c5、m5、r5 等... 为您的 t3 实例选择无限制模式

【讨论】：

实例类型为 m5.2xlarge，EBS 类型为 gp2，大小为 320

【参考方案2】：

我建议更快的存储。 cpu 的目标是加起来达到 100%。限制以这种奇怪的方式工作，它模拟“未知”原因的使用。原因可能是其中之一：

空闲时间（请注意，这是您认为的免费 CPU，这就是为什么我说它加起来是 100%） 用户时间（正常使用） 系统时间（系统使用情况）

iowait（您的情况，cpu 等待 HDD/SSD 响应）

美好的时光（未包含在用户时间中的低优先级进程） 中断时间（外部设备“通话”时间 - 如果您有许多 USB 设备等可能是您的情况 - 不太可能） softirq（来自已处理中断的排队工作 - 见上文） 偷时间（克莱门特正在描述的案例）

我建议你确定哪一个是你的情况

you can try below to get the info:
$ sudo apt-get install sysstat
$ mpstat -P ALL 1

从这里有 2 个选项供您选择 :)

EBS 允许您运行称为“IO1”的 IO 优化卷（中等价格 - 中等速度） 更换机器并在“Nitro System”中使用一台（提供裸机功能 - 即：就像您直接连接了实际的 NVMe - 最大可能速度）

m5.2xlarge  8   37  32 GiB  EBS Only    $0.384 per Hour
m5d.2xlarge 8   37  32 GiB  1 x 300 NVMe SSD    $0.452 per Hour

来源：Instances built on the Nitro System