为什么Disk Read And write看起来很小，IO却99.99%
Why is IO 99.99 % even though the Disk Read And write seems to be very small
我们的一个 Kafka 代理在 8 核机器上的平均负载非常高（平均约为 8）。虽然这应该没问题，但我们的集群似乎仍然面临问题，生产者未能以通常的速度刷新消息。
经过进一步调查，我发现我的 java 进程等待 IO 的时间太多，几乎 99.99% 的时间，截至目前，我认为这是一个问题。
请注意，即使在负载相对较低（大约 100-150 Kbps）时也会发生这种情况，我已经看到即使在集群中输入 2 Mbps 的数据时它也能完美运行。
我不确定这个问题是不是因为 Kafka，我假设这不是因为所有其他经纪人在这段时间都工作正常，我们的数据在 5 个经纪人之间完美分配。
请协助我找出问题的根本原因。我应该在哪里寻找问题？有没有其他工具可以帮助我调试这个问题？
我们在 m5.2x 大型机器上使用 1 TB 安装的 EBS 卷。
有任何问题请随时提问。
GC 日志快照
弄清楚问题后回答我自己的问题。
事实证明，真正的问题与 st1 HDD 驱动器的工作方式有关，而不是 kafka 或 GC。
st1 HDD 卷类型针对涉及大型顺序 I/O 的工作负载进行了优化，并且在小型随机 IOs 中表现非常糟糕。您可以阅读更多相关信息 here。
虽然它应该只对 Kafka 工作得很好，但是我们将 Kafka 应用程序日志写入同一个 HDD，这增加了很多 READ/WRITE IOs 并且随后在高峰时间非常快地耗尽了我们的突发信用.只要我们有可用的突发积分，我们的集群就可以正常工作，并且在积分耗尽后性能会下降。
这个问题有几种解决方案：
- 首先删除所有向 st1 驱动器添加 IO 负载的外部应用程序，因为它不适用于那些小型随机 IOs。
- 增加此类 st1 并行驱动器的数量划分 load.This 使用 Kafka 很容易做到，因为它允许我们将数据保存在不同驱动器的不同目录中。但是只有新的主题才会被划分，因为分区是在创建主题时分配给目录的。
- 使用 gp2 SSD 驱动器，因为它们可以很好地管理这两种负载。但是这些很贵。
- 使用适合您的用例的更大的 st1 驱动器，因为吞吐量和突发信用取决于磁盘的大小。 READ HERE
This文章对我解决问题帮助很大。
谢谢。
我们的一个 Kafka 代理在 8 核机器上的平均负载非常高（平均约为 8）。虽然这应该没问题，但我们的集群似乎仍然面临问题，生产者未能以通常的速度刷新消息。
经过进一步调查，我发现我的 java 进程等待 IO 的时间太多，几乎 99.99% 的时间，截至目前，我认为这是一个问题。
请注意，即使在负载相对较低（大约 100-150 Kbps）时也会发生这种情况，我已经看到即使在集群中输入 2 Mbps 的数据时它也能完美运行。
我不确定这个问题是不是因为 Kafka，我假设这不是因为所有其他经纪人在这段时间都工作正常，我们的数据在 5 个经纪人之间完美分配。
请协助我找出问题的根本原因。我应该在哪里寻找问题？有没有其他工具可以帮助我调试这个问题？
我们在 m5.2x 大型机器上使用 1 TB 安装的 EBS 卷。
有任何问题请随时提问。
GC 日志快照
弄清楚问题后回答我自己的问题。
事实证明，真正的问题与 st1 HDD 驱动器的工作方式有关，而不是 kafka 或 GC。
st1 HDD 卷类型针对涉及大型顺序 I/O 的工作负载进行了优化，并且在小型随机 IOs 中表现非常糟糕。您可以阅读更多相关信息 here。 虽然它应该只对 Kafka 工作得很好，但是我们将 Kafka 应用程序日志写入同一个 HDD，这增加了很多 READ/WRITE IOs 并且随后在高峰时间非常快地耗尽了我们的突发信用.只要我们有可用的突发积分，我们的集群就可以正常工作，并且在积分耗尽后性能会下降。
这个问题有几种解决方案：
- 首先删除所有向 st1 驱动器添加 IO 负载的外部应用程序，因为它不适用于那些小型随机 IOs。
- 增加此类 st1 并行驱动器的数量划分 load.This 使用 Kafka 很容易做到，因为它允许我们将数据保存在不同驱动器的不同目录中。但是只有新的主题才会被划分，因为分区是在创建主题时分配给目录的。
- 使用 gp2 SSD 驱动器，因为它们可以很好地管理这两种负载。但是这些很贵。
- 使用适合您的用例的更大的 st1 驱动器，因为吞吐量和突发信用取决于磁盘的大小。 READ HERE
This文章对我解决问题帮助很大。
谢谢。