在此时间窗口中检测到记忆力衰竭的早期症状

Posted 2021-04-18

我正在努力理解新遗物引发的以下错误/警告：

在此时间窗口中检测到记忆力衰竭的早期症状。

以下是基于日志的配置文件图表。

我想了解：

1. 当轻微的GC发生时，为什么Eden Space永远不会完全清洁？
2. 根据日志中的GC行为，蓝色和黄色分别对应主要GC和次要GC吗？
3. 为什么GC一直在收集？
4. 红色区域是New Relic抛出内存耗尽警报的时候。但是，堆尚未满。这会触发断路器转换到开路状态吗？

在向我们的任务执行程序服务提交新的REST调用时，我注意到了这种行为（例如：executorService.submit(() -> restconecto.post(..))）。我尝试提交一个logger.info()，它工作正常，但似乎做一个长轮询是问题。以下是我的GC配置：

• 并行GC
• -Xms2048m -Xmx2048m

感谢您的任何见解。

答案

1. 垃圾收集器是一个守护程序线程，在JVM启动时启动，守护程序在所有非守护程序线程停止时停止。 GC持续运行的原因，以及应用程序从不干净的原因很可能是因为总有东西要收集（它甚至可能是后台任务）。最终用户无法控制垃圾收集器。
2. 真的不明白你的问题
3. 见1。
4. 为了触发警报，您​​的堆不必已满。默认情况下，遗物设置如下： Memory threshold: 20% Garbage collection CPU threshold: 10%

这些当然可以调整，但这些基本上意味着如果可用内存小于阈值，则触发警报。

正如您在提交REST请求时所注意到的那样（取决于实际提交的请求以及您的应用程序的结构/设计方式），此特定请求对于应用程序处理来说可能“很重”，因此它可能会使用您可能期望的更多内存。

另一答案

1. 你正在使用的年轻一代收藏家是PS Scavenge。此收集器并行使用多个线程。因此，没有一个完全停止世界的暂停来收集年轻一代的所有节点。因此，对于伊甸园空间，可用空间不会一直降至0％。
2. 图表上的黄色和蓝色线与主要或次要GC事件不对应。这取决于图表本身。但是，在垃圾收集CPU时间图表中，黄色区域对应于年轻代收集器PS Scavenge上花费的CPU时间，而蓝色区域对应于旧代收集器PS Mark Sweep上花费的CPU时间。
3. 垃圾收集器一直在运行，因为年轻的gen，幸存者和旧的收集器都在使用多个后台线程。这最大限度地减少了在单线程垃圾收集器中定期发生的世界停顿次数。
4. 根据我从图表中可以看出的情况，是的。红色区域是一段时间，在此期间New Relic确定它需要可能暂停程序并完全清理堆，以便程序可以继续运行。通常情况下，并发收集者最终会延迟世界各地的停顿，而不是完全阻止它们。有关详细信息，请参阅垃圾收集中的Gil Tene's seminal talk。有关断路器跳闸的条件的详细信息，请参阅this doc。