抓取系统JVM调优

标签：启动   机制   use   red   new   判断   uri   新生代   man   

抓取系统，抓取的是国外某网站的数据
运营反应系统卡顿，于是登录到服务器，查看了一下JVM的启动参数(jinfo -flags + pid)
只设置了Command line: -Xss256k -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC这些参数，垃圾收集器年轻代用的是：ParNew 老年代用的是CMS

#jinfo打印的完整参数
jinfo -flags 30827
Attaching to process ID 30827, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.261-b12
Non-default VM flags: -XX:CICompilerCount=2 -XX:CompressedClassSpaceSize=260046848 -XX:InitialHeapSize=62914560 -XX:MaxHeapSize=994050048 -XX:MaxMetaspaceSize=268435456 -XX:MaxNewSize=174456832 -XX:MaxTenuringThreshold=6 -XX:MetaspaceSize=268435456 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=20971520 -XX:OldPLABSize=16 -XX:OldSize=41943040 -XX:ThreadStackSize=256 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseFastUnorderedTimeStamps -XX:+UseParNewGC 
Command line:  -Xss256k -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
由于没有设置最小堆（-Xms）最大堆（-Xmx）以及年轻代（-Xmn）所以我们看到初始堆大小只有60M，算一下年轻代（年轻代默认占整堆的1/3）只有20M，Survivor区（默认占年轻代的1/8）只有2M
因为是抓取系统，查看分析了抓取的频率以及数据量，综合数据移动到老年代的几个条件（大对象，经历15次gc后仍存活的对象<cms默认6次>，触发了对象动态年龄判断机制，出发了老年代空间分配担保机制）
分析得出，应该是由于未设置堆大小，致使使用默认配置（不合理），加上系统资源不足，而且抓取频率也比较高，同时抓取时使用线程池，导致jvm发生大量YGC\FGC

随后查看了一下gc情况（jstat -gc + pid）
发现YGC和FGC都非常频繁

调整配置
增加整堆大小设置，新生代大小设置，调整Eden区和Survivor区比例
贴上配置
nohup java -Xms1024m -Xmx1024m -Xmn512m -XX:SurvivorRatio=4 -Xss256k -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -jar ad-service.jar >/dev/null 2>&1 &
修改后，继续观察gc情况，发现gc非常平稳，基本没有FGC，而且FYC的频率也降低了

抓取系统JVM调优

标签：启动   机制   use   red   new   判断   uri   新生代   man   

原文地址：https://www.cnblogs.com/DayangJava/p/14286184.html