TPS低,CPU高--记一次storm压测问题排查过程

一、业务背景+系统架构

本次场景为kafka+storm+redis+hbase,通过kafka的数据,进入storm的spout组件接收,转由storm的Bolt节点进行业务逻辑处理,最后再推送进kafka。

表数据相关的逻辑为:查询Hbase表数据,首次查询会写入redis和storm cache,再次查询,会直接从redis或cache中取值。

storm应用:

TPS低,CPU高--记一次storm压测问题排查过程

二、性能测试场景

1.数据:json类型的用户偏好数据700万

2.灌入方式:java脚本

3.hbase表:生产全量数据导入

4.storm集群:5台 (Nimbus+sup01+sup02+sup03+sup04)

三、性能过程截图

三分钟时处理数据量:

TPS低,CPU高--记一次storm压测问题排查过程

storm响应时间(不包含kafka延时)

TPS低,CPU高--记一次storm压测问题排查过程

十三分钟处理数据量:

TPS低,CPU高--记一次storm压测问题排查过程

从stormUI接口估算出的TPS大约为970左右,远没有达到我们业务要求。

四、性能瓶颈分析:

1、直接查看storm应用服务器的情况:

TPS低,CPU高--记一次storm压测问题排查过程

发现 cpu从20%直接到80%

TPS低,CPU高--记一次storm压测问题排查过程

CPU资源显然在user态消耗的更多,判断为用户类进程占用的cpu时间片更多。

2、我们按消耗cpu资源的大小对进程进行排序,抓出最大的进程号16889,然后打印进程下面的线程:

命令:ps -mp pid -o THREAD,tid,time

TPS低,CPU高--记一次storm压测问题排查过程

3.挑出占用cpu时间最高的线程,打印线程栈信息,注意线程id(tid)必须转化成16进制

命令:printf "%x\n" tid

jstack pid |grep tid -A 30

TPS低,CPU高--记一次storm压测问题排查过程TPS低,CPU高--记一次storm压测问题排查过程

此处不逐一举例线程信息,Niubus主机和其他从机都需选取一些线程进行打印,发现耗时长的线程大部分都处于Blocked状态,线程状态为执行getcontentmodelscore方法。

检查getcontentmodelscore这部分代码:

TPS低,CPU高--记一次storm压测问题排查过程

发现这部分代码逻辑为从Hbase中获取得分数据和推荐商品数据,判断为hbase性能不佳引起的性能低下,由于PRE环境HBASE条件有限,没有监听端口,也无权限进行配置优化,此问题暂时没有进一步解决方案。

五、第二种排查方案:

由于stormUI提供了可视化的界面,我们可以点开处理时间长的bolt下找到对应的端口号:

TPS低,CPU高--记一次storm压测问题排查过程

在host一栏查到对应的机器地址,通过Jps -m |grep 命令找到对应的进程号,此方法适用于多个业务系统公用一个集群,需要快速定位Pid的时候。

六、附redis监控:

TPS低,CPU高--记一次storm压测问题排查过程

在redis工具中敲入info,查看连接数和使用内存。

由于redis是在内存中运行,不需要考虑命中率;redis单线程运行,如果redis查得慢的话基本可能是一次获取的数据太多了或者程序逻辑不对,不需要考虑慢查询。对于redis,只要不一次获取太多的Key-value,基本不会出现性能问题。

七、strorm worker executor配置问题:

storm中worker代表了进程,比如配置10个worker,5台机器,每个机器会均衡分配2个worker,executor代表线程数,对于每个Bolt,spout节点都可增大减小线程数,达到最佳的处理数据效率。

在本次压测时,10个worker配置了100个线程数,发现性能远不如10个worker配置60个线程,对于kafka,我们知道,一个kafka分区只需对应一个线程,多配置的线程也会处于闲置状态,但并没出现由于多配置线程儿造成的性能降低。而对于storm,对于多配置的线程,反而出现了性能的严重降低。此问题暂时未知道具体原因。

上一篇:Problem B: 大整数的加法运算 升级版


下一篇:Windows中与系统关联自己开发的程序(默认打开方式、图标、右击菜单等)