Apache storm 风暴拓扑处理逐渐放缓

我一直在阅读有关ApacheStorm的文章，并尝试了StormStarter中的几个示例。还了解了如何优化拓扑以及如何扩展拓扑以足够快地执行以满足所需的吞吐量

我已经创建了启用确认的示例拓扑，我能够每秒处理3K-5K消息。在最初的10到15分钟或大约1到2分钟的消息中，它的执行速度非常快，然后开始变慢。在storm UI上，我可以看到整体延迟开始逐渐增加，但不会恢复，一段时间后处理速度下降到每秒几百次。对于我尝试过的所有类型，我都得到了完全相同的行为，最简单的一种是使用KafkaSpout读取kafka并将其发送到transform bolt解析消息，然后再次使用KafkaBolt将其发送给kafka。解析器速度非常快，因为解析消息的时间不到一毫秒。我尝试了几个增加/描述并行性、更改缓冲区大小等选项，但行为相同。请帮助我找出拓扑中逐渐变慢的原因。这是我正在使用的配置

1 Nimbus machine (4 CPU) 24GB RAM
2 Supervisor machines (8CPU) and using 1 thread per core with 24GB RAM
4 Node kafka cluster running on above 2 supervisor machines (each topic has 4 partitions)

KafkaSpout(2 parallelism)-->TransformerBolt(8)-->KafkaBolt(2)

topology.executor.receive.buffer.size: 65536
topology.executor.send.buffer.size: 65536
topology.spout.max.batch.size: 65536
topology.transfer.buffer.size: 32
topology.receiver.buffer.size: 8
topology.max.spout.pending: 250

一开始

几分钟后

45分钟后，延迟开始上升

80分钟后-延迟将继续增加，并将持续到100秒，直到它达到8到10英里的消息

可视化虚拟机屏幕截图

线程

---

注意RT_左_螺栓上的

容量

度量，它非常接近1；这就解释了为什么拓扑速度变慢了

从：

Storm UI也变得非常有用。跟踪所有螺栓的新统计数据“#已执行”、“执行延迟”和“容量”。“容量”指标非常有用，它告诉您bolt在过去10分钟内执行元组的时间百分比。如果此值接近1，则螺栓处于“容量”状态，是拓扑中的瓶颈。at容量螺栓的解决方案是增加该螺栓的平行度

---

因此，您的解决方案是向给定的螺栓（RT_LEFT_螺栓）添加更多的执行器（和任务）。您可以做的另一件事是减少RT_RIGHT_BOLT上的执行器数量。容量表明您不需要太多执行器，可能需要1或2个执行器来完成此工作。

问题是由于使用newgen params的GC设置，它没有完全使用分配的堆，因此内部风暴队列已满且内存不足。奇怪的是，storm没有抛出内存不足错误，它只是被暂停了，在visual vm的帮助下，我能够找到它。

解释为什么它被否决，以便我可以改进。.你能发布一些storm UI截图吗？在帖子中添加截图，VisualVM螺纹监视器中的一个观察结果是，大多数变压器螺栓螺纹处于“停止”、“等待”或“监视”状态，很少有螺纹处于运行状态。此外，大多数线程正在运行，但在一段时间内处于等待或驻车状态。无法找出原因？转换螺栓会根据条件过滤消息，因此不要混淆，以查看来自RT_左螺栓的发射次数较少。只有2%的消息将通过此用例的筛选条件。我尝试将并行度增加到60，但我仍然看到相同的行为，即使使用60，我也看到相同的容量数，这是否意味着它有太多的数据…，另一个疑问，为什么Transformer bolt上的执行延迟会增加…如果它在容量为1的情况下运行，那么整个系统的执行延迟应该是相同的？Pramod您是否介意提供导致问题的GC设置以及解决问题的确切值。谢谢