【问题标题】:DSE Garbage Collection on non-heap CMS Perm Gen took a long time非堆 CMS Perm Gen 上的 DSE 垃圾收集需要很长时间
【发布时间】:2014-03-12 21:17:23
【问题描述】:

我在 Datastax-enterprise 的 Cassandra/Solr 包中遇到了长时间的 GC 暂停(> 10 秒)。经过几天的监控,我发现它只发生在 CMS Perm Gen 的 GC 发生时,如图所示。当 PermGen GC 发生时,长 GC 发生在图表的每个拐点。而且每次 Perm Gen GC 启动时,都会有很长的暂停,导致客户端会话超时!

https://www.dropbox.com/s/qgdcurprvc1sees/permgen_gc.png

Heap GC 是正常的,没有停顿,只有在 Non-heap Perm Gen GC 中总是会出现长时间的停顿,这种情况总是发生在服务器非高峰时间。

![在此处输入图片描述][1]

DSE 使用的 JVM 选项:

-ea -javaagent:/usr/local/dse/resources/cassandra/lib/jamm-0.2.5.jar 
-XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42
-Xms16384M -Xmx16384M -Xmn5461M -XX:+HeapDumpOnOutOfMemoryError 
-Xss180k -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled 
-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
-XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly 
-Djava.net.preferIPv4Stack=true -Dcassandra.load_ring_state=false 
-Dcassandra-foreground=yes -Dsearch-service=true
-Dtomcat.logs=/var/log/dse/tomcat -DName=SI2_DSE
-Ddse.solr.data.dir=/data/solrIndexRamDisk
-Djava.library.path=/usr/local/dse/resources/hadoop/native/Linux-amd64-64/lib

JVM 信息

  • 虚拟机:Java HotSpot(TM) 64 位服务器 VM 版本 20.12-b01
  • 供应商:Sun Microsystems Inc.
  • JIT 编译器:HotSpot 64 位分层编译器

堆信息

  • 当前堆大小:10,247,153 KB
  • 最大堆大小:16,218,048 KB
  • 提交的内存:16,218,048 KB
  • 待完成:{0} 个对象

虚拟机服务器信息

  • 操作系统:Linux 2.6.32-279.1.1.el6.x86_64
  • 架构:amd64
  • 处理器数量:32
  • 提交的虚拟内存:39,845,596 KB
  • 总物理内存:99,018,824 KB
  • 可用物理内存:58,184,572 KB
  • 总交换空间:4,194,296 KB
  • 可用交换空间:4,194,296 KB

【问题讨论】:

  • 您能否在您的 system.log 中验证 JNA 已正确安装和加载?

标签: solr garbage-collection jvm permgen datastax-enterprise


【解决方案1】:

如果你可以直接使用 Solr,你可以试试 Heliosearch,它试图解决堆外数据的 GC 暂停问题。

http://heliosearch.org/off-heap-filters/

【讨论】:

    【解决方案2】:

    使用-XX:+CMSClassUnloadingEnabled,它允许CMS收集器在oldgen GC期间清除permgen并卸载不再使用的类。 链接:http://blog.redfin.com/devblog/2012/06/cmsclassunloadingenabled-at-redfin.html#.UwWeO4XqPK0

    使用 100 或 200 MB 的大小进行 perm 生成,而不是 60 MB。

    试试看,如果能解决你的问题,分享一下

    【讨论】:

    • 它只是延迟了炸弹:(
    • 你使用的 perm generation 的大小是多少?以前这 10 秒的暂停是在 5 小时内发生的(正确的?)现在的频率是多少。如果通过调整 perm gen 的大小将其推迟生产时间会有帮助吗?您的应用程序是 24-7 类型还是每天都需要重新启动?
    • MaxPermSize = 85Mb,但最大使用量仅为 57Mb 这是一个 24x7 的服务,我们已经在多个不同时间执行 GC 的服务器上进行滚动重启。这是相当麻烦的操作并且容易出错。
    • 尝试 MaxPermSize = 200m -XX:PermSize=200m 目前 57/85 ~ 67% 的 Perm Generation 利用率。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-06-26
    • 1970-01-01
    • 1970-01-01
    • 2012-06-28
    • 1970-01-01
    • 1970-01-01
    • 2014-03-27
    相关资源
    最近更新 更多