java - 为什么我提高内存时更频繁地获得 GC？

coder 2024-03-19 原文

我有一个关于 g1gc 的问题。

这些是堆使用图。

上面是-Xms4g -Xmx4g。
最下面是-Xms8g -Xmx8g。

我不知道为什么 8g 选项导致 g1gc 更频繁地发生。其他选项全部默认。

服务器规范是 40 个逻辑进程。

ps. What are the proper tuning options?

附加问题

内存分配是否可以更快，因为内存大小越大 -> 区域大小越大？

gc.log

4G gc.log

2019-05-07T21:03:42.093+0900: 10.280: [GC pause (G1 Evacuation Pause) (young), 0.1785373 secs]
   [Parallel Time: 43.4 ms, GC Workers: 28]
      [GC Worker Start (ms): Min: 10280.0, Avg: 10280.1, Max: 10280.6, Diff: 0.6]
      [Ext Root Scanning (ms): Min: 0.0, Avg: 0.4, Max: 0.8, Diff: 0.8, Sum: 12.0]
      [Update RS (ms): Min: 0.8, Avg: 1.1, Max: 1.6, Diff: 0.8, Sum: 31.5]
         [Processed Buffers: Min: 0, Avg: 2.0, Max: 3, Diff: 3, Sum: 56]
      [Scan RS (ms): Min: 0.0, Avg: 0.4, Max: 0.7, Diff: 0.7, Sum: 10.9]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 38.0, Avg: 38.5, Max: 39.9, Diff: 1.9, Sum: 1079.0]
      [Termination (ms): Min: 1.3, Avg: 2.6, Max: 3.2, Diff: 1.9, Sum: 74.1]
         [Termination Attempts: Min: 413, Avg: 769.6, Max: 855, Diff: 442, Sum: 21549]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.1, Sum: 2.0]
      [GC Worker Total (ms): Min: 42.7, Avg: 43.2, Max: 43.4, Diff: 0.7, Sum: 1209.5]
      [GC Worker End (ms): Min: 10323.3, Avg: 10323.3, Max: 10323.4, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.4 ms]
   [Other: 134.7 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 132.4 ms]
      [Ref Enq: 0.9 ms]
      [Redirty Cards: 0.3 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.7 ms]
   [Eden: 928.0M(928.0M)->0.0B(828.0M) Survivors: 26.0M->120.0M Heap: 1193.0M(4096.0M)->409.0M(4096.0M)]
Heap after GC invocations=8 (full 0):
 garbage-first heap   total 4194304K, used 418816K [0x00000006c0000000, 0x00000006c0204000, 0x00000007c0000000)
  region size 2048K, 60 young (122880K), 60 survivors (122880K)
 Metaspace       used 28525K, capacity 30824K, committed 31104K, reserved 1077248K
  class space    used 3583K, capacity 4166K, committed 4224K, reserved 1048576K
}
 [Times: user=1.21 sys=0.08, real=0.18 secs]
{Heap before GC invocations=8 (full 0):
 garbage-first heap   total 4194304K, used 744448K [0x00000006c0000000, 0x00000006c0204000, 0x00000007c0000000)
  region size 2048K, 219 young (448512K), 60 survivors (122880K)
 Metaspace       used 28525K, capacity 30824K, committed 31104K, reserved 1077248K
  class space    used 3583K, capacity 4166K, committed 4224K, reserved 1048576K
2019-05-07T21:03:42.895+0900: 11.082: [GC pause (G1 Evacuation Pause) (young), 0.0505563 secs]
   [Parallel Time: 11.6 ms, GC Workers: 28]
      [GC Worker Start (ms): Min: 11082.3, Avg: 11082.6, Max: 11083.6, Diff: 1.3]
      [Ext Root Scanning (ms): Min: 0.0, Avg: 0.4, Max: 0.8, Diff: 0.8, Sum: 9.9]
      [Update RS (ms): Min: 0.4, Avg: 1.0, Max: 1.5, Diff: 1.1, Sum: 29.4]
         [Processed Buffers: Min: 1, Avg: 1.8, Max: 3, Diff: 2, Sum: 50]
      [Scan RS (ms): Min: 0.8, Avg: 1.2, Max: 1.4, Diff: 0.6, Sum: 32.4]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Object Copy (ms): Min: 8.3, Avg: 8.4, Max: 8.6, Diff: 0.2, Sum: 236.3]
      [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 2.8]
         [Termination Attempts: Min: 1, Avg: 42.7, Max: 52, Diff: 51, Sum: 1195]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.1, Sum: 2.0]
      [GC Worker Total (ms): Min: 10.2, Avg: 11.2, Max: 11.5, Diff: 1.3, Sum: 312.9]
      [GC Worker End (ms): Min: 11093.7, Avg: 11093.8, Max: 11093.8, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.3 ms]
   [Other: 38.6 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 37.0 ms]
      [Ref Enq: 0.5 ms]
      [Redirty Cards: 0.3 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.5 ms]
   [Eden: 318.0M(252.0M)->0.0B(1052.0M) Survivors: 120.0M->48.0M Heap: 727.0M(4096.0M)->397.0M(4096.0M)]
