我有一个从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`
答案 0 :(得分:0)
嗯,你说"它显着减速"但你甚至没有做过基本的统计收集,例如它是否与100%的CPU挂钩,或者是否与其他资源有关。
假设耗费CPU时间,下一步是确定它是在GC中还是在应用程序代码中使用。 GC日志和运行jstack和jstat或分析器将有助于那里。缓解将取决于这些发现。
GC异常后幸存者空间已满,但由于您正在进行流处理,因此分配的对象可能短暂存在,以至于对象根本无法生存足够长的时间以使其脱离伊甸园空间。没有更多信息,很难判断它是否是一个问题。
答案 1 :(得分:0)
我发现问题是由另一个做缓冲的应用程序完成的。不管怎样,谢谢!