Java线上程序频繁JVM FGC问题排障与启示

线上Java程序的JVM频繁FGC,现象如图所示:一直持续FGC5次左右,每次耗时1秒多不等。FGJava
强烈推介IDEA2020.2破解激活,IntelliJ IDEA 注册码,2020.2 IDEA 激活码

线上Java程序的JVM频繁FGC,现象如图所示:

Java线上程序频繁JVM FGC问题排障与启示

一直持续FGC 5次左右,每次耗时1秒多不等。

FGC的原因实际上是内存不够用,但是运维反映堆内存是2G,从运维提供的参数看也是。

内存实际上一直只用到1G以内。

 

这时候可以自己写一段代码输出堆内存数据,这是最准的:

public class JVMTest {
    public static void main(String[] args) throws Exception {
    MemoryMXBean mxb = ManagementFactory.getMemoryMXBean();
        //Heap
        System.out.println("Max:" + mxb.getHeapMemoryUsage().getMax() / 1024 / 1024 + "MB");    //Max:1776MB
        System.out.println("Init:" + mxb.getHeapMemoryUsage().getInit() / 1024 / 1024 + "MB");  //Init:126MB
        System.out.println("Committed:" + mxb.getHeapMemoryUsage().getCommitted() / 1024 / 1024 + "MB");   //Committed:121MB
        System.out.println("Used:" + mxb.getHeapMemoryUsage().getUsed() / 1024 / 1024 + "MB");  //Used:7MB
        System.out.println(mxb.getHeapMemoryUsage().toString());    //init = 132120576(129024K) used = 8076528(7887K) committed = 126877696(123904K) max = 1862270976(1818624K)

        //Non heap
        System.out.println("Max:" + mxb.getNonHeapMemoryUsage().getMax() / 1024 / 1024 + "MB");    //Max:0MB
        System.out.println("Init:" + mxb.getNonHeapMemoryUsage().getInit() / 1024 / 1024 + "MB");  //Init:2MB
        System.out.println("Committed:" + mxb.getNonHeapMemoryUsage().getCommitted() / 1024 / 1024 + "MB");   //Committed:8MB
        System.out.println("Used:" + mxb.getNonHeapMemoryUsage().getUsed() / 1024 / 1024 + "MB");  //Used:7MB
        System.out.println(mxb.getNonHeapMemoryUsage().toString());    //init = 2555904(2496K) used = 7802056(7619K) committed = 9109504(8896K) max = -1(-1K)
    }
}

参考:https://www.cnblogs.com/songxingzhu/p/9106394.html 

Java线上程序频繁JVM FGC问题排障与启示

 

这是本地的测试数据,很明显自己设定的内存都生效了,然后拿到线上一跑果然实际堆最大内存是900多M,所以内存触发了阈值就FGC。所以FGC的根源还是内存不够,运维设置不对,运维设置了2G,但是实际上由于使用上的问题不生效

所以要用数据说话,不要去猜测,也不要过度相信配置,因为已经FGC了,而且内存上不了1G。

java
    -Xms64m #JVM启动时的初始堆大小
    -Xmx128m #最大堆大小
    -Xmn64m #年轻代的大小,其余的空间是老年代
    -XX:MaxMetaspaceSize=128m #
    -XX:CompressedClassSpaceSize=64m #使用 -XX:CompressedClassSpaceSize 设置为压缩类空间保留的最大内存。
    -Xss256k #线程
    -XX:InitialCodeCacheSize=4m #
    -XX:ReservedCodeCacheSize=8m # 这是由 JIT(即时)编译器编译为本地代码的本机代码(如JNI)或 Java 方法的空间
    -XX:MaxDirectMemorySize=16m
    -XX:NativeMemoryTracking=summary #开启内存追踪
    -jar app.jar

#java -Xms2048m -Xmx2048m  -Xmn64m   -cp Test-1.0.0.jar com.test.JVMTest  start

这个只是本地模拟,线上参数需要比这个复杂。

 

再回到前面的问题为什么回运维设置不生效呢?

因为这个原因:

Java 8u131及以上版本开始支持了Docker的cpu和memory限制。

cpu limit

即如果没有显式指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount, 那么JVM使用docker的cpu限制。如果docker有指定cpu limit,jvm参数也有指定-XX:ParalllelGCThreads 或者 -XX:CICompilerCount,那么以指定的参数为准。

memory limit

在java8u131+及java9,需要加上-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap才能使得Xmx感知docker的memory limit。

-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap (正确的识别容器限制,910.50M)安全

关于这个解释可以参考此文即可:http://virtual.51cto.com/art/201901/589723.htm

具体使用不使用这个参数需要结合实际情况。

 

后来据运维说是参数配置问题:

java -server -jar XXX.jar -Xms2048m -Xmx2048m 这是错的

java -server -jar -Xms2048m -Xmx2048m XXX.jar 要这样

Java线上程序频繁JVM FGC问题排障与启示

延申阅读:记一次频繁FGC的简单排查

一次JVM GC长暂停的排查过程

本文来源21aspnet,由架构君转载发布,观点不代表Java架构师必看的立场,转载请标明来源出处:https://javajgs.com/archives/2087

发表评论