Heap after GC invocations=9 (full 0):
 garbage-first heap   total 4194304K, used 406528K [0x00000006c0000000, 0x00000006c0204000, 0x00000007c0000000)
  region size 2048K, 24 young (49152K), 24 survivors (49152K)
 Metaspace       used 28525K, capacity 30824K, committed 31104K, reserved 1077248K
  class space    used 3583K, capacity 4166K, committed 4224K, reserved 1048576K
}
 [Times: user=0.34 sys=0.02, real=0.05 secs]
{Heap before GC invocations=9 (full 0):
 garbage-first heap   total 4194304K, used 912384K [0x00000006c0000000, 0x00000006c0204000, 0x00000007c0000000)
  region size 2048K, 271 young (555008K), 24 survivors (49152K)
 Metaspace       used 29461K, capacity 31868K, committed 32256K, reserved 1077248K
  class space    used 3681K, capacity 4237K, committed 4352K, reserved 1048576K

8G gc.log

2019-05-05T02:39:16.996+0900: 201016.724: [GC pause (G1 Evacuation Pause) (young), 0.0336675 secs]
   [Parallel Time: 12.9 ms, GC Workers: 28]
      [GC Worker Start (ms): Min: 201016724.7, Avg: 201016724.9, Max: 201016725.0, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 0.8, Avg: 1.2, Max: 5.2, Diff: 4.4, Sum: 32.4]
      [Update RS (ms): Min: 0.0, Avg: 3.1, Max: 3.5, Diff: 3.5, Sum: 87.7]
         [Processed Buffers: Min: 0, Avg: 11.1, Max: 30, Diff: 30, Sum: 310]
      [Scan RS (ms): Min: 0.1, Avg: 0.3, Max: 0.3, Diff: 0.2, Sum: 7.3]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [Object Copy (ms): Min: 6.9, Avg: 7.5, Max: 7.7, Diff: 0.8, Sum: 211.2]
      [Termination (ms): Min: 0.2, Avg: 0.3, Max: 0.4, Diff: 0.2, Sum: 9.0]
         [Termination Attempts: Min: 105, Avg: 124.7, Max: 146, Diff: 41, Sum: 3491]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 3.2]
      [GC Worker Total (ms): Min: 12.4, Avg: 12.5, Max: 12.7, Diff: 0.4, Sum: 350.8]
      [GC Worker End (ms): Min: 201016737.3, Avg: 201016737.4, Max: 201016737.5, Diff: 0.2]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.7 ms]
   [Other: 20.0 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 17.2 ms]
      [Ref Enq: 0.2 ms]
      [Redirty Cards: 0.3 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 1.7 ms]
   [Eden: 4864.0M(4864.0M)->0.0B(4868.0M) Survivors: 48.0M->44.0M Heap: 5968.1M(8192.0M)->1091.2M(8192.0M)]
