我使用tomcat7和JRE 1.8运行Java WebApp。该应用程序缓存大量数据(~15GB),并支持高吞吐量(~4K /秒)。由于请求率高,它会在年轻一代中生成大量对象,其中一些对象在年轻一代的ParNew集合中存活,并且被移动到幸存者并最终移动到堆内存中的旧代空间。
这些对象不断累积在旧一代中。当老一代几乎满员时,CMS就会开始运作,这会导致世界各地的GC停滞不前。这会影响我的应用程序的延迟。
为了避免这种情况,我开始使用CMSInitiatingOccupancyFraction = 85和+ UseCMSInitiatingOccupancyOnly。然而,尽管有这两个选项,当老一代人满85%时,CMS并没有开始。它仍然发生在老一代几乎已经完成并且做了一个停止世界的GC。我搜索了CMSInitiatingOccupancyFraction的限制,但找不到任何解释行为的相关链接。请在下面找到我的tomcat进程的确切命令行:
jsvc.exec -home /usr/lib/jvm/jre1.8.0_45 -user tomcat7 -pidfile /home/ameya/service/2.0.4-SNAPSHOT/logs/catalina-daemon.pid -outfile /home/ameya/service/2.0.4-SNAPSHOT/logs/catalina-daemon.out -errfile &1 -classpath /home/ameya/conf/service:/home/ameya/service/2.0.4-SNAPSHOT/bin/bootstrap.jar:/home/ameya/service/2.0.4-SNAPSHOT/bin/commons-daemon.jar:/home/ameya/service/2.0.4-SNAPSHOT/bin/tomcat-juli.jar -Djava.util.logging.config.file=/home/ameya/service/2.0.4-SNAPSHOT/conf/logging.properties -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true -XX:PermSize=1G -XX:MaxPermSize=5G -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=85 -Xms12G -Xmx24G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9004 -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Duser.language=en -Duser.country=US -Dsun.net.inetaddr.ttl=30 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/dump.tmp -XX:+AggressiveOpts -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs= -Dcatalina.base=/home/ameya/service/2.0.4-SNAPSHOT -Dcatalina.home=/home/ameya/service/2.0.4-SNAPSHOT -Djava.io.tmpdir=/home/ameya/service/2.0.4-SNAPSHOT/temp org.apache.catalina.startup.Bootstrap
有人可以帮助我理解为什么当老一代人满85%时CMS没有开始运行?
答案 0 :(得分:1)
根据oracle forums增量CMS忽略InitiatingOccupancyFraction。
iCMS在openjdk 9中也是deprecated和will be removed。并且在服务器计算机上没有多大意义,因为它主要用于在具有一个或两个核心的处理器上运行的应用程序