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个并发压测结果

Web调优之IBM JDK+liberty(一):  Jmeter pod里压力,50个线程并发测试,调整 -Xms -Xms, Log原来是大问题-LMLPHP

Web调优之IBM JDK+liberty(一):  Jmeter pod里压力,50个线程并发测试,调整 -Xms -Xms, Log原来是大问题-LMLPHP

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记录日志的代码已经关闭)Web调优之IBM JDK+liberty(一):  Jmeter pod里压力,50个线程并发测试,调整 -Xms -Xms, Log原来是大问题-LMLPHP

    Web调优之IBM JDK+liberty(一):  Jmeter pod里压力,50个线程并发测试,调整 -Xms -Xms, Log原来是大问题-LMLPHP

    Web调优之IBM JDK+liberty(一):  Jmeter pod里压力,50个线程并发测试,调整 -Xms -Xms, Log原来是大问题-LMLPHP

第一次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 措施

  1. 调整Xms Xmx 为 4G, Xmn为2G
  2. 关闭Contrast 和 new relic
  3. 调整日志level为error,即很少有日志输出。

4.3 效果

1. Local GC每1-2s一次,反而更多,因为Throughput 加大,每秒处理的请求从39变成了630,所以GC更频繁,但是每次回收效果不错, 所以尚可接受
Global GC只在压测的刚开始发生了一次(前面也压测过)

2. Global GC 就没有发生,即压测的半个小时没有Global GC

3. Park 的进程数由23%左右变成11%左右

Web调优之IBM JDK+liberty(一):  Jmeter pod里压力,50个线程并发测试,调整 -Xms -Xms, Log原来是大问题-LMLPHP

4. 平均响应时间由1260ms 变成 79.2ms, 原来的运行时间是现在的16倍,Trasactions/s由39s变成630

Web调优之IBM JDK+liberty(一):  Jmeter pod里压力,50个线程并发测试,调整 -Xms -Xms, Log原来是大问题-LMLPHP



 

05-11 19:55
查看更多