Java HotSpot 1.6 VM,垃圾收集 - 可怕的 PermGen

发布于 2024-09-01 01:50:19 字数 1188 浏览 8 评论 0原文

我的应用程序显示“老一代”/“终身一代”大小不断增加,当达到“老一代”的最大限制时,PermGen 大小突然增加。 以下是我的生成大小:

-Xmx1200m -Xms1200m -Xmn450m -XX:MaxPermSize=600m -XX:+UseParallelGC

这是在 32 位 Fedora 上,因此不能有比这更大的堆。

该应用程序没有执行任何花哨的类加载,尽管它使用 Spring IOC 和 Hibernate,Spring App-context.xml 定义了大约 1000 个 Bean。

该应用程序以 175MB PermGen 开始,在几个小时内稳步增加到约 250MB,一直保持这种状态,直到 Tenured Generation 达到约 780 MB,然后 permgen 跃升至约 500MB,而 Old Gen 下降到约 500MB。

这迫使我每天重新启动应用程序,并让我真正害怕迫在眉睫的内存不足错误。任何见解都会非常有帮助。

谢谢 Gala101

13/May:有人可以解释一下当“老一代”被垃圾收集时会发生什么吗?
jvm 是否将“Old Gen”中的集合放入 PermGen 中?
我的 PermGen 峰值仅在从“Old Gen”进行收集时出现,而且 OldGen 大小的减少与 PermGen 大小的增加紧密匹配。
PS:我不进行任何实时部署/取消部署,因为这肯定会耗尽 PermGen。
下面是我的监控页面的当前快照:(提交的部分刚刚从 ~250 MB 跃升至 500 MB)

    PS Perm Gen
Type    Non-heap memory
Usage   init = 16777216(16384K) used = 254453736(248489K) committed = 504954880(493120K) max = 629145600(614400K)
Peak Usage  init = 16777216(16384K) used = 254453736(248489K) committed = 504954880(493120K) max = 629145600(614400K)
Collection Usage    init = 16777216(16384K) used = 252421536(246505K) committed = 504954880(493120K) max = 629145600(614400K)

My app shows rising 'Old Generation'/'Tenured Generation' size, and when this reaches the max limit for 'Old Gen', then suddenly PermGen size increases.
Here are my generation sizings:

-Xmx1200m -Xms1200m -Xmn450m -XX:MaxPermSize=600m -XX:+UseParallelGC

This is on 32 bit Fedora so can't have a bigger heap than this.

The app is not doing any fancy classloading, though it is using Spring IOC and Hibernate, the Spring App-context.xml defines some 1000 Beans.

This app starts with 175MB PermGen, which steadily increases to ~250MB in few hrs, stays that way till Tenured Generation reached ~780 MB, then permgen jumps to ~500MB while Old Gen drops to ~500MB.

This forces me to restart the App on daily basis, and gives me real scare of looming OutOfMemory Error.. Any insights would be very helpful.

Thanks
Gala101

13/May: Could someone please throw light on what happens when 'Old Gen' is garbage collected?
Does the jvm put collections from 'Old Gen' into PermGen?
My PermGen spike comes only when collection happens from 'Old Gen', also decrease in OldGen size closely matches increase in PermGen size.
PS: I don't do any live deploy/undeploy as that's sure to eat up PermGen.
Below is a current spanshot from my monitoring page: (the committed part had just jumped from ~250 MB to 500 MB)

    PS Perm Gen
Type    Non-heap memory
Usage   init = 16777216(16384K) used = 254453736(248489K) committed = 504954880(493120K) max = 629145600(614400K)
Peak Usage  init = 16777216(16384K) used = 254453736(248489K) committed = 504954880(493120K) max = 629145600(614400K)
Collection Usage    init = 16777216(16384K) used = 252421536(246505K) committed = 504954880(493120K) max = 629145600(614400K)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

压抑⊿情绪 2024-09-08 01:50:19

我会按照 leonm 的建议来分析什么占用了这么多内存。我敢打赌你有某种令人讨厌的内存泄漏。

你说你不做任何花哨的类加载,但 Hibernate 会为你动态生成一些类。
您是否使用一些 AOP 功能(例如来自 Spring AOP 模块?)。

基本上,如果您用完了 PermGen 空间,那么您的应用程序似乎会继续生成新类(因为它的类存储在 PermGen 中)。

I would follow leonm's advice to analyze what takes so much memory. I bet you have some kind of nasty memory leak.

You say you don't do any fancy classloading, but Hibernate generates some classes on the fly for you.
Do you use some AOP features (e.g. from Spring AOP module?).

Basically, if you are running out of PermGen space, then it seems like your application keeps on producing new classes (because it's classes which are stored in PermGen).

雨巷深深 2024-09-08 01:50:19

在重新启动服务器之前使用 jmap 进行内存转储并使用 Eclipse MAT 进行分析

Use jmap to do a memory dump before you restart your server and analyze with Eclipse MAT

缱绻入梦 2024-09-08 01:50:19

如果您继续在应用程序服务器上部署/取消部署应用程序,Permgen 就会泄漏。

检查此链接以获取更多说明这不是应用程序服务器的错误。

http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java

Permgen gets leaked if you keep deploying/undeploying apps on the appserver.

Check this link for some more explaination how this is not the appserver's fault.

http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文