Java波动型数据预测_性能数据波动问题

最近项目在做性能测试的时候发现的一系列的数据波动的问题，下面记录下，以便以后查找。

压力测试跑了8个小时，结果数据从第5个小时开始悲剧，响应时间翻了一倍以上(原图找不到了，形状形同下图)

波动前后的数据都很稳定，查看日志发现在出现问题之后没有任何日志打出来，通过ls -sh查看各个日志文件的大小，发现其中一个日志文件208G，把整个home的空间占满了，在继续打日志的时候打不进去。把该日志删除后，重新跑压力测试，问题消失。

性能测试结果显示接口响应时间和预期的结果有很大的出入

首先排查测试使用的环境参数，没有问题。怀疑GC等影响，查看数据发现整个接口响应时间慢并不是因为数据波动导致的，而是一直都很慢，排除掉这个问题。通过visualvm直接连接到性能测试的jvm，查看接口情况。发现接口调用中的一步占用时间超过90%以上，定位到问题在这里。

通过对该方法的详细排查，发现内部有一个数据库调用，不过通常对于一个几万条的数据表进行索引查询也就几毫秒，不至于慢到这个程度。再详细查了一下，发现性能测试库没有建对应的索引，不过在测试环境和线上环境都是建好的。

所以，引起这个的原因是索引木有建，建上索引以后数据满足预期

合并主干后，重新进行性能测试，发现数据有周期性波动

每5分钟有一次大范围波动，排除了Full GC、线程池大小调整、cache过期、apache配置等问题，最后问题聚焦在新加的一个jvm监控上面，详细查找后发现果然有一个5分钟事件。

这里面会采集thread的数据，调用ThreadMXBean.dumpAllThreads(booleanlokcedMonitors, boolean lockedSysnchronizers)方法，传递的参数是ThreadMXBean.dumpAllThreads(true,true)，需要遍历所有线程的Monitor和Synchronizer信息，导致所有的线程阻塞(正常情况下不会有这么明显的影响，性能测试的时候并发设的是30，每秒的请求数有几百个，所以影响会大一点)。把参数修改为ThreadMXBean.dumpAllThreads(false,false)即可解决。