我有一个连接器（Kafka连接）从Kafka流数据到其他一些系统。在处理了60000多条记录之后，它的速度急剧减慢，以至于我最终杀死了我的连接器。
我用jmap命令查看了gc，似乎只有我的幸存者空间已满（100%使用）。
怎么会这样？幸存者空间不只是一个临时的地方吗？我从这篇文章中了解到
我不能理解的是，它在完全使用幸存者空间之前处理了60000条记录。为什么以前不这样？难道他不应该把一部分留给老一代来腾出这个空间吗？
顺便说一句：我在独立模式下运行这个连接器，堆容量为256mb（107代表伊甸园+1代表幸存者+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条答案
按热度按时间6rqinv9w1#
我发现这个问题是由另一个做缓冲的应用程序造成的。无论如何谢谢你！
svdrlsy42#
好吧，你说的是“它的速度急剧下降”，但你甚至没有做基本的统计数据收集，例如，它是否被固定在100%的cpu或其他资源瓶颈。
假设它占用cpu时间，下一步是确定它是用在gc中还是用在应用程序代码中。gc日志和运行jstack、jstat或profiler将在这方面有所帮助。缓解将取决于这些发现。
在gc之后幸存者空间被填满是不寻常的，但是由于您正在进行流处理，分配的对象可能足够短暂，以至于对象根本无法存活足够长的时间，无法离开eden空间。如果没有更多的信息，很难判断这是否是一个问题。