jmeter压力测试后的性能瓶颈分析及优化方法

1. 短时间的性能测试（5分钟）

性能测试结果显示正常

2. 中期2小时的性能测试

虽然有波动，总体还算正常。

3. 中期4小时的性能测试

可以明显的看出性能明显下降。

4. 查看内存及垃圾回收（jstat）

# jstat -gcutil -t  43917 3000
Timestamp         S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   27956.4   0.00   0.00  18.80  99.97  95.18  92.91  22526  435.235  1350 4001.013 4436.24827959.5   0.00   0.00  41.05  99.97  95.18  92.91  22526  435.235  1350 4001.013 4436.24827962.5   0.00   0.00  68.23  99.97  95.18  92.91  22526  435.235  1350 4001.013 4436.24827965.4   0.00   0.00  96.35  99.97  95.18  92.91  22526  435.235  1350 4001.013 4436.24827968.5   0.00   0.00  10.70  99.98  95.18  92.91  22526  435.235  1351 4003.350 4438.58427971.5   0.00   0.00  28.34  99.98  95.18  92.91  22526  435.235  1351 4003.350 4438.58427974.5   0.00   0.00  47.01  99.98  95.18  92.91  22526  435.235  1351 4003.350 4438.58427977.5   0.00   0.00  64.59  99.98  95.18  92.91  22526  435.235  1351 4003.350 4438.58427980.5   0.00   0.00  83.39  99.98  95.18  92.91  22526  435.235  1351 4003.350 4438.58427983.5   0.00   0.00 100.00  99.98  95.18  92.91  22526  435.235  1352 4003.350 4438.58427986.5   0.00   0.00  12.69  99.98  95.18  92.91  22526  435.235  1352 4005.704 4440.93827989.5   0.00   0.00  29.48  99.98  95.18  92.91  22526  435.235  1352 4005.704 4440.93827992.5   0.00   0.00  45.24  99.98  95.18  92.91  22526  435.235  1352 4005.704 4440.93827995.5   0.00   0.00  59.97  99.98  95.18  92.91  22526  435.235  1352 4005.704 4440.93827998.5   0.00   0.00  74.45  99.98  95.18  92.91  22526  435.235  1352 4005.704 4440.93828001.5   0.00   0.00  86.40  99.98  95.18  92.91  22526  435.235  1352 4005.704 4440.93828004.5   0.00   0.00 100.00  99.98  95.18  92.91  22526  435.235  1353 4005.704 4440.93828007.5   0.00   0.00 100.00  99.98  95.18  92.91  22526  435.235  1353 4005.704 4440.93828010.5   0.00   0.00  24.63  99.97  95.18  92.91  22526  435.235  1353 4010.111 4445.34628013.5   0.00   0.00  49.55  99.97  95.18  92.91  22526  435.235  1353 4010.111 4445.34628016.5   0.00   0.00  86.74  99.97  95.18  92.91  22526  435.235  1353 4010.111 4445.34628019.5   0.00   0.00 100.00  99.97  95.18  92.91  22526  435.235  1354 4010.111 4445.346

可以看出全局垃圾回收非常频繁。

5. 查看内存直方图（jmap）

性能下降时的查询结果：

# jmap -histo 43917 | more
num     #instances         #bytes  class name
----------------------------------------------1:       4885725      816256552  [C2:       4884972      117239328  java.lang.String3:        532002       63840240  com.xxx.xxxx.dao.model.AcsBusinessLogService4:        554806       48822928  java.lang.reflect.Method5:        532002       25536096  org.springframework.aop.framework.ReflectiveMethodInvocation6:        532002       17024064  java.util.concurrent.FutureTask7:        570471       14718728  [Ljava.lang.Object;8:         15866       12960848  [B9:        532054       12769296  java.util.Date10:        532004       12768096  java.util.concurrent.LinkedBlockingQueue$Node11:        532002       12768048  org.springframework.aop.interceptor.AsyncExecutionInterceptor$$Lambda$1601/68449831812:         71743        2295776  java.util.concurrent.ConcurrentHashMap$Node13:         18664        2086616  java.lang.Class14:         13047        1659328  [I15:           319         889088  [Ljava.util.concurrent.ConcurrentHashMap$Node;

可以看出字符数组类型数据[C，实例数488万个，占用空间816MB，e类型数据53万个，占用空间63MB，这些数据说明有空间没有及时释放。

字符串类型数据，实例数488万个，占用空间117MB。

出现上述情况的可能原因有两个：一个是在性能测试的时候，新生成的实例的速度远大于回收的速度，导致实例数的不断增加。第二个原因就是程序中存在内存泄漏，有部分实例生成后无法释放。

6. 性能测试几小时后查看内存直方图（jmap）

# jmap -histo 43917 | more    num     #instances         #bytes  class name
----------------------------------------------1:         94646       11657136  [C2:         10510       11349640  [B3:         12241        4028096  [I4:         71746        2295872  java.util.concurrent.ConcurrentHashMap$Node5:         94029        2256696  java.lang.String6:         18664        2086616  java.lang.Class7:         22804        2006752  java.lang.reflect.Method8:         38034        1924432  [Ljava.lang.Object;9:           319         889088  [Ljava.util.concurrent.ConcurrentHashMap$Node;10:         19625         785000  java.util.LinkedHashMap$Entry11:         46489         743824  java.lang.Object12:         27776         666624  java.util.ArrayList13:          5944         602456  [Ljava.util.HashMap$Node;14:         17998         575936  java.util.HashMap$Node15:         12831         513240  org.antlr.v4.runtime.atn.BasicState

从这里可以看出，对比之前的数据，字符数组类型数据实例数只有9万，相比之前的488万大幅减少，占用空间11M，相比之前816M也是大幅减少。

字符串数据9万个，相比之前的488万，大幅减少，占用空间2MB，幅度也大幅减少。

e实例对象没有了，说明被回收了。

通过这些数据可以说明，之前的数据增多原因是内存回收速度跟不上的，而不是内存无法释放造成的。

7. 相对简单的应对方法

对分配的内存空间在使用结束后，及时设置为空，方便垃圾回收能够及时回收。

8. 相对复杂更有效的应对方法

根据程序频繁申请和释放内存的特点，采用内存池技术，预先建立一个内存池，需要内存的时候，从内存池中申请，使用完毕释放到内存池，当发现内存池大小不足时，扩充内存池的大小。这种方法就是把内存的申请和释放，在程序中处理了，而不是依赖jvm虚拟机来处理。

这种方法，也提高了程序的复杂性，需要对内存池技术比较熟悉，有比较丰富的经验才行。