GC Survivor Space Full

时间:2017-05-11 14:57:20

标签: java garbage-collection apache-kafka

我有一个从kafka到其他系统的连接器(Kafka-connect)流数据。在处理了60 000条记录之后,它会急剧减慢到我实际上最终杀死连接器的程度。

我用jmap命令查看了GC,似乎只有我的Survivor Space已满(100%使用)。

这怎么可能?幸存者空间不仅仅是一个临时的地方吗?据我所知this post

我无法理解的是,它在完全使用幸存者空间之前处理了6万条记录。为什么以前没有这种情况发生?难道他不能把这部分空间放到老一世这个空间吗?

Btw:我在独立模式下运行此连接器,堆为256MB(Eden为107,幸存者为1 + Old为95)

以下是jmap示例

Heap Configuration:

MinHeapFreeRatio         = 40
MaxHeapFreeRatio         = 70
MaxHeapSize              = 268435456 (256.0MB)
NewSize                  = 1363144 (1.2999954223632812MB)
MaxNewSize               = 160432128 (153.0MB)
OldSize                  = 5452592 (5.1999969482421875MB)
NewRatio                 = 2
SurvivorRatio            = 8
MetaspaceSize            = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize         = 17592186044415 MB
G1HeapRegionSize         = 1048576 (1.0MB) 

Heap Usage:

G1 Heap:
regions  = 256
capacity = 268435456 (256.0MB)
used     = 130770392 (124.71236419677734MB)
free     = 137665064 (131.28763580322266MB)
48.71576726436615% used
G1 Young Generation:
Eden Space:
regions  = 107
capacity = 167772160 (160.0MB)
used     = 112197632 (107.0MB)
free     = 55574528 (53.0MB)
66.875% used
Survivor Space:
regions  = 1
capacity = 1048576 (1.0MB)
used     = 1048576 (1.0MB)
free     = 0 (0.0MB)
100.0% used
G1 Old Generation:
regions  = 18
capacity = 99614720 (95.0MB)
used     = 17524184 (16.712364196777344MB)
free     = 82090536 (78.28763580322266MB)
17.591962312397204% used`

2 个答案:

答案 0 :(得分:0)

嗯,你说"它显着减速"但你甚至没有做过基本的统计收集,例如它是否与100%的CPU挂钩,或者是否与其他资源有关。

假设耗费CPU时间,下一步是确定它是在GC中还是在应用程序代码中使用。 GC日志和运行jstack和jstat或分析器将有助于那里。缓解将取决于这些发现。

GC异常后幸存者空间已满,但由于您正在进行流处理,因此分配的对象可能短暂存在,以至于对象根本无法生存足够长的时间以使其脱离伊甸园空间。没有更多信息,很难判断它是否是一个问题。

答案 1 :(得分:0)

我发现问题是由另一个做缓冲的应用程序完成的。不管怎样,谢谢!