Storm优化心得

最新推荐文章于 2020-05-08 10:34:27 发布

zzxzz00001

最新推荐文章于 2020-05-08 10:34:27 发布

阅读量2k

点赞数

分类专栏： Storm 文章标签： storm 优化

本文链接：https://blog.csdn.net/zzxzz00001/article/details/51492805

版权

Storm 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

将storm的消息打包后发送将极大的提升storm的吞吐量，减少emit次数单机环境下平均每多一次emit，速率降低6%
设定一个合理的spout的ack等待队列的长度通过topology.max.spout.pending进行配置大小
当pending满时，spout将不会再向bolt发射数据，防止雪崩的发生
设置合理的executor的传输配置 topology.transfer.buffer.size=32
topology.executor.receive.buffer.size=16384
topology.executor.send.buffer.size=16384
http://www.michael-noll.com/blog/2013/06/21/understanding-storm-internal-message-buffers/
这篇文章有较好的说明
配置合理的jvm参数 storm的topology默认只给768M的最大容量，实际生产环境中可能不够应该设置合理的新生代和老年代大小，尽可能的减少全局gc 当storm分配的内存过大时（比如8G),可以使用cms回收器进行回收远程调试storm和jmx监测
由于可能会有多个拓扑运行在storm上所以通过直接指定端口的方式会造成端口占用的问题解决方法有两个
1) 直接修改storm.yaml
加入需要重启nimbus worker.childopts: “-Xmx1024m
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=1%ID%
storm api中的注释:

/*
The jvm opts provided to workers launched by this supervisor. All “%ID%”, “%WORKER-ID%”, “%TOPOLOGY-ID%”
and “%WORKER-PORT%” substrings are replaced with:
%ID% -> port (for backward compatibility),
%WORKER-ID% -> worker-id,
%TOPOLOGY-ID% -> topology-id,
%WORKER-PORT% -> port.
*/
2) 通过在topology的config中配置topology.worker.childopts为需要的jvm参数对于一些System.properties也是通过这个方法设置，这个不需要重启storm，
注意topology中设置worker.childopts并不会生效，中topology的main方法中进行System.setProperty也是无效的，必须通过这种方式进行设置
storm的监测和指标 storm虽然可以开jmx，但是你无法从中抓取到任何信息，你可以通过storm
ui给出的RESTful接口来获取所有bolt的信息 storm
ui本质上是调用了nimbus给出的接口，理论上直接通过nimbus也能获取数据但是不方便
https://github.com/apache/storm/blob/master/docs/STORM-UI-REST-API.md
同时你可以通过编写Metric的方式来监测你想要的特定的应用内的指标
http://blog.csdn.net/desilting/article/details/22798693 此外可以通过
config.registerMetricsConsumer自定义监测记录以何种形式输出
可以通过实现IMetricsConsumer接口的方式自定义输出方式比如jmx
滑动窗口的实现 TickTuple的原理是bolt的config中配置了
conf.put(Config.TOPOLOGY_TICK_TUPLE_FREQ_SECS,
emitFrequencyInSeconds); 后系统每隔一段时间都会从__system component发射一个tuple过来
但是如果对时间点上有严格要求可以模拟TickTuple的方式写一个TickSpout定时发射tick给你想要定时发数据的bolt
目前项目中使用了quartz做了TickSpout达成了整点定时调度的功能
适量增加并发度但不是越多越好配置过多的并发度会增加cpu上下文切换开销一般来说对于调用次数比较多的bolt
并发度不应该超过每台物理机上cpu的核心数需要根据实际情况进行修改
注册kryo对象提升序列化速率理论上可以通过 config.registerSerialization(class);
方法注册一些自定义的对象，storm默认使用kyro序列化方案，预先注册对象将会带来一些性能上的提升不够大多数时候序列化并不是瓶颈
使用hook进行一些纪录和额外操作
通过配置topology.auto.task.hooks可以在各个bolt的传输之间增加钩子，可以通过钩子实现一些诸如日志纪录等全局内容，不过对emit的性能有一定影响