Storm环境配置及吞吐量测试调优总结

Storm环境配置及吞吐量测试调优总结

2017年10月19日 17:03:53

阅读数：10867

问题导读

1.本文集群环境是什么？

2.配置中worker和slot是什么关系？

3.吞吐量是如何测试的？

 

1、硬件配置信息

 

6台服务器，2个CPU，96G，6核，24线程

 

2、集群信息

 

Storm集群：1个nimbus，6个supervisor

nimbus：192.168.7.127

supervisor：

192.168.7.128

192.168.7.129

192.168.7.130

192.168.7.131

192.168.7.132

192.168.7.133

 

Zookeeper集群：

3个节点

192.168.7.127:2181, 192.168.7.128:2181, 192.168.7.129:2181

Kafka集群：

7个节点

192.168.7.127:9092

192.168.7.128:9092

192.168.7.129:9092

192.168.7.130:9092

192.168.7.131:9092

192.168.7.132:9092

192.168.7.133:9092

 

3、配置关系解析

 

按照服务器的硬件配置可以计算得到以下信息：

1、worker和slot的关系是一一对应的，一个worker占用一个slot。计算集群worker和slot数量一般以每个服务器的CPU线程数来计算。

如上面的环境就是

worker、slot：144 （6个supervisor，每个supervisor 都是24线程的CPU，24*6=144）

2、spout并发数，也就是setSpout后面的参数10------builder.setSpout("words",newKafkaSpout(kafkaConfig),10);

这里我在测试的时候，是使用kafka和storm做数据传输，kafka有一个partition的机制，Spout线程数量根据kafka topic的partition数量

来定义，一般是1:1的关系，就是当前topic的partition数量为18，则spout的线程数量可以设置为18。也可以稍微比这个数多，但是不能

多太多；具体需要多少个kafka partition大伙可根据需求来做测试找到自己需要的数值

3、bolt的并发数------builder.setBolt("words",newKafkaBolt(),10);

bolt的并发数量，决定了处理掉效率，bolt并发度为1，面对大的数据量可能会很慢，bolt并发度过高，也不好，可能会照成资源浪费。

具体数值需测试决定

 

 

3、吞吐量测试（以下只列举了部分场景。所有测试的数据请看附件）

 

测试场景1:

partition ：20

worker ：10

Spout ：20

Bolt ：1

计算结果：

 

测试场景2:

partition ：20

worker ：20

Spout ：20

Bolt ：1

测试结果：

 

 

场景3：（数据生成程序在128-132上执行，每个程序100个现成，资源也有一定的占用，所以实际结果可能要比测试结果好点）

Topic 5

Partition 20

Spout 20

Worker 20

Bolt 1

测试结果：

 

 

总结结果：

5个Topic，20个partition，20*5个worker，20*5个spout，1*5个bolt

总的吞吐量=5.04+4.02+5.76+6.31+4.99=26.12

 

每秒吞吐量为26.12万

每日吞吐将近226亿

总结：

影响storm吞吐量的因素有以下几个：spout并发数，worker数量（与slot挂钩），kafka的partition数量

其实这里spout的并发数和kafka的partition的数量是挂钩的。

这里要注意的是，提高worker的数量，虽然可以提高吞吐量，但是要知道，worker的数量和集群的机器数量是挂钩的，是有限制的。

所以需要通过测试设置你自己觉得合理的一个数值；因为如果一个任务设置的worker数量过多，也就说明了留给其他任务的worker

数量就越少，运行的任务也就越少。所以只要符合业务需求的那个值才是最好的；

具体的测试结果看附件；

转载请注明源地址：

http://blog.csdn.net/weijonathan/article/details/38536671问题导读

1.本文集群环境是什么？

2.配置中worker和slot是什么关系？

3.吞吐量是如何测试的？

 

 

1、硬件配置信息

 

6台服务器，2个CPU，96G，6核，24线程

 

2、集群信息

 

Storm集群：1个nimbus，6个supervisor

nimbus：192.168.7.127

supervisor：

192.168.7.128

192.168.7.129

192.168.7.130

192.168.7.131

192.168.7.132

192.168.7.133

 

Zookeeper集群：

3个节点

192.168.7.127:2181, 192.168.7.128:2181, 192.168.7.129:2181

Kafka集群：

7个节点

192.168.7.127:9092

192.168.7.128:9092

192.168.7.129:9092

192.168.7.130:9092

192.168.7.131:9092

192.168.7.132:9092

192.168.7.133:9092

 

3、配置关系解析

 

按照服务器的硬件配置可以计算得到以下信息：

1、worker和slot的关系是一一对应的，一个worker占用一个slot。计算集群worker和slot数量一般以每个服务器的CPU线程数来计算。

如上面的环境就是

worker、slot：144 （6个supervisor，每个supervisor 都是24线程的CPU，24*6=144）

2、spout并发数，也就是setSpout后面的参数10------builder.setSpout("words",newKafkaSpout(kafkaConfig),10);

这里我在测试的时候，是使用kafka和storm做数据传输，kafka有一个partition的机制，Spout线程数量根据kafka topic的partition数量

来定义，一般是1:1的关系，就是当前topic的partition数量为18，则spout的线程数量可以设置为18。也可以稍微比这个数多，但是不能

多太多；具体需要多少个kafka partition大伙可根据需求来做测试找到自己需要的数值

3、bolt的并发数------builder.setBolt("words",newKafkaBolt(),10);

bolt的并发数量，决定了处理掉效率，bolt并发度为1，面对大的数据量可能会很慢，bolt并发度过高，也不好，可能会照成资源浪费。

具体数值需测试决定

 

 

3、吞吐量测试（以下只列举了部分场景。所有测试的数据请看附件）

 

测试场景1:

partition ：20

worker ：10

Spout ：20

Bolt ：1

计算结果：

 

测试场景2:

partition ：20

worker ：20

Spout ：20

Bolt ：1

测试结果：

 

 

场景3：（数据生成程序在128-132上执行，每个程序100个现成，资源也有一定的占用，所以实际结果可能要比测试结果好点）

Topic 5

Partition 20

Spout 20

Worker 20

Bolt 1

测试结果：

 

 

总结结果：

5个Topic，20个partition，20*5个worker，20*5个spout，1*5个bolt

总的吞吐量=5.04+4.02+5.76+6.31+4.99=26.12

 

每秒吞吐量为26.12万

每日吞吐将近226亿

总结：

影响storm吞吐量的因素有以下几个：spout并发数，worker数量（与slot挂钩），kafka的partition数量

其实这里spout的并发数和kafka的partition的数量是挂钩的。

这里要注意的是，提高worker的数量，虽然可以提高吞吐量，但是要知道，worker的数量和集群的机器数量是挂钩的，是有限制的。

所以需要通过测试设置你自己觉得合理的一个数值；因为如果一个任务设置的worker数量过多，也就说明了留给其他任务的worker

数量就越少，运行的任务也就越少。所以只要符合业务需求的那个值才是最好的；

具体的测试结果看附件；

转载请注明源地址：

http://blog.csdn.net/weijonathan/article/details/38536671