在充分了解节点计算机硬件资源的情况下进行Storm运行性能的调优。
Storm运行性能调优主要是从以下几个方面:
(1)代码层面,这得看程序编写者的功力了。
(2)并行度层面,分为:
setNumWorkers取值;
kafkaSpout取值(假设是从Kafka中读取数据);
Bolt取值;
shuffleGrouping和fieldsGrouping的选择等。
1. setNumWorkders
worker 可以分配到不同的 supervisor 节点上,这是 Storm 实现多节点并行计算的主要配置手段。在一定程度上workers 的数量越多越好,但实际生产硬件资源有限。所以主要考虑集群中各节点的内存情况:默认情况下,一个 worker 分配 768M 的内存,外加 64M 给 logwriter 进程;因此一个 worker 会耗费 832M 内存;假设集群有3个节点,每个节点4G内存,除去 Linux 系统、kafka、zookeeper 等的消耗,保守估计仅有2G内存可用来运行 topology,由此可知,当集群只有一个 topology 在运行的情况下,最多可以配置6个 worker。
此外,还可以调节 worker 的内存空间。这取决于流过 topology 的数据量的大小以及各 bolt 单元的业务代码的执行时间。如果数据量特别大,代码执行时间较长,那么可以考虑增加单个 worker 的工作内存。有一点需要注意的是,一个 worker 下的所有 executor 和 task 都是共享这个 worker 的内存的,也就是假如一个 worker 分配了 768M 内存,3个 executor,6个 task,那么这个 3 executor 和 6 task 其实是共用这 768M 内存的,但是好处是可以充分利用多核 CPU 的运算性能。
2. kafkaSpout
如果 spout 读取的是 kafka 的数据,那么正常情况下,设置为 topic 的分区数量即可。计算 kafkaSpout 的最佳取值,有一个最简单的办法,就是在 Storm UI里面,点开 topology 的首页,在 Spouts (All time) 下,查看以下几个参数的值:
- Emitted已发射出去的tuple数
- Transferred已转移到下一个bolt的tuple数
- Complete latency (ms) 每个tuple在tuple tree中完全处理所花费的平均时间
- Acked 成功处