风暴 - 寻找延迟的来源答案

【问题标题】：storm - finding source(s) of latency风暴 - 寻找延迟的来源
【发布时间】：2015-06-29 18:32:06
【问题描述】：

我的三部分拓扑存在一些严重的延迟问题，但我无法确定位置。

kafka -> 数据库查找 -> 写入 cassandra

storm UI 中的数字如下所示：

（我看到螺栓以 > 1.0 的容量运行）

如果两个螺栓的进程延迟约为 65 毫秒，为什么“完全延迟”> 400 秒？ “失败”的元组来自我怀疑的超时，因为延迟值正在稳步增加。

元组通过 shuffleGrouping 连接。

Cassandra 位于 AWS 上，因此在途中可能存在网络限制。

storm 集群有 3 台机器。拓扑中有 3 个工作线程。

【问题讨论】：

标签： java cassandra apache-storm

【解决方案1】：

您的拓扑有几个问题：

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

【讨论】：

1.主管系统上的 CPU 负载
@ethrbunny 我查看了手册，实际上容量代表了在螺栓上花费的时间，而不是 CPU 使用率。关于 cassandra，您仍然有一些延迟，批量插入可能会使您的持久性更快，什么是快速插入 1000 * 1 记录 * 30 毫秒或 10 * 100 记录 * 100 毫秒？您必须考虑包裹需要通过网络传输并被确认的时间。
@ethrbunny 该拓扑的总延迟是一个巨大的值，因为下一个元组仅在插入前一个元组后才插入到 casandra，这将导致总 ack 延迟很大。跨度>

【解决方案2】：

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

将 TOPOLOGY_MAX_SPOUT_PENDING 设置为 500 后：

【讨论】：