基于Dubbo的压测调优实例-阿里云开发者社区

开发者社区> 开发与运维> 正文

基于Dubbo的压测调优实例

简介:        不久前参与开发了一个基于dubbo分布式框架的底层账单系统,并实现了其中的一部分业务接口,目前需对这些接口进行压测,以评估生产环境所能承受的最大吞吐量。

       不久前参与开发了一个基于dubbo分布式框架的底层账单系统,并实现了其中的一部分业务接口,目前需对这些接口进行压测,以评估生产环境所能承受的最大吞吐量。笔者以其中一个查询接口为例来回顾此次压测的整体流程


压测准备:

1.调用查询接口的测试jar包,作为dubbo-consumer,依赖了查询服务的api,测试module基于maven开发,执行maven clean package即可通过编译得到jar包

2.JMeter:Apache组织开发的基于Java的压力测试工具

方案:

无限次请求查询接口(保证任意时刻并发量相同),观察Error%为0,当请求平稳进行时的tps,为该接口吞吐量

实施:

1.JMeter中添加一个测试计划,线程组容量分别设为10、20、50、80、100、200、400、1000、2000,通过jmeter csv data set config设置三组查询参数

2.准备完毕后,依次在不同容量线程组下启动测试计划,结果如下

吞吐量折线统计图
99%Line折线统计图
Error%折现统计图

       结论:当线程数为200时,tps达到1700+,随着线程数增加,99%Line明显蹿升至6s,猜想部分线程请求不到资源,并且Error线程占比瞬间增多也印证了这一点。ps:如果同一组参数测试,压测效果却在递减,可尝试重启Jmeter。


思考&决策:

       当前测试结构中包含三个节点:本地测试Consumer节点—>查询接口Provider节点—>数据库节点,所以相邻两个节点间均可能产生并发瓶颈,所以需要定位具体问题发生的具体位置。由于压测仅需一个节点,所以笔者使用了jVisualVM+jmx+jstacd组合,远程监听Dubbo服务所在的那台机器。


调优准备:

1.jstatd:(JDK自带)基于RMI的服务程序,用于监控基于HotSpot的JVM中资源的创建及销毁。首次使用需在被监控机器中加入权限授予文件jstatd.all.policy(jdk的bin目录下)

文件内容:

grant codebase"file:${java.home}/../lib/tools.jar"{

permission java.security.AllPermission;

};

完毕后执行./jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=远程服务器ip &

对外默认开启1099端口

2.jVisualVM:(JDK自带)Java性能分析工具

3.jmx:(JDK自带),是一个为应用程序、设备、系统等植入管理功能的框架,如管理基于tomcat的web服务,本文中管理基于SpringBoot的Dubbo服务,需在启动脚本中加入jmx的启动配置

-Dcom.sun.management.jmxremote

-Djava.rmi.server.hostname=远程服务器ip

-Dcom.sun.management.jmxremote.port=18999(自定义)

-Dcom.sun.management.jmxremote.ssl=false

-Dcom.sun.management.jmxremote.authenticate=false


方案&实施:

开启压测,并观察jVisualVM中占用CPU时间非常多的热点方法,并查询远程主机cpu使用率情况

jVisualVM观察面板

       发现在正常线程数请求时,获取DriudDataSource连接池连接的方法CPU时间非常高,经查询发现,系统中连接池的配置:initialSize、minIdle、maxActive都非常低,遂进行了第一次调优:提升数据库连接数,连接池初始化连接数50,最小空闲连接数50,最高活跃连接数400。

       提升后,获取连接方法的CPU时间明显降低,遂测试线程数为400时的请求环境下的支持情况,发现已经开始出现error,即一部分线程请求不到资源,99%Line也达到6s之大!

分析:

       此时系统的数据库连接池配置已经达到400,瓶颈不在此处,那么会不会是远程的数据库节点存在瓶颈,于是远程登录数据库节点,发现mysql的允许连接数非常大,不存在瓶颈。既然请求线程数非常大,数据库连接池连接数非常大,数据库提供的连接数也足够,CPU、JVM均没有异常,那么造成性能瓶颈的可能在与dubbo允许提供的连接线程数不足以匹配压测产生的线程数。

       定位到dubbo配置,发现并没有显式定义dubbo连接数,查阅dubbo开发文档

dubbo默认连接线程数

       问题发现了:dubbo默认连接线程数为100,  而并发量400的请求线程对dubbo造成的压力过大,导致压测不久就出现部分线程请求不到资源超时的问题,遂进行了第二次调优:提升Dubbo线程池连接数,将连接数提升至1000。

        那么是不是到此并发就不存在瓶颈了呢?1000请求线程+dubbo允许线程数1000+数据库大连接数支持,理论上操作是没有问题的,我们来实际跑一下,发现压测时出现了更严重的问题,刚开始请求就出现了OOM及超过一半的error线程,准备去远程机器打印一下执行日志,就连tail及ps命令都没有可用资源供执行,停掉了请求线程,又费了九牛二虎之力停掉了服务进程,开始分析原因:各系统间通信均无瓶颈,问题会出在哪里,是什么原因撑爆了JVM,已知的条件是远程服务至少有1000个线程在服务器内生存,是不是线程量太大撑爆了机器?由于JVM中,栈空间线程私有,查阅JVM参数

JVM线程栈空间

服务器为linux系统,那默认ThreadStackSize=1024K,那么1000个线程JVM就需要创建1000*1024k即1个G的空间!这个节点部署三个服务,光一个服务的请求线程就占据1个G,内存溢出也是情理之中的了,遂进行了第三次调优:减少线程栈空间,ThreadStackSize调至256K,也是够用的,再次模拟1000线程并发,OK,无论是系统间线程调用还是内存中JVM空间都在正常情况下,并未出现线程请求不到资源的情况。


总结:

       本次压测主要目的是确定单节点在生产环境所能承受的tps峰值,并借助测试数据反向分析之前开发及单元测试无法覆盖的隐藏问题,通过三次调优,我们可以发现,该环境下瓶颈主要在系统间请求发生时,以及JVM自身无法负载大数据量线程导致。当然也有可能发生在程序本身过程中,如逻辑中创造大量对象,消耗大量内存,或同步逻辑处理块设计欠缺,导致死锁、线程饿死等。笔者所描述的问题只是众多压测问题中的一小部分,分析、操作难免有疏漏,欢迎各位同学予以指正及建议。感谢华哥、林哥指导,感谢一鸣同学协助~

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章