Heron Topology资源需求参数调试步骤

简介

为了使一个Topology能够更有效的运行，我们需要对Topology中的一些基础的默认参数进行调整。如下是一些可以调整的基础参数，但不限于这些：

• Container RAM
• Container CPU
• Component RAMs
• Component Parallelisms
• Number of Containers

需要注意的是，对一个拓扑的调试可能需要多次迭代并有一定的困难。所以在对拓扑进行调试之前，最好对拓扑的基本概念和术语有一定的理解，以更好的完成下面步骤的调试操作。

拓扑调试的一般步骤

1. 使用默认的（初始的）参数设置提交和发布topology。这里的参数配置基于输入数据的规模（input data size），组件的逻辑（component logic），或者是一些来自于其他正在工作的topology的经验。
2. 适当的提高拓扑的并行度（parallelism）或container RAM或者CPU，来解决出现backpressure的问题。
3. 确保Spout不会出现延迟（lag）。在topology稳定运行的状态下，拓扑应该可以完全的读取全部的数据。
4. 重复步骤2-3，直到没有backpressure和spout lag问题的出现。
5. 至此，topology的CPU和RAM使用率将会趋于稳定。然后，基于以周为周期的对数据趋势的日常记录，为spikes留有合适的使用空间，并将分配给topology但topology并未使用到的资源进行调整和重新利用。

虽然，上述这些步骤看似简单，但对topology的调试也可能会需要一段时间以达到topology运行的最佳状态。下面的一些提示可能会帮助你完成上面的步骤。

一些提示信息

1. 如果topology中的每个components都指定了componentRAMs，则将会将这些设置的RAM资源分配这些Heron实例（instances）。我们可以根据这些实例的功能来指定参数的设置以节省资源。默认情况下，每个实例都分配了1G的内存，而这些内存资源可能会比它需要的多。需要注意的是，如果container RAM被指定，在为heron中的实例组件留出一些内存资源之后，其他剩余的资源将会平均的分配给该容器中所有的实例。
2. 在Bolts中，一个内存敏感的执行任务将有可能会引起GC问题。topology中由spout生成的一些对象，由于得不到bolts的及时处理而变成老一代的待回收对象，这样就会导致GC回收，大量的GC回收则会引起内存资源不足的问题。
3. 可以在Spout中使用Scheme S来简单的降低数据流量。这样可以帮助我们解决由外部服务提供数据流的问题。或者简单在运行早期阶段，没有太多资源被使用的时候，对使用状态进行评估。但这仍可能会导致spouts中100%的资源占用。