2013-11-26T10:19:30.011+0800: [GC [ParNew: 2432484K->19997K(2696640K), 0.0378270 secs] 5560240K->3155822K(7691712K), 0.0398670 secs] [Times: user=0.18 sys=0.00, real=0.04 secs]
2013-11-26T10:19:36.277+0800: [GC [ParNew: 2417093K->15777K(2696640K), 0.0372550 secs] 5552917K->3151795K(7691712K), 0.0388490 secs] [Times: user=0.28 sys=0.00, real=0.04 secs]
**2013-11-26T10:19:36.325+0800: [GC [ParNew: 20441K->16452K(2696640K), 0.0186420 secs] 3156459K->3153092K(7691712K), 0.0200280 secs] [Times: user=0.17 sys=0.00, real=0.02 secs]**
2013-11-26T10:19:41.464+0800: [GC [ParNew: 2413508K->22811K(2696640K), 0.0426440 secs] 5550148K->3160128K(7691712K), 0.0444710 secs] [Times: user=0.25 sys=0.00, real=0.04 secs]
显然,小gc每5或6秒发生一次。
在2013-11-26T10:19:36.277之后,2013-11-26T10:19:36.325有一个小gc,只使用了20441K !!!
为什么小gc发生了(线上的blod)?谁知道?
更多细节:
这种现象每24小时不会超过10次。
有关我们服务器的更多详细信息:
CPU计数12个CPU
CPU速度2400 MHz
内存总计16322984 KB
jvm(热点1.6.0_26)的参数是:
-Xms7804M -Xmx7804M -Xmn2926M -XX:PermSize = 256M -XX:MaxPermSize = 256M -XX:SurvivorRatio = 8 -XX:TargetSurvivorRatio = 70 -XX:MaxTenuringThreshold = 10 -server -Xss256k -XX:+ HeapDumpOnOutOfMemoryError -XX :+ PrintGCDetails -XX:+ PrintGCDateStamps -XX:+ UseConcMarkSweepGC -XX:+ DisableExplicitGC -XX:SoftRefLRUPolicyMSPerMB = 0 -XX:CMSInitiatingOccupancyFraction = 75 -XX:+ UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads = 12 -XX:+ CMSScavengeBeforeRemark -XX:+ CMSClassUnloadingEnabled
@Alexey Ragozin更多日志:
2013-11-27T23:34:47.352+0800: [GC [ParNew: 2496458K->81521K(2696640K), 0.0381510 secs] 5104803K->2690529K(7691712K), 0.0406260 secs] [Times: user=0.28 sys=0.00, real=0.04 secs]
2013-11-27T23:34:51.745+0800: [GC [ParNew: 2478577K->57599K(2696640K), 0.0535680 secs] 5087585K->2716762K(7691712K), 0.0554400 secs] [Times: user=0.28 sys=0.01, real=0.06 secs]
2013-11-27T23:34:55.728+0800: [GC [ParNew: 2454747K->19841K(2696640K), 0.0300150 secs] 5113910K->2679701K(7691712K), 0.0320030 secs] [Times: user=0.18 sys=0.00, real=0.03 secs]
**2013-11-27T23:34:55.769+0800: [GC [ParNew: 21438K->16389K(2696640K), 0.0171200 secs] 2681299K->2676788K(7691712K), 0.0187850 secs] [Times: user=0.13 sys=0.00, real=0.02 secs]**
2013-11-27T23:34:59.888+0800: [GC [ParNew: 2413445K->16017K(2696640K), 0.0251400 secs] 5073844K->2676744K(7691712K), 0.0271570 secs] [Times: user=0.15 sys=0.00, real=0.02 secs]
2013-11-27T23:35:04.374+0800: [GC [ParNew: 2413073K->16059K(2696640K), 0.0240360 secs] 5073800K->2677460K(7691712K), 0.0259960 secs] [Times: user=0.15 sys=0.00, real=0.03 secs]
... ...
2013-11-28T02:56:57.719+0800: [GC [ParNew: 2449927K->45500K(2696640K), 0.0360740 secs] 6195838K->3791742K(7691712K), 0.0379370 secs] [Times: user=0.23 sys=0.00, real=0.03 secs]
2013-11-28T02:57:37.987+0800: [GC [ParNew: 2442556K->54097K(2696640K), 0.0383490 secs] 6188798K->3800678K(7691712K), 0.0402170 secs] [Times: user=0.23 sys=0.00, real=0.04 secs]
2013-11-28T02:57:38.036+0800: [GC [1 CMS-initial-mark: 3746580K(4995072K)] 3801777K(7691712K), 0.0694940 secs] [Times: user=0.06 sys=0.00, real=0.07 secs]
2013-11-28T02:57:38.770+0800: [CMS-concurrent-mark: 0.661/0.662 secs] [Times: user=2.15 sys=0.00, real=0.66 secs]
2013-11-28T02:57:38.806+0800: [CMS-concurrent-preclean: 0.035/0.035 secs] [Times: user=0.06 sys=0.01, real=0.04 secs]
CMS: abort preclean due to time 2013-11-28T02:57:43.862+0800: [CMS-concurrent-abortable-preclean: 5.016/5.056 secs] [Times: user=6.82 sys=0.19, real=5.05 secs]
**2013-11-28T02:57:43.872+0800: [GC[YG occupancy: 407766 K (2696640 K)]2013-11-28T02:57:43.872+0800: [GC [ParNew: 407766K->35780K(2696640K), 0.0236470 secs] 4154346K->3782623K(7691712K), 0.0256460 secs] [Times: user=0.20 sys=0.00, real=0.03 secs]**
[Rescan (parallel) , 0.0119390 secs][weak refs processing, 0.8478360 secs][class unloading, 0.0661530 secs][scrub symbol & string tables, 0.0146780 secs] [1 CMS-remark: 3746843K(4995072K)] 3782623K(7691712K), 1.1138910 secs] [Times: user=1.41 sys=0.00, real=1.12 secs]
2013-11-28T02:57:48.965+0800: [CMS-concurrent-sweep: 3.893/3.977 secs] [Times: user=5.65 sys=0.15, real=3.97 secs]
2013-11-28T02:57:48.977+0800: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
答案 0 :(得分:2)
-XX:+CMSScavengeBeforeRemark
是您奇怪的小集合的原因。
CMS必须进行2次世界停留以完成旧的空间收集周期
他们都需要扫描整个年轻空间。年轻人收藏后,年轻空间中的物品数量非常少,因此在收集年轻品后,旧的空间收集暂停了。
一旦CMS准备好暂停评论, -XX:+CMSScavengeBeforeRemark
选项会强制收集年轻人,即使Eden尚未满员。
你会在每个旧的空间收集周期中看到这个“现象”。
有关CMS机制的更多详细信息 - Understanding GC pauses in JVM, HotSpot's CMS collector
有关JVM GC选项的更多信息 - HotSpot JVM garbage collection options cheat sheet
UPDATE
从技术上讲,还有另一个原因可能导致年轻的早产儿。如果应用程序试图分配不适合Eden的大型数组,JVM可能会开始收集空闲空间。这是可能的,但更有可能的是JVM会选择直接在旧空间中分配这个数组。
答案 1 :(得分:0)
我怀疑除了编写和/或维护特定GC的人之外,任何人都能正确/正确地解释这种现象。
但是,我会发现你的应用程序正在创造大量的垃圾。每6秒2400000K == 2.4Gb的垃圾。你有一个病态的应用程序,或者这是一个非常不现实的垃圾收集器基准测试......它不会告诉你有关GC如何为实际应用程序行事的任何有意义的事情。
如果您仅仅为了满足您的好奇心而提出此问题,我建议您自己调查此现象......然后将结果作为自我答案报告。
答案 2 :(得分:0)
当年轻一代填满时会发生轻微的地方选区。如果遵循,以高速率创建新对象的应用程序将经历越来越多的次要垃圾收集。鉴于您发布的GC日志,您的应用程序也可以看到相同的行为。您可以高速创建对象,从而经常触发较小的GC。
有关GC的更多信息,您可以查看此资源:http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html