1.运行环境
k8s
Web服务器: Liberty(IBM J9 JDK),base image : FROM websphere-liberty:20.0.0.3-kernel-java8-ibmjava
DB: DB2
WebApp 简介: 一个简单的Restful服务,从DB2 Select若干条数据
测试环境: 为防VPN等家里网络影响测试效果,在另外一个POD上装Jmeter,这样用POD调用POD,测试结果比较准确
2.调优前
2.1 环境设置
JVM setup: -Xms -Xmx : 2G Xmn:1G
Liberty connector: <connectionManager minPoolSize=“50” maxPoolSize=“50" purgePolicy=“FailingConnectionOnly”/>
DB 最大连接数: 50
2.2 50个并发压测结果
3. 分析50个线程压测30分钟结果
3.1 结果
- Global GC 发生了11次,后面平均2分钟左右一次
- Local GC发生了558次,基本3-4秒一次
- Contrast 最多占了28%左右的工作线程,占了700M的内存
- 很多线程在执行new relic
- 很多线程park, 因为mybatis 在输出log (在这次压测之前,通过new relic分析调用栈发现占用时间最多的是打印log,原来通过AOP记录日志的代码已经关闭)
第一次dump的内存使用率
Nursery Area Free : 767,422,912 bytes Total : 1,048,576,000 bytes 73 % free
Tenured Area Free : 951,384,856 bytes Total : 1,098,907,648 bytes 86% free
最后一次dump的内存使用率
Nursery Area Free : 791,680,088 bytes Total : 1,048,576,000 bytes 75 % free
Tenured Area Free : 671,331,936 bytes Total : 1,098,907,648 bytes 61% free
3.2 措施
- 调整Xms Xmx 为 4G, Xmn为2G
- 关闭Contrast 和 new relic
- 调整日志level为error,即很少有日志输出。
4.3 效果
1. Local GC每1-2s一次,反而更多,因为Throughput 加大,每秒处理的请求从39变成了630,所以GC更频繁,但是每次回收效果不错, 所以尚可接受
Global GC只在压测的刚开始发生了一次(前面也压测过)
2. Global GC 就没有发生,即压测的半个小时没有Global GC
3. Park 的进程数由23%左右变成11%左右
4. 平均响应时间由1260ms 变成 79.2ms, 原来的运行时间是现在的16倍,Trasactions/s由39s变成630