java - GC 调优 - 防止 Full GC

标签 java garbage-collection jvm performance

我试图避免 Full GC(来自下面的 gc.log 示例) 在生产中的 Tomcat 中运行 Grails 应用程序。 关于如何更好地配置 GC 有什么建议吗？

14359.317:[完整 GC 14359.317:[CMS:3453285K->3099828K(4194304K)，13.1778420 秒] 4506618K->3099828K(6081792K)，[CMS 权限:261951 K->181304K(264372K)] icms_dc=0 , 13.1786310 秒] [时间: user=13.15 sys=0.04, real=13.18 秒]

我的虚拟机参数如下:
-Xms=6G
-Xmx=6G
-XX:MaxPermSize=1G
-XX:NewSize=2G
-XX:MaxTenuringThreshold=8
-XX:SurvivorRatio=7
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled
-XX:+CMS增量模式
-XX:CMSInitiatingOccupancyFraction=60
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGC详细信息
-XX:+PrintGCTimeStamps
-XX:+PrintTenuringDistribution
-Dsun.reflect.inflationThreshold=0 

    14169.764: [GC 14169.764: [ParNew
    Desired survivor size 107347968 bytes, new threshold 8 (max 8)
    - age   1:   15584312 bytes,   15584312 total
    - age   2:   20053704 bytes,   35638016 total
    - age   3:   13624872 bytes,   49262888 total
    - age   4:   14469608 bytes,   63732496 total
    - age   5:   10553288 bytes,   74285784 total
    - age   6:   11797648 bytes,   86083432 total
    - age   7:   12591328 bytes,   98674760 total
    : 1826161K->130133K(1887488K), 0.1726640 secs] 5216326K->3537160K(6081792K) icms_dc=0 , 0.1733010 secs] [Times: user=0.66 sys=0.03, real=0.17 secs] 
    14218.712: [GC 14218.712: [ParNew
    Desired survivor size 107347968 bytes, new threshold 8 (max 8)
    - age   1:   25898512 bytes,   25898512 total
    - age   2:   10308160 bytes,   36206672 total
    - age   3:   16927792 bytes,   53134464 total
    - age   4:   13493608 bytes,   66628072 total
    - age   5:   14301832 bytes,   80929904 total
    - age   6:   10448408 bytes,   91378312 total
    - age   7:   11724056 bytes,  103102368 total
    - age   8:   12299528 bytes,  115401896 total
    : 1807957K->147911K(1887488K), 0.1664510 secs] 5214984K->3554938K(6081792K) icms_dc=0 , 0.1671290 secs] [Times: user=0.61 sys=0.00, real=0.17 secs] 
    14251.429: [GC 14251.430: [ParNew
    Desired survivor size 107347968 bytes, new threshold 7 (max 8)
    - age   1:   25749296 bytes,   25749296 total
    - age   2:   20111888 bytes,   45861184 total
    - age   3:    7580776 bytes,   53441960 total
    - age   4:   16819072 bytes,   70261032 total
    - age   5:   13209968 bytes,   83471000 total
    - age   6:   14088856 bytes,   97559856 total
    - age   7:   10371160 bytes,  107931016 total
    - age   8:   11426712 bytes,  119357728 total
    : 1825735K->155304K(1887488K), 0.1888880 secs] 5232762K->3574222K(6081792K) icms_dc=0 , 0.1895340 secs] [Times: user=0.74 sys=0.06, real=0.19 secs] 
    14291.342: [GC 14291.343: [ParNew
    Desired survivor size 107347968 bytes, new threshold 7 (max 8)
    - age   1:   25786480 bytes,   25786480 total
    - age   2:   21991848 bytes,   47778328 total
    - age   3:   16650000 bytes,   64428328 total
    - age   4:    7387368 bytes,   71815696 total
    - age   5:   16777584 bytes,   88593280 total
    - age   6:   13098856 bytes,  101692136 total
    - age   7:   14029704 bytes,  115721840 total
    : 1833128K->151603K(1887488K), 0.1941170 secs] 5252046K->3591384K(6081792K) icms_dc=0 , 0.1947390 secs] [Times: user=0.82 sys=0.04, real=0.20 secs] 
    14334.142: [GC 14334.143: [ParNew
    Desired survivor size 107347968 bytes, new threshold 6 (max 8)
    - age   1:   31541800 bytes,   31541800 total
    - age   2:   20826888 bytes,   52368688 total
    - age   3:   19155264 bytes,   71523952 total
    - age   4:   16422240 bytes,   87946192 total
    - age   5:    7235616 bytes,   95181808 total
    - age   6:   16549000 bytes,  111730808 total
    - age   7:   13026064 bytes,  124756872 total
    : 1829427K->167467K(1887488K), 0.1890190 secs] 5269208K->3620753K(6081792K) icms_dc=0 , 0.1896630 secs] [Times: user=0.80 sys=0.03, real=0.19 secs] 
    14359.317: [Full GC 14359.317: [CMS: 3453285K->3099828K(4194304K), 13.1778420 secs] 4506618K->3099828K(6081792K), [CMS Perm : 261951K->181304K(264372K)] icms_dc=0 , 13.1786310 secs] [Times: user=13.15 sys=0.04, real=13.18 secs]
    14373.287: [GC [1 CMS-initial-mark: 3099828K(4194304K)] 3100094K(6081792K), 0.0107380 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
    14373.298: [CMS-concurrent-mark-start]
    14472.579: [GC 14472.579: [ParNew
    Desired survivor size 107347968 bytes, new threshold 8 (max 8)
    - age   1:   42849392 bytes,   42849392 total
    : 1677824K->86719K(1887488K), 0.1056680 secs] 4777652K->3186547K(6081792K) icms_dc=0 , 0.1063280 secs] [Times: user=0.61 sys=0.00, real=0.11 secs] 
    14506.980: [GC 14506.980: [ParNew
    Desired survivor size 107347968 bytes, new threshold 8 (max 8)
    - age   1:   42002904 bytes,   42002904 total
    - age   2:   35733928 bytes,   77736832 total
    : 1764543K->96136K(1887488K), 0.0982790 secs] 4864371K->3195964K(6081792K) icms_dc=0 , 0.0988960 secs] [Times: user=0.53 sys=0.01, real=0.10 secs] 
    14544.285: [GC 14544.286: [ParNew
    Desired survivor size 107347968 bytes, new threshold 8 (max 8)
    - age   1:   26159736 bytes,   26159736 total
    - age   2:   37842840 bytes,   64002576 total
    - age   3:   33192784 bytes,   97195360 total
    : 1773960K->130799K(1887488K), 0.1208590 secs] 4873788K->3230628K(6081792K) icms_dc=0 , 0.1215900 secs] [Times: user=0.59 sys=0.02, real=0.13 secs] 
    14589.266: [GC 14589.266: [ParNew
    Desired survivor size 107347968 bytes, new threshold 4 (max 8)
    - age   1:   28010360 bytes,   28010360 total
    - age   2:   21136704 bytes,   49147064 total
    - age   3:   35081376 bytes,   84228440 total
    - age   4:   32468056 bytes,  116696496 total
    : 1808623K->148284K(1887488K), 0.1423150 secs] 4908452K->3248112K(6081792K) icms_dc=0 , 0.1429440 secs] [Times: user=0.70 sys=0.02, real=0.14 secs] 
    14630.947: [GC 14630.947: [ParNew
    Desired survivor size 107347968 bytes, new threshold 8 (max 8)
    - age   1:   28248240 bytes,   28248240 total
    - age   2:   20712320 bytes,   48960560 total
    - age   3:   18217168 bytes,   67177728 total
    - age   4:   34834832 bytes,  102012560 total
    : 1826108K->140347K(1887488K), 0.1784680 secs] 4925936K->3275469K(6081792K) icms_dc=0 , 0.1790920 secs] [Times: user=0.98 sys=0.03, real=0.18 secs] 
    14664.779: [GC 14664.779: [ParNew
    Desired survivor size 107347968 bytes, new threshold 5 (max 8)
    - age   1:   25841000 bytes,   25841000 total
    - age   2:   22264960 bytes,   48105960 total
    - age   3:   17730104 bytes,   65836064 total
    - age   4:   17988048 bytes,   83824112 total
    - age   5:   34739384 bytes,  118563496 total
    : 1818171K->147603K(1887488K), 0.1714160 secs] 4953293K->3282725K(6081792K) icms_dc=0 , 0.1720530 secs] [Times: user=0.82 sys=0.11, real=0.17 secs] 
    14702.488: [GC 14702.489: [ParNew
    Desired survivor size 107347968 bytes, new threshold 8 (max 8)
    - age   1:   26887368 bytes,   26887368 total
    - age   2:   21403352 bytes,   48290720 total
    - age   3:   18732224 bytes,   67022944 total
    - age   4:   17640576 bytes,   84663520 total
    - age   5:   17942952 bytes,  102606472 total
    : 1825427K->142695K(1887488K), 0.2118320 secs] 4960549K->3312168K(6081792K) icms_dc=0 , 0.2124630 secs] [Times: user=1.13 sys=0.14, real=0.21 secs]

我的目标策略是: 我想将终身使用的对象限制在最低限度，我正在处理请求，并期望除了一定数量的共享对象之外，所有其他对象仅对当前的请求有用。因此，通过使用较大的 NewSize 和增加的 TenuringThreshold，希望这些单一服务对象不会残留。

以下内容支持我的策略:
-Xms=6G
-Xmx=6G
-XX:NewSize=2G//足够大的空间，这样ParNew就不会经常发生，让对象有时间过期
-XX:MaxTenuringThreshold=8//进一步限制任期
-XX:SurvivorRatio=7//基于示例 -XX:CMSInitiatingOccupancyFraction=60
//防止升级分配失败导致的Full GC
-XX:+UseCMSInitiatingOccupancyOnly
//根据示例使用上面的内容

MaxPermSize=1G 和“-Dsun.reflect.inflationThreshold=0”与另一个我宁愿分开的问题有关。

“-XX:+CMSClassUnloadingEnabled”和“-XX:+CMSPermGenSweepingEnabled”之所以存在，是因为 grails 严重依赖额外的类来进行闭包和反射

-XX:+CMSIncrementalMode 是一个实验，尚未取得太大成功

最佳答案

发布的日志片段显示您有大量对象的存活时间超过 320 秒(每个年轻集合大约 40 秒，并且对象在升级之前经过 8 次集合的存活)。然后剩下的对象就会变成终身对象，最终你会遇到一个明显意想不到的完整GC，它实际上并没有收集太多东西。

3453285K->3099828K(4194304K)

即您有一个长期使用的 4G，触发时约占 82% (3453285/4194304)，13 秒后约占 74%。

这意味着花费了 13 秒来收集总计约 350M 的数据，这在 6G 堆的上下文中并不算多。

这基本上意味着你的堆不够大，或者更有可能的是，你有内存泄漏。像这样的泄漏对于 CMS 来说是一件可怕的事情，因为并发的 tenured 集合是一个非压缩事件，这意味着 tenured 是一个空闲列表的集合，这意味着碎片对于 CMS 来说可能是一个大问题，这意味着您对 tenured 的利用变得越来越低效。意味着升级失败事件的可能性增加(尽管如果这是这样一个事件，那么我希望看到一条日志消息说明这一点)，因为它想要升级(或认为需要升级)X MB 为终身职位但它没有可用的(连续)空闲列表 >= X MB。这会触发意外的永久收集，这是一个非远程并发的 STW 事件。如果你实际上没有什么可收集的(正如你所做的那样)，那么你坐在那里无所事事也就不足为奇了。

一些一般性的指示，在很大程度上重申了弗拉基米尔·西特尼托夫所说的话......

  • 在多核机器上使用 iCMS 没有任何意义(除非您有很多 JVM 或其他进程在该机器上运行，导致 JVM 确实缺乏 CPU)，因此删除此开关
  • 由于在每个集合的幸存者空间之间复制相对大量内存的影响，您的年轻集合不必要地长，150-200 毫秒是一个非常庞大的 ParNew 集合
    • 年轻一代问题的正确答案取决于分配行为的实际情况(例如，也许您最好尽早保留并减少碎片对永久集合的影响，或者也许您最好拥有更多更大规模的新生代并减少新生代收集的频率，从而减少提升的对象，从而最大限度地减少终身流失)。

一些问题...

  • 它最终会发生 OoM 还是会恢复？
  • 在此日志片段期间，应用程序是否处于稳定状态(在启动后的某个时刻承受一致的负载)还是处于压力之下？

关于java - GC 调优 - 防止 Full GC，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9792590/

上一篇：javascript - 通过引用传递 JavaScript 对象

下一篇：jwplayer - 如何在视频加载时立即隐藏 JWPlayer 或 FlowPlayer 上的控制栏

相关文章：

c# - 在 C# 中的运行时向类型化对象添加 expando 属性

没有 JVM 的 Java

java - 如何知道Java方法的字节码大小

java - 在 @PathVariable 和 @RequestParam 中使参数可选

java - 如何知道 List 对象是否具有固定大小

java - GC 如何阻止新创建的内存/对象在 GC 周期期间进行清理 (Java/C#)

java - 在命令行中捕获 RuntimeException 'cross-borders"——源自一个 jar 并抛出到另一个 jar 中

java - 不必要的数据库事务导致速度缓慢？

java - 构建失败 apache-tomcat-7.0.42-src build.xml

.net - 在 .NET 中，当您最小化程序时垃圾收集器被调用是真的吗？

©2024 IT工具网  联系我们