2

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

经过进一步调查，我发现我的 java 进程等待 IO 的时间太长了，几乎 99.99% 的时间，到目前为止，我相信这是一个问题。

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

我不确定这个问题是否是因为 Kafka，我假设这不是因为所有其他代理在此期间都运行良好，并且我们的数据在 5 个代理之间完美分配。

请帮助我找到问题的根本原因。我应该去哪里寻找问题？有没有其他工具可以帮助我调试这个问题？

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

请随时提出任何问题。

itop 快照

在此处输入图像描述

GC 日志快照 在此处输入图像描述

4

1 回答 1

4

找出问题后回答我自己的问题。

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

st1 HDD 卷类型针对涉及大型顺序 I/O 的工作负载进行了优化，并且在使用小型随机 IO 时性能非常差。你可以在这里阅读更多关于它的信息。虽然它应该只适用于 Kafka，但我们将 Kafka 应用程序日志写入同一个 HDD，这增加了很多 READ/WRITE IO，随后在高峰时间很快耗尽了我们的突发信用。只要我们有可用的突发积分并且在积分耗尽后性能降低，我们的集群就可以正常工作。

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

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

这篇文章帮助我解决了很多问题。

谢谢。

于 2019-01-13T05:50:23.643 回答