java jvm-old gc耗时几十s，导致系统告警

最新推荐文章于 2025-03-02 14:02:21 发布

原创最新推荐文章于 2025-03-02 14:02:21 发布 · 1.8k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#java

博客讨论了生产环境中因调整JVM配置，特别是新生代与老年代比例增大，导致oldgc耗时过长，进而引发接口超时的问题。问题的根本原因是接入Skywalking并调整内存分配，使得老年代gc阈值提高。解决方法是回滚到正常的JVM配置，避免老年代gc过于频繁或耗时过长。

问题

生产环境告警，接口超时。

原因

old gc耗时几十s，导致系统瞬间卡死，然后接口都超时了。

另外一个应用也是耗时好几s，导致系统瞬间卡死，然后很多告警。

不是每次old gc都会卡死，而是偶尔一次old gc才会耗时很久，大部分时候正常。

本质原因

为什么old gc耗时这么久？原因是因为之前有一个节点接入skywalking，然后调整了jvm配置，具体是：新生代和老年代的比例，默认是2。现在是4，老的内存大小翻倍——导致老年代的gc阈值变高了，所以才会很久gc一次，但是有可能导致单次耗时太久。

正常节点的old gc是下面这样。

正常节点和异常节点的jvm配置

异常节点

$ jinfo -flags 11597

Attaching to process ID 11597, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.161-b12

Non-default VM flags:

-XX:CICompilerCount=4 -XX:InitialHeapSize=3221225472 -XX:MaxHeapSize=3221225472

-XX:MaxMetaspaceSize=524288000

-XX:MaxNewSize=643825664

-XX:MetaspaceSize=314572800

-XX:MinHeapDeltaBytes=524288 -XX:NewRatio=4 -XX:NewSize=643825664 -XX:OldSize=2577399808 -XX:ThreadStackSize=512 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops

-XX:+UseParallelGC //默认：吞吐量优先-新生代 + 多线程-老年代

Command line: -javaagent:/home/xxx/private-cloud/agent/skywalking-agent.jar -Dskywalking.agent.service_name=trade-base -Dskywalking.agent.instance_uuid=xxx -Ddubbo.application.name=xxx-base -Ddubbo.application.version=green-1

-Xmx3072m -Xms3072m

-XX:NewRatio=4 //新和老的比例，默认是2。现在是4，老的内存大小翻倍——导致老年代的gc阈值变高了，所以才会很久gc一次，但是有可能导致单次耗时太久。

-Xss512k

-XX:MetaspaceSize=300m

-XX:MaxMetaspaceSize=500m

注：因为接入了skywalking，并且配置了jvm参数，所以jvm参数和正常节点不一样，本质就是因为这个原因导致的。

为什么新的配置就有问题？因为：新和老的比例，默认是2。现在是4，老的内存大小翻倍——导致老年代的gc阈值变高了，所以才会很久gc一次，但是有可能导致单次耗时太久。

注意这个只是接入了skywalking，并且由于skywalking占用资源，所以jvm内存调大，但是新老比例不应该调大。