GC需要三个小时才能降低1.2GB的堆，这可能是什么原因？

Question

在我们的一台服务器中，垃圾收集花了近三个小时试图降低（成功）1.2GB的堆内存。从1.4GB到200MB。

在此期间CPU使用率很高，几乎达到80-100％。可能是什么原因？我们有4个这样的服务器具有相同的配置（JVM设置，服务器配置，硬件，网络），假设没有人对它进行任何更改，这可能是特定服务器运行3小时GC的原因。

所有其他服务器每个GC活动只需要5到10分钟。

请附上HP BAC的图表，以便于参考。显示我认为GC启动的时间，以及GC停止的时间。

（斯蒂芬指出更多结论性结论）当服务器管理员回复我时提供这些信息：

• 您的JVM的确切版本 使用。 （标准Java SE 1.4.2）
• JVM选项。的（编辑）
• 详情 Web容器/服务器库。的（编辑）
• 有关服务的信息 确实。来自的任何相关线索 服务器/服务日志文件（即将发布）
• 请求记录中的任何相关模式（即将发生）
• GC记录时间 事件。 （如果你现在没有 您可能需要启用GC日志记录 启用它并等到问题 再次发生。）（即将发生）

Answer 1

这里没有太多数据可供使用，但我的预感是：你正在交换。我们唯一一次看到GC时间那么高，就是当你过度使用盒子并且它正在分页到磁盘时。这可以将事物变成一个数量级（或更多）的性能降级。

您需要收集操作系统（如果适用，可能会收集虚拟机管理程序）交换统计数据以证明或反驳这一理论。

（我知道CPU时间高于我预期的交换时间，但你永远不知道。）

如果您发布硬件配置，“java -version”信息和JVM命令行参数（例如：-Xmx和-Xms）以帮助缩小您实际运行的内容，那么也会有所帮助。

Answer 2

您没有提供太多信息，但可能的原因可能是：

• 申请中的错误;例如内存泄漏具有一些相当特殊的特征，或者一个任务一直耗尽内存然后重新启动。

• 意外或故意拒绝服务攻击;例如一些客户端一直在使用参数来重试超大请求，每次都会减少“问题大小”。

• 具有特定特征的单个极长时间运行请求。

• 捶打 - 请参阅@Trent Gray-Donald的回答。 （如果你有全面的内存，那么GC算法，包括查看大量页面上随机散布的大量对象，很可能会引发颠簸。我只是不确定这会导致像你这样逐渐下降的堆使用正在看。）

• JVM设置的病态组合。

• 您正在使用的特定JVM中的垃圾收集器中的错误。

• 以上的一些组合。

这是一个需要获得Oracle / Java支持合同的问题。

---

以下信息可能有助于诊断：

• 您正在使用的JVM的确切版本。
• JVM选项。
• Web容器/服务器库的详细信息。
• 有关服务的信息。
• 来自服务器/服务日志文件的任何相关线索
• 请求日志中的任何相关模式
• GC记录事件发生的时间。 （如果您当前没有启用GC日志记录，则可能需要启用它并等到问题再次出现。）