我们在高峰时间遇到严重的应用程序问题,应用程序变得非常非常慢,当我检查 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 空间
最佳答案
每分钟一次主要 GC 看起来一点也不麻烦。通常它需要大约半秒的时间,所以这是您总体 CPU 使用率的 1/120。繁重的应用程序负载会导致更多的内存分配,这也是很自然的。显然,您正在分配一些存在一段时间的对象(可能是缓存)。
我的结论:所展示的 GC 行为并不能证明您的应用程序的内存分配存在问题。
更新
我已经更仔细地查看了您的图表(不幸的是,它们很难阅读)。您没有每分钟一次 GC;每分钟有 60 秒 的主要 GC,这意味着它一直在发生。那确实看起来像个大麻烦;事实上,在这些情况下,由于“超过 GC 时间百分比阈值”,您通常会得到 OOME。请注意,您使用的 CMS 收集器实际上比默认收集器慢;它的优点只是它不会“停止世界”。它可能不是您的最佳选择。但是您确实希望有内存泄漏或程序设计中的一般问题。
关于Java 应用程序因堆而变慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18276208/