问题标签 [g1gc]

我设置ParallelGCThreads=1和使用G1 GC，所有其他JVM设置都是默认的。我PageRank在 Spark-1.5.1 上运行，有两个 EC2 节点，每个节点有 100 GB 堆。

我的堆使用图如下（红色区域：年轻代，黑色区域：老年代）。所有的young GC都很小，突然有一个young GC收集了60GB，然后young GC又变小了。我的 GC 日志显示没有混合 GC、没有完整 GC、一个并发标记和数十个年轻 GC。我想知道为什么会发生那个巨大的年轻 GC？

下面是我的 GC 日志的一部分。巨大的年轻GC是具有“Heap：84.1G”的GC

根据：

9 垃圾优先垃圾收集器

和：

G1：Java 的垃圾优先垃圾收集器

G1 针对具有大内存的多处理器机器。

那两篇论文（和其他网络论文）没有描述我们为什么需要：大记忆 B. 多处理器（我认为这是由于并发和并行的需要）

这些要求的技术解释是什么？

我正在使用不同的 G1 配置测试 Spark-1.5.1，并观察到我的应用程序需要 2 分钟才能完成 MaxGCPauseMillis = 200（默认）和 4 分钟 MaxGCPauseMillis = 1。堆使用情况如下所示。我们可以从下面的统计数据中看到，两个配置的 GC 时间仅相差 5 秒。

我想知道为什么执行时间会增加这么多？

一些统计数据：

MaxGCPauseMillis = 200 - 年轻 GC 数：67；一个executor的GC时间：9.8秒

MaxGCPauseMillis = 1 - 年轻 GC 数：224；一个executor的GC时间：14.7秒

红色区域是年轻一代，黑色是老一代。该应用程序在 10 个节点上运行，每个节点有 1 个执行程序和 6 GB 堆。

该应用程序是一个字数统计示例：

对于垃圾优先收集器，年轻 gc意味着仅在年轻代中执行 gc， 混合 gc 将清理年轻代和老年代。

那么什么是完整的 gc呢？为什么它比混合 gc持续时间更长？

我进行了一些搜索，但没有找到任何解释完整 gc的帖子。

我一直在尝试在我的应用程序上使用 G1，并注意到与 java 7u91 上的默认垃圾收集器相比，启动应用程序需要更多时间。另一方面，像 G1 应该执行的那样执行的集合更少。

G1速度慢有什么原因吗？我的应用程序使用 128mb 的最小和最大堆，超过 Solaris 64 位版本，VM 没有自定义参数。（Java服务器版）

谁能解释一下 G1 收集器如何确定年轻区域的数量？G1 论文指出“我们通过历史平均跟踪完全年轻收集的固定和每个区域的成本，并使用这些估计来确定在完全年轻的疏散暂停之间分配的年轻区域的数量”，但没有详细信息。

例如，给定下面的 GC 日志，预测年轻区域时间是什么意思，它是如何计算的？伊甸园和幸存者如何计算？

我正在测试基于 Jetty 的 API 与基于 Netty 的 API。实验中唯一的区别是我使用的 API（相同的应用程序、相同的服务器、相同的内存配置、相同的负载等），我使用基于 Netty 的 API 获得了更长的 GC 暂停。大多数情况下，停顿低于一毫秒，但在平稳运行几天后，每 12-24 小时我会看到 4-6 秒的停顿，而基于 Jetty 的 API 不会出现这种停顿。

每当发生这种情况时，关于 G1 正在做什么导致它发出 STW 的信息非常少，请注意此处的第二条暂停消息：

我的 GC 选项是：

而且，作为参考，我的 VM 选项是：

我如何找出为什么G1 停止了世界2016-02-23T05:22:35.642？

我尝试在我的程序中使用 G1GC。程序用于具有各种内存大小的各种机器：具有 1Gb 内存（最小）的 VPS、具有 8Gb 内存的台式机、具有 32Gb 内存（最大）的 DS。我注意到即使有很多可用内存，G1GC 也不会保留更多内存（例如，G1GC 在我的机器上没有保留超过 3Gb，总共 8Gb / 4Gb 空闲）

PS我想要通用的解决方案。我无法为每种类型的机器创建单独的版本或单独的运行脚本。

多年来，我们一直使用+UseParallelOldGC. 现在，我们开始使用更大的堆和 G1 收集器推出一项新服务。这进展顺利。

对于我们使用 的服务+UseParallelOldGC，我们通过在收集后查看老年代大小并在阈值上发出警报来监控内存泄漏。这很有效，事实上两周前我们的培根就保存了。

具体来说，对于+UseParallelOldGC，我们执行以下操作：

• ManagementFactory.getMemoryPoolMXBeans()
• 搜索MemoryPoolMXBean名称以结尾的结果"Old Gen"
• 比较getCollectionUsage().getUsed()（如果有的话）getMax()

不幸的是，G1 似乎不再有getCollectionUsage().

不过，从根本上说，我们希望在 G1 选择在混合循环中进行的最后一次混合收集之后监控 G1 堆大小，或者类似的事情。

例如，在 VM 之外，我会对一个 awk 脚本感到满意，该脚本仅发现最后一个'(mixed)'是后跟 a'(young)'并查看最终堆大小是多少（例如，'1540.0M' 'Heap: 3694.5M(9216.0M)->1540.0M(9216.0M)'）

有没有办法在 Java VM 中做到这一点？

我正在使用 G1 垃圾收集器。

您可以启用自适应大小策略日志

这是 GC 日志中的示例输出

1822.780: [G1Ergonomics (Heap Sizing) 尝试堆扩展，原因：最近 GC 开销高于 GC 后的阈值，最近 GC 开销：11.48 %，阈值：10.00 %，未提交：0 字节，计算的扩展量：0 字节（20.00 %） ]

哪个 JVM 标志管理阈值：其中提到的10.00 % ？

下面是一些似乎相关的标志，但我尝试为其中一些设置不同的值，并且日志消息没有改变。