不久前参与开发了一个基于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自身无法负载大数据量线程导致。当然也有可能发生在程序本身过程中，如逻辑中创造大量对象，消耗大量内存，或同步逻辑处理块设计欠缺，导致死锁、线程饿死等。笔者所描述的问题只是众多压测问题中的一小部分，分析、操作难免有疏漏，欢迎各位同学予以指正及建议。感谢华哥、林哥指导，感谢一鸣同学协助~
网友评论