Heap after GC invocations=19405 (full 0):
 garbage-first heap   total 8388608K, used 1117388K [0x00000005c0000000, 0x00000005c0404000, 0x00000007c0000000)
  region size 4096K, 11 young (45056K), 11 survivors (45056K)
 Metaspace       used 187853K, capacity 205120K, committed 210176K, reserved 1232896K
  class space    used 22574K, capacity 25471K, committed 26368K, reserved 1048576K
}
 [Times: user=0.39 sys=0.00, real=0.04 secs]
{Heap before GC invocations=19405 (full 0):
 garbage-first heap   total 8388608K, used 6106497K [0x00000005c0000000, 0x00000005c0404000, 0x00000007c0000000)
  region size 4096K, 1228 young (5029888K), 11 survivors (45056K)
 Metaspace       used 187853K, capacity 205120K, committed 210176K, reserved 1232896K
  class space    used 22574K, capacity 25471K, committed 26368K, reserved 1048576K
2019-05-05T02:39:33.830+0900: 201033.558: [GC pause (G1 Evacuation Pause) (young), 0.0373282 secs]
2019-05-05T02:39:33.830+0900: 201033.558: [GC pause (G1 Evacuation Pause) (young), 0.0373282 secs]
   [Parallel Time: 13.9 ms, GC Workers: 28]
      [GC Worker Start (ms): Min: 201033558.4, Avg: 201033558.5, Max: 201033558.6, Diff: 0.2]
      [Ext Root Scanning (ms): Min: 0.8, Avg: 1.2, Max: 4.5, Diff: 3.7, Sum: 32.5]
      [Update RS (ms): Min: 0.0, Avg: 2.8, Max: 3.1, Diff: 3.1, Sum: 77.4]
         [Processed Buffers: Min: 0, Avg: 10.3, Max: 31, Diff: 31, Sum: 289]
      [Scan RS (ms): Min: 0.1, Avg: 0.3, Max: 0.3, Diff: 0.3, Sum: 7.1]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [Object Copy (ms): Min: 8.5, Avg: 8.8, Max: 8.9, Diff: 0.4, Sum: 246.0]
      [Termination (ms): Min: 0.3, Avg: 0.4, Max: 0.5, Diff: 0.2, Sum: 12.0]
         [Termination Attempts: Min: 135, Avg: 156.5, Max: 175, Diff: 40, Sum: 4382]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 3.3]
      [GC Worker Total (ms): Min: 13.3, Avg: 13.5, Max: 13.7, Diff: 0.3, Sum: 378.4]
      [GC Worker End (ms): Min: 201033571.9, Avg: 201033572.0, Max: 201033572.1, Diff: 0.2]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.8 ms]
   [Other: 22.6 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 18.5 ms]
      [Ref Enq: 0.3 ms]
      [Redirty Cards: 1.0 ms]
      [Humongous Register: 0.1 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 2.1 ms]
   [Eden: 4868.0M(4868.0M)->0.0B(4880.0M) Survivors: 44.0M->32.0M Heap: 5963.4M(8192.0M)->1082.0M(8192.0M)]
