我们的一个kafka代理在一台8核机器上有一个非常高的平均负载（平均约8个）。虽然这应该没问题，但我们的集群似乎仍然面临问题，而且生产者未能以通常的速度刷新消息。
经过进一步的调查，我发现我的java进程等待io的时间太长了，几乎99.99%的时间都在等待，到目前为止，我认为这是一个问题。
请注意，即使在负载相对较低（大约100-150kbps）的情况下也会发生这种情况，我已经看到它在向集群输入2Mbps数据的情况下也能完美地执行。
我不确定这个问题是不是因为Kafka，我假设这不是因为所有其他经纪人在这段时间工作良好，我们的数据是完全分为5个经纪人。
请帮助我找出问题的根源。我应该在哪里找到问题？有没有其他工具可以帮助我调试这个问题？
我们在m5.2x大型机器上使用1 tb安装的ebs卷。
请随时提问。
gc日志快照
1条答案
按热度按时间ivqmmu1c1#
找出问题后回答我自己的问题。
事实证明，真正的问题是与st1硬盘驱动器的工作方式，而不是Kafka或gc。
st1 hdd卷类型针对涉及大型、顺序i/o的工作负载进行了优化，对于小型随机IO的性能非常差。你可以在这里了解更多。虽然它应该只适用于Kafka，但我们正在将Kafka应用程序日志写入同一个硬盘，这给读/写ios增加了很多，随后在峰值时间很快耗尽了我们的突发信用。我们的集群工作得很好，只要我们有可用的突发信用和性能下降后，信用耗尽。
这个问题有几种解决方案：
首先删除任何外部应用程序添加io负载到st1驱动器，因为它并不意味着这些类型的小随机io。
增加这样的st1并行驱动器的数量来划分负载。这对于kafka来说很容易做到，因为它允许我们将数据保存在不同驱动器的不同目录中。但是只有新的主题才会被划分，因为在创建主题时，分区被分配给目录。
使用gp2ssd驱动器，因为它们可以很好地管理这两种负载。但是这些很贵。
使用适合您的用例的更大的st1驱动器，因为吞吐量和突发信用取决于磁盘的大小。在这里阅读
这篇文章对我解决这个问题帮助很大。
谢谢。