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日志记录,则可能需要启用它并等待问题再次出现.)