Java 应用程序因堆而变慢

Question

我们在高峰时间遇到严重的应用程序问题，应用程序变得非常非常慢，当我检查 AppDynamics 矩阵时，我的堆内存已满并且每分钟都会启动 GC，这使得它非常非常慢。这是我的java(tomcat)的配置

OS version is Redhat 5 Linux

java version "1.6.0_05" 64Bit

Java 选项是 -Djava.awt.headless=true -Xmx2048m -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC

每分钟 Major GC 收集时间花费(毫秒)

CMS Old Gen 使用量(以 MB 为单位)

以 MB 为单位的 Eden 空间

有什么建议可以解释为什么 par eden space 和 old gen 会采取强硬路线吗？

更新

这是堆使用情况和主要 GC 收集的最后 12 小时图片(绿点)，3:00AM 到 7:00AM 之间的 GC 非常高，但是当我在 左右重新启动应用程序时>7:30AM 一切都很好，应用程序响应时间非常快，为什么重启会修复所有问题？

欢呼! 4GB Heap解决问题

4GB(零主要 GC)后每分钟花费的主要 GC 收集时间(毫秒)

4GB 堆后 CMS Old Gen 使用量(以 MB 为单位)

4GB 堆后以 MB 为单位的 Eden 空间

Answer 1

每分钟一次主要 GC 看起来一点也不麻烦。通常它需要大约半秒的时间，所以这是您总体 CPU 使用率的 1/120。繁重的应用程序负载会导致更多的内存分配，这也是很自然的。显然，您正在分配一些存在一段时间的对象(可能是缓存)。

我的结论:所展示的 GC 行为并不能证明您的应用程序的内存分配存在问题。

更新

我已经更仔细地查看了您的图表(不幸的是，它们很难阅读)。您没有每分钟一次 GC；每分钟有 60 秒 的主要 GC，这意味着它一直在发生。那确实看起来像个大麻烦；事实上，在这些情况下，由于“超过 GC 时间百分比阈值”，您通常会得到 OOME。请注意，您使用的 CMS 收集器实际上比默认收集器慢；它的优点只是它不会“停止世界”。它可能不是您的最佳选择。但是您确实希望有内存泄漏或程序设计中的一般问题。