amazon-web-services - 为什么Disk Read And write看起来很小，IO却99.99%

Question

我们的一个 Kafka 代理在 8 核机器上的平均负载非常高(平均约为 8)。虽然这应该没问题，但我们的集群似乎仍然面临问题，生产者未能以通常的速度刷新消息。

经过进一步调查，我发现我的 java 进程在几乎 99.99% 的时间里都在等待 IO，而且截至目前，我认为这是一个问题。

请注意，即使在负载相对较低(大约 100-150 Kbps)时也会发生这种情况，我已经看到即使在集群中输入 2 Mbps 的数据时它也能完美运行。

我不确定这个问题是不是因为 Kafka，我假设这不是因为所有其他经纪人在这段时间都工作正常，我们的数据在 5 个经纪人之间完美分配。

请协助我找出问题的根本原因。我应该在哪里寻找问题？是否有任何其他工具可以帮助我调试此问题？

我们在 m5.2x 大型机器上使用 1 TB 安装的 EBS 卷。

如有任何问题，请随时提出。

GC 日志快照

Answer 1

弄清楚问题后回答我自己的问题。

事实证明，真正的问题与 st1 HDD 驱动器的工作方式有关，而不是 kafka 或 GC。

st1 HDD 卷类型针对涉及大量顺序 I/O 的工作负载进行了优化，并且在处理小型随机 IO 时表现非常糟糕。您可以阅读更多相关信息 here .虽然它应该只对 Kafka 工作得很好，但我们将 Kafka 应用程序日志写入同一个 HDD，这增加了很多读/写 IO，随后在高峰时间非常快地耗尽了我们的突发信用。只要我们有可用的突发积分，我们的集群就可以正常工作，并且在积分耗尽后性能会下降。

这个问题有几种解决方案:

1. 首先删除所有将 IO 负载添加到 st1 驱动器的外部应用程序，因为它不适用于那些类型的小型随机 IO。
2. 增加此类 st1 并行驱动器的数量来分担负载。使用 Kafka 很容易做到这一点，因为它允许我们将数据保存在不同驱动器的不同目录中。但只有新主题才会被划分，因为分区是在创建主题时分配给目录的。
3. 使用 gp2 SSD 驱动器，因为它们可以很好地管理这两种负载。但是这些很贵。
4. 使用适合您的用例的更大的 st1 驱动器，因为吞吐量和突发积分取决于磁盘的大小。 READ HERE

This这篇文章对我解决问题帮助很大。

谢谢。