【JAVA】跨机房压测性能问题分析

参考博客：Java线程的6种状态及切换  JVM性能调优监控工具详解 深度理解Tomcat的参数

问题描述：压测部署在A和B两个机房的同样Java服务接口性能表现差别很大，接口内容为mget查询codis集群，codis集群搭建在A机房。压测表现为B机房的服务延时是A机房的十倍，QPS只有A机房的五分之一，而且B机房的服务cpu只能到200%，A机房cpu利用率最高900%。以上结果延时表现正常，但延时和QPS没有直接关系，QPS理论B机房也能达到相当水平，且无论如何调整wrk参数，B机房cpu利用率不超200%无法解释。

问题分析：

一、网络情况

• 首先查看内网为万兆网，网络带宽都没有达到上线
• A机房内通信ping命令延时在0.1ms左右，B机房pingA机房的延时在1ms左右

二、JVM分析

使用jstat命令查看GC情况，两个服务没有明显区别

jstat -gc 19228 500ms 5

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
139776.0 139776.0 761.7   0.0   1118528.0 275877.3 2796224.0   34461.3   55240.0 50333.7 7240.0 6517.5     36    0.581   2      0.225    0.805
139776.0 139776.0 761.7   0.0   1118528.0 275877.3 2796224.0   34461.3   55240.0 50333.7 7240.0 6517.5     36    0.581   2      0.225    0.805
139776.0 139776.0 761.7   0.0   1118528.0 275877.3 2796224.0   34461.3   55240.0 50333.7 7240.0 6517.5     36    0.581   2      0.225    0.805
139776.0 139776.0 761.7   0.0   1118528.0 275877.3 2796224.0   34461.3   55240.0 50333.7 7240.0 6517.5     36    0.581   2      0.225    0.805
139776.0 139776.0 761.7   0.0   1118528.0 275877.3 2796224.0   34461.3   55240.0 50333.7 7240.0 6517.5     36    0.581   2      0.225    0.805

三、进程分析

使用jstack命令分析进程，也并无进程阻塞等问题，且本身同样的代码理论也并无问题

jstack 19228 > show.txt

cat show.txt |grep java.lang.Thread.State | awk '{print $2}' | sort -n | uniq -c
      1 BLOCKED
     47 RUNNABLE
     10 TIMED_WAITING
     84 WAITING

四、LInux内核参数

此时怀疑是是否限制了cpu使用或者进程绑定了指定cpu，经运维协助排查并无此原因。

五、Tomcat参数

此时，想到对于这种不太消耗cpu，纯IO操作的接口想到了提高tomcat连接数，看能否提高cpu利用率及QPS。于是修改了max-threads和accept-count又默认200，100提升到1000；但实际上max-connections本身默认就有10000；所以连接数不会有太多变化，只会和wrk的-c参数有关，可以用命令netstat nltp|grep 8888 验证连接数，但是处理线程提升还是应该在后文有用的。

六、Redis连接池参数

终于，想到了jedis连接池没有配置最大连接数，按默认配置只有8。于是改成100，同时提高最大最小空闲连接数到50，20测试。果然cpu利用率直接提升到1000%，在延时仍然很是同机房十倍的情况下，QPS也提升到了相应水平。

七、结论

由于机房之间延时问题（ping延时本身相差10倍），A和B机房的服务压测延时相差也有10倍，原因主要是A机房服务访问codis集群同机房，B机房服务访问codis集群非同机房，mget命令会有多次服务和集群的通讯，延时相差属于合理范围。

B机房CPU利用率不高，原因在与codis集群一开始只有8个连接，延时又比较高，大部分线程必须等待，但是一旦提升到100个连接，即便单次访问存在差别，但是提高了java服务到codis集群之前通信的并发数，所以QPS上来了，CPU利用率也提高了。

 

本期是个很简单的问题，同样查了三个小时，顺便熟悉下好久不用的JVM调优工具，所以走了《走进科学》的风格，先尽量扩大问题吸引读者，最后简单解决，又在情理之中，实在是秒。