风暴 - 寻找延迟的来源

Question

我有一个三部分拓扑结构，有一些严重的延迟问题，但我无法弄清楚在哪里。

kafka - ＆gt; db lookup - ＆gt;写信给cassandra

风暴UI中的数字如下所示：

（我看到螺栓的运行速度大于1.0）

如果两个螺栓的过程延迟为~65ms，为什么'完整潜伏期'＆gt; 400秒？ “失败的”元组来自超时，我怀疑延迟值正在稳步增加。

元组通过 shuffleGrouping 连接。

Cassandra生活在AWS上，因此可能存在网络限制。

风暴群集有3台机器。拓扑中有3名工作人员。

Answer 1

您的拓扑有几个问题：

1. 查看decode_bytes_1和save_to_cassandra spouts的容量。两者都超过1（所有喷口容量的总和应小于1），这意味着您使用的资源比您可用的资源多。也就是说，拓扑无法处理负载。
2. 如果元组的吞吐量在白天变化，TOPOLOGY_MAX_SPOUT_PENDING将解决您的问题。这是，如果你有偷看的时间，你会在惊喜时间赶上。
3. 您需要增加工作机器的数量或优化瓶颈喷口（或两者）中的代码。否则你将无法处理所有元组。
4. 你可以通过逐个插入插入元组的instread来改进cassandra persister ......
5. 我强烈建议您始终将TOPOLOGY_MAX_SPOUT_PENDING设置为保守值。 最大spout挂起，表示拓扑内的最大未取消元组数，请记住此值乘以点数，如果在发出后30秒未确认，则元组将超时（失败）< / strong>即可。
6. 是的，你的问题是让元组超时，这正是发生的事情。
7. （EDIT）如果您正在运行开发环境（或者只是在部署拓扑之后），您可能会遇到由spout尚未消耗的消息所产生的流量峰值;重要的是要防止这种情况对您的拓扑产生负面影响 - 您永远不知道何时需要重新启动生产拓扑或执行某些维护 - 如果是这种情况，您可以将其作为流量的临时峰值处理 - spout需要消耗拓扑离线时产生的所有消息 - 在一些（或几分钟）之后，传入元组的频率稳定;你可以使用max pout pending参数处理它（再次阅读第2项）。
8. 考虑到群集中有3个节点，并且cpu使用率为0,1您可以在螺栓中添加更多执行程序。

Answer 2

FWIW - TOPOLOGY_MAX_SPOUT_PENDING 的默认值似乎不受限制。我添加了对stormConfig.put(Config.TOPOLOGY_MAX_SPOUT_PENDING, 500);的调用，似乎（到目前为止）问题已经缓解。可能是“雷鸣般的群体”问题？

将TOPOLOGY_MAX_SPOUT_PENDING设置为500后：