关于storm程序性能压测记录及总结

STORM性能压测步骤记录及总结

压测前的准备

　　 1.明确压测计划和方案。

　　　　(1).首先肯定本次压测的目的是什么。
　　　　(2).例如是验证目标工程是否可以达到预约的性能指标，仍是须要经过调整压测资源的分配，通过屡次压测比对结果，发现性能瓶颈的所在。
　　　　(3).压测指标通常来讲是根据往年同时段或者最近一次大促峰值的数据量按照必定比例增长后评估得出的。

可能会影响性能几个因素：
a.    机器数、
b.    worker数、
c.    执行器数（这里体现为worker数和执行器的配比）、
d.    接收topic的partition数
e.    程序代码内部的逻辑复杂度

压测指标
a.    CUP使用状况；
b.    内存使用状况；
c.    最大瞬间处理峰值TPS；
d.    持续峰值TPS（可以持续三分钟以上的最大值）；
e.    平均TPS；
f.    spout数据下发到每一个partition是否均匀；
g.    网络IO；

  　　2. 准备好压测所须要的数据。

　　　　(1)通常来讲须要根据压测指标的tps来准备相应数量的数据，尽可能保证灌入的数据能够持续处理10分钟以上，时间过短的话不足以保证数据处理的稳定性。

　　　　(2)肯定数据是否能够重复灌入。因为可能须要进行屡次压测，或者压测数据不够的时候，首先要肯定能否重复使用数据，好比须要将第一次接收的数据存入redis或者hbase表中，后面存在去重或者其余重复数据处理逻辑，那么使用重复数据就会对压测结果形成影响。

　　  3.提早报备

进行压测以前先在群中知会一下，以避免有其余人同时在进行别的操做而对压测结果形成影响。

 　　 4. 对压测拓扑对象进行分析。

a.肯定拓扑中有多少spout和bolt，搞清楚它们之间的联系和处理逻辑，肯定有多少种日志须要进行压测，单场景仍是混合场景。

b.对于涉及到数据写入redis、hbase、hive等，若是存在去重或者其余重复数据处理逻辑，须要在压测前将其进行清空处理。

 　　  5.提早打开对应服务器上cpu等监控界面

查看cpu和内存：  /nmon下     ./nmon_x86_64_centos6

 

 若是有专门的监控页面或工具（如zabbix等）则会更加便捷，可以一站式的监控多项指标。

 

 

压测步骤

第一步：向kafka灌入数据

注：发送数据以前必定要保证storm UI上的对应拓扑已经杀死或者是Deactive状态，不然数据发送以后会立刻被消费掉，没法堆积到大量的数据达到压测效果。

 

 直接在服务器上向kafka发送数据

此方法须要先将事先准备好的压测数据上传至服务器上，使用linux命令进行数据发送。

 

 

注：此方法可能出现灌入数据在分区上分布不均匀的状况，酌情使用。

cat /data/testdata/10033593/kafkadata/storm-expose-access/10.246.4* | /home/storm/software/kafka/bin/kafka-console-producer.sh --broker-list "broker地址" --topic storm_expose_access

 

 

第二步：启动拓扑并记录监控数据

当灌入数据达到预期达到以前预估的量的时候（保证灌入的数据能够持续处理10分钟以上），就能够开始进行压测了。

1. 使用拓扑启动命令启动拓扑。
2. 打开storm UI界面，进行数据记录。
3. 若是配置有监控界面，可直接采用读取监控页面的数据来进行指标检测和记录。

因为拓扑内部进程彻底启动须要必定的时间，所以在前几十秒中，是不进行数据处理的。所以最好从1min后再开始进行记录。

 

1. Cpu监控

待cpu稳定后，观察cpu利用率是否在正常范围内，通常是75%如下。

 

1. 查看拓扑进程分布

因为当拓扑分配多个worker的时候，拓扑进程可能随机分布到storm UI上面的几个服务器上，所以须要肯定哪几台。

(1)     到storm UI上面查看集群所在的服务器

(2)     分别到这几台服务器上查看目标拓扑的进程号，查询不到时表示目标拓扑在该服务器上没有分配进程

查询命令：  jps –m （或jps –m | grep 拓扑名）

下图中24922 即为dfp_sa_log在该台服务器上的进程号（一台服务器上能够有多个）

 

 

1. 查看内存FullGC次数

根据年老代分区的内存变化状况判断JVM是否进行FullGC，记录内存在监控时间段内的FullGC次数。
应该尽量减小Full GC的次数。在对JVM调优的过程当中，很大一部分工做就是对于FullGC的调节

根据上面的方法获得的目标拓扑的进程号，能够查看该进程在当前服务器上的FullGC次数。

查询命令：jstat -gcutil  +进程号

 

 

第三步：根据监控数据进行分析调整

1．  Tps

选择两个时间点记录的数据量，取差值除以时间差，可得出tps。尽可能选取时间间隔较长的进行计算，这样得出的结果属于系统稳定以后的数据，通常比较接近真实状况。

（1）当计算得出的tps跟预期指标相差不大时，说明当前系统能够知足性能要求。将压测过程当中的数据记录下来整理成文档便可。

（2）当监控到的tps与预期指标相差甚远的时候，就须要对压测过程当中可能形成tps上不去的缘由进行定位分析了。

 i.查看压测过程当中拓扑中各个spout和bolt对应的capacity值，若是很是接近于1，或者已经超过1，则说明该spout/bolt已经达处处理极限。此时可对其分配几个excutor再压压看

 ii. Spout的执行器数太少。当spout分配的执行器数小于topic分区数的时候，可能会形成接收到的数据不能及时下发给处理单元，形成tps太低，能够增长执行器数（excutor）数等于分区数在进行观察

 iii.Topic分区影响，当tps相对于压测指标太低，同时各个bolt的capacity值都没有达处处理极限时，多是topic分区较少从而入口接收数据的能力达不到形成的。可建议后期增长topic的分区数。

 iv. Redis读取/写入影响，若是逻辑中存在redis读取或者写入操做的时候，可能也会对tps形成影响

 v.逻辑过重致使，如关联mysql维表或者hbase

vi.外部rsf接口影响

 

2．  Cpu

待cpu稳定后，观察cpu利用率，若是在75%如下则表示正常

若是CPU利用率太高，可使用top命令查看当前占用率较高的是哪些进程，具体想要分析出cpu高的问题还须要其余手段。

 

3．  内存FullGC

若是内存FullGC过于频繁，则说明该拓扑处理过程当中内存消耗过大，短期内就须要清空一下内存，须要进行优化；或者也可能跟应用的逻辑和分配的资源有关。

经过jmap dump了jvm的堆内存，用visualvm查看dump出来的文件，进行进一步的分析调优。

 

通常来讲，测试环境与实际生产环境上的资源配置相差较大，所以咱们在测试环境上得出的结果通常与生产仍是有必定差别。这可能就须要咱们经过按照必定的比例调整测试环境上的配置资源数，分别得出分配不一样资源时的结果，而后再根据这些结果进行线性估算得出在生产上可能须要的资源数，压测结果可供调整生产环境时进行参考。