Heap after GC invocations=19406 (full 0):
 garbage-first heap   total 8388608K, used 1107927K [0x00000005c0000000, 0x00000005c0404000, 0x00000007c0000000)
  region size 4096K, 8 young (32768K), 8 survivors (32768K)
 Metaspace       used 187853K, capacity 205120K, committed 210176K, reserved 1232896K
  class space    used 22574K, capacity 25471K, committed 26368K, reserved 1048576K
}
 [Times: user=0.41 sys=0.00, real=0.04 secs]
{Heap before GC invocations=19406 (full 0):
 garbage-first heap   total 8388608K, used 6122963K [0x00000005c0000000, 0x00000005c0404000, 0x00000007c0000000)
  region size 4096K, 1228 young (5029888K), 8 survivors (32768K)
 Metaspace       used 187853K, capacity 205120K, committed 210176K, reserved 1232896K
  class space    used 22574K, capacity 25471K, committed 26368K, reserved 1048576K

最佳答案

设置了G1GC的JVM会通过构造一个名为region的内存块来启动，不区分New/Survivor/Old物理内存。逻辑上有New/Survivor/Old，但物理上没有地址分隔。

对象在任意region创建，对象的referrer信息存储在一个Remember set中(使用整个Heap中的5% level)。 memset 是一种数据结构，可以很容易地知道哪个区域被分配了一个带有引用的对象。 (跟踪到该区域的引用)

如果要创建一个大于region大小的object，它会创建一个跨越多个region的Object，这组region称为Humongous。此信息也存储在 memset 中。

根据堆大小，区域大小可以从 1 MB 到 32 MB 不等。下表显示了如果未明确设置区域大小，将根据最小堆大小选择的区域大小。

|---------------------|------------------|
|    Min Heap Size    |   Region Size    |
|---------------------|------------------|
|     heap < 4GB      |       1MB        |
|---------------------|------------------|
|  4GB <= heap < 8GB  |       2MB        |
|---------------------|------------------|
|  8GB <= heap < 16GB |       4MB        |
|---------------------|------------------|
| 16GB <= heap < 32GB |       8MB        |
|---------------------|------------------|
| 32GB <= heap < 64GB |      16MB        |
|---------------------|------------------|
|     64GB < heap     |      32MB        |
|---------------------|------------------|

因此，在您的情况下，区域的大小将以不同方式计算。此外，内存分配模式可能因您的应用程序而异。为了找到更准确的原因，我们需要垃圾收集日志。

可以设置InitiatingheapOccupancyPercent让后台线程启动时间。堆使用量与总堆大小的比率。减小该值可以让您快速启动后台线程。默认值为 45。但是，如果该值太小，垃圾收集将运行得太频繁。它需要 CPU 周期并且可能会影响应用程序本身的性能。

如您所知，电锯图是健康的应用程序。因此，即使您不进行额外设置也没有大问题。

额外:可以帮助您解决问题的错误报告

Bug-8151176中的描述指的是为了实际计算IHOP而计算old gen occupancy/total heap size

这意味着年轻一代的职业完全被忽略了。即如果年轻代的fraction大于IHOP，则并发循环无法启动。

The reason is that static IHOP starts if old gen occupancy exceeds a fixed percentage of the current heap capacity. If either the user or ergonomics decide that the old gen cannot be larger than that fraction of the heap capacity that triggers concurrent mark, marking will never start.

关于java - 为什么我提高内存时更频繁地获得 GC？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56041590/

频繁 java Diff ms Min garbage-collection g1gc

有关java - 为什么我提高内存时更频繁地获得 GC？的更多相关文章

ruby - 为什么我可以在 Ruby 中使用 Object#send 访问私有(private)/ protected 方法？ - 2
类classAprivatedeffooputs:fooendpublicdefbarputs:barendprivatedefzimputs:zimendprotecteddefdibputs:dibendendA的实例a=A.new测试a.foorescueputs:faila.barrescueputs:faila.zimrescueputs:faila.dibrescueputs:faila.gazrescueputs:fail测试输出failbarfailfailfail.发送测试[:foo,:bar,:zim,:dib,:gaz].each{|m|a.send(m)resc
ruby-on-rails - Ruby net/ldap 模块中的内存泄漏 - 2
作为我的Rails应用程序的一部分，我编写了一个小导入程序，它从我们的LDAP系统中吸取数据并将其塞入一个用户表中。不幸的是，与LDAP相关的代码在遍历我们的32K用户时泄漏了大量内存，我一直无法弄清楚如何解决这个问题。这个问题似乎在某种程度上与LDAP库有关，因为当我删除对LDAP内容的调用时，内存使用情况会很好地稳定下来。此外，不断增加的对象是Net::BER::BerIdentifiedString和Net::BER::BerIdentifiedArray，它们都是LDAP库的一部分。当我运行导入时，内存使用量最终达到超过1GB的峰值。如果问题存在，我需要找到一些方法来更正我的代
ruby-on-rails - Rails - 子类化模型的设计模式是什么？ - 2
我有一个模型:classItem项目有一个属性“商店”基于存储的值，我希望Item对象对特定方法具有不同的行为。Rails中是否有针对此的通用设计模式？如果方法中没有大的if-else语句，这是如何干净利落地完成的？最佳答案通常通过Single-TableInheritance. 关于ruby-on-rails-Rails-子类化模型的设计模式是什么？，我们在StackOverflow上找到一个类似的问题： https://stackoverflow.co
ruby - 什么是填充的 Base64 编码字符串以及如何在 ruby 中生成它们？ - 2
我正在使用的第三方API的文档状态:"[O]urAPIonlyacceptspaddedBase64encodedstrings."什么是“填充的Base64编码字符串”以及如何在Ruby中生成它们。下面的代码是我第一次尝试创建转换为Base64的JSON格式数据。xa=Base64.encode64(a.to_json) 最佳答案他们说的padding其实就是Base64本身的一部分。它是末尾的“=”和“==”。Base64将3个字节的数据包编码为4个编码字符。所以如果你的输入数据有长度n和n%3=1=>"=="末尾用于填充n%
ruby - 解析 RDFa、微数据等的最佳方式是什么，使用统一的模式/词汇(例如 schema.org)存储和显示信息 - 2
我主要使用Ruby来执行此操作，但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式，例如使用这个yaml文件，它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i
ruby - 为什么 4.1%2 使用 Ruby 返回 0.0999999999999996？但是 4.2%2==0.2 - 2
为什么4.1%2返回0.0999999999999996？但是4.2%2==0.2。最佳答案参见此处:WhatEveryProgrammerShouldKnowAboutFloating-PointArithmetic实数是无限的。计算机使用的位数有限(今天是32位、64位)。因此计算机进行的浮点运算不能代表所有的实数。0.1是这些数字之一。请注意，这不是与Ruby相关的问题，而是与所有编程语言相关的问题，因为它来自计算机表示实数的方式。关于ruby-为什么4.1%2使用Ruby返
ruby - ruby 中的 TOPLEVEL_BINDING 是什么？ - 2
它不等于主线程的binding，这个toplevel作用域是什么？此作用域与主线程中的binding有何不同？>ruby-e'putsTOPLEVEL_BINDING===binding'false 最佳答案事实是，TOPLEVEL_BINDING始终引用Binding的预定义全局实例，而Kernel#binding创建的新实例>Binding每次封装当前执行上下文。在顶层，它们都包含相同的绑定(bind)，但它们不是同一个对象，您无法使用==或===测试它们的绑定(bind)相等性。putsTOPLEVEL_BINDINGput
ruby - Infinity 和 NaN 的类型是什么？ - 2
我可以得到Infinity和NaNn=9.0/0#=>Infinityn.class#=>Floatm=0/0.0#=>NaNm.class#=>Float但是当我想直接访问Infinity或NaN时:Infinity#=>uninitializedconstantInfinity(NameError)NaN#=>uninitializedconstantNaN(NameError)什么是Infinity和NaN？它们是对象、关键字还是其他东西？最佳答案您看到打印为Infinity和NaN的只是Float类的两个特殊实例的字符串
ruby-on-rails - 如果 Object::try 被发送到一个 nil 对象，为什么它会起作用？ - 2
如果您尝试在Ruby中的nil对象上调用方法，则会出现NoMethodError异常并显示消息:"undefinedmethod‘...’fornil:NilClass"然而，有一个tryRails中的方法，如果它被发送到一个nil对象，它只返回nil:require'rubygems'require'active_support/all'nil.try(:nonexisting_method)#noNoMethodErrorexceptionanymore那么try如何在内部工作以防止该异常？最佳答案像Ruby中的所有其他对象
ruby - 为什么 SecureRandom.uuid 创建一个唯一的字符串？ - 2
关闭。这个问题需要detailsorclarity.它目前不接受答案。想改进这个问题吗？通过editingthispost添加细节并澄清问题.关闭8年前。Improvethisquestion为什么SecureRandom.uuid创建一个唯一的字符串？SecureRandom.uuid#=>"35cb4e30-54e1-49f9-b5ce-4134799eb2c0"SecureRandom.uuid方法创建的字符串从不重复？

java - 为什么我提高内存时更频繁地获得 GC？

额外:可以帮助您解决问题的错误报告

有关java - 为什么我提高内存时更频繁地获得 GC？的更多相关文章

随机推荐