问题生产环境告警和接口超时。原因是旧的gc耗时几十秒，导致系统瞬间卡顿，然后接口全部超时。另一个应用也用了好几秒，导致系统瞬间卡顿，然后大量报警。不是oldgc每次都会卡，而是oldgc偶尔会卡很久，大部分时间是正常的。oldgc耗时这么长的本质原因是什么？原因是因为之前有个节点连接到skywalking，然后调整了jvm配置，具体是：新生代和老年代的比例，默认是2，现在是4，old的大小内存加倍——导致老年代的gc阈值变高，所以很长时间会gc一次，但可能会造成单次时间过长。一个普通节点的oldgc如下。正常节点和异常节点的JVM配置异常节点$jinfo-flags11597AttachingtoprocessID11597,pleasewait...Debuggerattachsuccessfully.Servercompilerdetected.JVMversionis25.161-b12Non-defaultVMflags:-XX:CICompilerCount=4-XX:InitialHeapSize=3221225472-XX:MaxHeapSize=3221225472-XX:MaxMetaspaceSize=524288000-XX:MaxNewSize=643825664-XX:MetaspaceSize=314572800-XX:MinHeapDeltaXXBytes=5242800-XX:MinHeapDeltaXXXX4-XX66XX4-XX28-XX6688000-XX:MaxNewSize=643825664:OldSize=2577399808-XX:ThreadStackSize=512-XX:+UseCompressedClassPointers-XX:+UseCompressedOops-XX:+UseParallelGC//默认：吞吐量优先-新生代+多线程-老年代命令行：-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//new和old的比例，默认是2。现在是4，老内存的大小翻倍——导致老年代的gc阈值变高，所以会长时间gc一次，但是可能会造成单次时间过长。-Xss512k-XX:MetaspaceSize=300m-XX:MaxMetaspaceSize=500m注意：因为连接了skywalking，配置了jvm参数，导致jvm参数和普通节点不一样，本质上就是这个原因造成的。为什么新配置有问题？因为：新旧比例默认为2。现在是4，old内存的大小翻了一番——导致oldgeneration的gc阈值变高，所以很长时间会gc一次，但是可能会造成单次时间过长。注意这里只是连接到skywalking，因为skywalking占用资源，所以jvm内存应该增加，但是新旧比例不要增加。正常节点$jinfo-flags53022AttachingtoprocessID53022,pleasewait...Debuggerattachedsuccessfully.Servercompilerdetected.JVMversionis25.161-b12Non-defaultVMflags:-XX:CICompilerCount=3-XX:InitialHeap29Size=2:MaxHeapSize=2046820352-XX:MaxNewSize=682098688-XX:MinHeapDeltaBytes=524288-XX:NewSize=42467328-XX:OldSize=85458944-XX:+UseCompressedClassPointers-XX:+UseCompressedOops-XX:+UseFastUnorderedTimeStamps-XXelGC+UsePara//默认值garbagecollector命令行：-Ddubbo.application.name=xxx-base-Ddubbo.application.version=green-1解决方法是回滚jvm配置，即将问题节点的Jvm配置改成一样作为一个普通的节点。普通节点的jvm使用默认配置，即不配置jvm参数。本文由博客多发平台OpenWrite发布！
