长时间偶然的年轻垃圾收集暂停
长时间偶然的年轻垃圾收集暂停
提问于 2012-07-17 07:45:55
我们调整我们的GC最低限度的“停止-世界”停顿。烫发和终年世代表现良好。年轻人大部分时间工作得很好，暂停时间通常不超过500毫秒(注：“时代”：user=0.35 sys=0.02，real=0.06 secs)：
{Heap before GC invocations=11603 (full 60):
par new generation total 3640320K, used 3325226K [0x0000000600000000, 0x00000006f6e00000, 0x00000006f6e00000)
eden space 3235840K, 100% used [0x0000000600000000, 0x00000006c5800000, 0x00000006c5800000)
from space 404480K, 22% used [0x00000006de300000, 0x00000006e3a4a898, 0x00000006f6e00000)
to space 404480K, 0% used [0x00000006c5800000, 0x00000006c5800000, 0x00000006de300000)
concurrent mark-sweep generation total 4147200K, used 1000363K [0x00000006f6e00000, 0x00000007f4000000, 0x00000007f4000000)
concurrent-mark-sweep perm gen total 196608K, used 133030K [0x00000007f4000000, 0x0000000800000000, 0x0000000800000000)
2012-07-16T14:36:05.641+0200: 427048.412: [GC 427048.412: [ParNew
Desired survivor size 207093760 bytes, new threshold 4 (max 4)
- age 1: 8688880 bytes, 8688880 total
- age 2: 12432832 bytes, 21121712 total
- age 3: 18200488 bytes, 39322200 total
- age 4: 20473336 bytes, 59795536 total
: 3325226K->75635K(3640320K), 0.0559610 secs] 4325590K->1092271K(7787520K), 0.0562630 secs] [Times: user=0.35 sys=0.02, real=0.06 secs]
Heap after GC invocations=11604 (full 60):
par new generation total 3640320K, used 75635K [0x0000000600000000, 0x00000006f6e00000, 0x00000006f6e00000)
eden space 3235840K, 0% used [0x0000000600000000, 0x0000000600000000, 0x00000006c5800000)
from space 404480K, 18% used [0x00000006c5800000, 0x00000006ca1dcf40, 0x00000006de300000)
to space 404480K, 0% used [0x00000006de300000, 0x00000006de300000, 0x00000006f6e00000)
concurrent mark-sweep generation total 4147200K, used 1016635K [0x00000006f6e00000, 0x00000007f4000000, 0x00000007f4000000)
concurrent-mark-sweep perm gen total 196608K, used 133030K [0x00000007f4000000, 0x0000000800000000, 0x0000000800000000)
}然而，有时，通常每天一次，我们会得到异常长的年轻垃圾收集时间(注意: user=0.41 sys=0.01，real=5.51 secs)：
{Heap before GC invocations=7884 (full 37):
par new generation total 3640320K, used 3304448K [0x0000000600000000, 0x00000006f6e00000, 0x00000006f6e00000)
eden space 3235840K, 100% used [0x0000000600000000, 0x00000006c5800000, 0x00000006c5800000)
from space 404480K, 16% used [0x00000006c5800000, 0x00000006c9b00370, 0x00000006de300000)
to space 404480K, 0% used [0x00000006de300000, 0x00000006de300000, 0x00000006f6e00000)
concurrent mark-sweep generation total 4147200K, used 1967225K [0x00000006f6e00000, 0x00000007f4000000, 0x00000007f4000000)
concurrent-mark-sweep perm gen total 189100K, used 112825K [0x00000007f4000000, 0x00000007ff8ab000, 0x0000000800000000)
2012-07-15T01:23:25.474+0200: 293088.245: [GC 293093.636: [ParNew
Desired survivor size 207093760 bytes, new threshold 4 (max 4)
- age 1: 30210472 bytes, 30210472 total
- age 2: 11614600 bytes, 41825072 total
- age 3: 8591680 bytes, 50416752 total
- age 4: 7779600 bytes, 58196352 total
: 3304448K->73854K(3640320K), 0.1158280 secs] 5271674K->2046454K(7787520K), 0.1181990 secs] [Times: user=0.41 sys=0.01, real=5.51 secs]
Heap after GC invocations=7885 (full 37):
par new generation total 3640320K, used 73854K [0x0000000600000000, 0x00000006f6e00000, 0x00000006f6e00000)
eden space 3235840K, 0% used [0x0000000600000000, 0x0000000600000000, 0x00000006c5800000)
from space 404480K, 18% used [0x00000006de300000, 0x00000006e2b1fb40, 0x00000006f6e00000)
to space 404480K, 0% used [0x00000006c5800000, 0x00000006c5800000, 0x00000006de300000)
concurrent mark-sweep generation total 4147200K, used 1972599K [0x00000006f6e00000, 0x00000007f4000000, 0x00000007f4000000)
concurrent-mark-sweep perm gen total 189100K, used 112825K [0x00000007f4000000, 0x00000007ff8ab000, 0x0000000800000000)
}以下是jstat -gccause的相关输出：
Timestamp S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
293083.2 16.96 0.00 96.26 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause No GC
293083.2 16.96 0.00 96.26 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause No GC
293084.2 16.96 0.00 97.69 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause No GC
293085.3 16.96 0.00 98.32 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause No GC
293086.3 16.96 0.00 99.32 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause No GC
Timestamp S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
293087.3 16.96 0.00 99.55 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause No GC
293088.3 16.96 0.00 100.00 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause Allocation Failure
293089.3 16.96 0.00 100.00 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause Allocation Failure
293090.3 16.96 0.00 100.00 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause Allocation Failure
293091.3 16.96 0.00 100.00 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause Allocation Failure
293092.3 16.96 0.00 100.00 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause Allocation Failure
293093.3 16.96 0.00 100.00 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause Allocation Failure
293084.2 16.96 0.00 100.00 47.44 59.66 7884 772.326 74 10.893 783.219 unknown GCCause Allocation Failure
293094.3 0.00 18.26 6.23 47.56 59.66 7885 772.442 74 10.893 783.334 unknown GCCause No GC
293094.6 0.00 18.26 6.71 47.56 59.66 7885 772.442 74 10.893 783.334 unknown GCCause No GC
293095.3 0.00 18.26 6.85 47.56 59.66 7885 772.442 74 10.893 783.334 unknown GCCause No GC
293095.6 0.00 18.26 6.92 47.56 59.66 7885 772.442 74 10.893 783.334 unknown GCCause No GC
293096.2 0.00 18.26 9.84 47.56 59.66 7885 772.442 74 10.893 783.334 unknown GCCause No GC
293096.6 0.00 18.26 10.11 47.56 59.66 7885 772.442 74 10.893 783.334 unknown GCCause No GC “分配失败”在其他地方也显示为GC原因，但始终是单个条目。当它出现在这样的序列中时，它与一个长GC暂停相关联。我查看了Oracle JVM源代码，“分配失败”看起来是一种非常自然的情况: Young没有空间用于新的数据，是时候清理了。在暂停发生之前，我检查了系统中任何内存密集型的意外操作，但没有发现任何可疑之处。
请注意，在暂停期间，年轻垃圾收集时间不会增加很多。我的内存和GC设置如下(省略了日志设置)：
-Xms6000m
-Xmn2950m
-Xmx6000m
-XX:MaxPermSize=192m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-Dsun.rmi.dgc.client.gcInterval=9223372036854775807
-Dsun.rmi.dgc.server.gcInterval=9223372036854775807
-XX:CMSInitiatingOccupancyFraction=50
-XX:+CMSScavengeBeforeRemark
-XX:+CMSClassUnloadingEnabled还测试了8000米和12000米堆。机器：
- 具有16 of内存的8核
- 具有50 of内存的24核
所以我的基本问题是:为什么ParNewGC的行为是这样的呢？
回答 1
Stack Overflow用户
发布于 2012-07-17 08:32:20
在执行GC之前，它必须将每个线程送到安全点(它不只是立即停止每个线程)。如果您长期运行JNI调用或系统调用，则可能需要很长时间才能到达安全点。在这种情况下，您看到的是很长的停顿，尽管集合本身的时间长度是正常的。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/11518102
复制相关文章
相似问题
腾讯云开发者
