All geek questions in one place

PermGen For memory reasons

I constantly discover OOM in PermGen for my environment:

  • java 6
  • JBoss-4.2.3
  • Not a great web application

I know about String.intern (), but I miss its useful use. The increase in the size of MaxPermGen did not bring strength (from 128 MB to 256 MB).

What other reasons can cause OOM for PermGen? What is the best research scenario in such a situation (strategy, tools, etc.)?

Thanks for any help

+6
source share
2 answers

See note

  • Put the JDBC driver in the general / lib (as the tomcat documentation says), and not in WEB-INF / lib
  • Do not put commons-logging in WEB-INF / lib as tomcat already loads it

objects of the new class fall into PermGen and thereby occupy an increasing amount of space. No matter how big you occupy the PermGen space, it will inevitably end after enough deployment. What you need to do is take steps to clean PermGen so that you can stabilize its size. There are two JVM flags that handle this cleanup:

-XX:+CMSPermGenSweepingEnabled

This option enables PermGen in the start of the garbage collection. By default, PermGen space is never included in garbage collection (and thus grows without restriction).

 -XX:+CMSClassUnloadingEnabled

This parameter tells the PermGen swing garbage collection to take action on class objects. By default, class objects are freed even when PermGen space is visited during a garabet collection.

+13
source

Usually you get this error when redistributing the application when there is a class> leak , because it means that all your classes are loading again, while the old versions remain.

There are two solutions:

  • Restart the application server instead of redeploying the application - light but annoying
  • Investigate and repair leaks with a profiler. Unfortunately, class loader leaks can be very difficult to detect.
+8
source

Source: https://habr.com/ru/post/885727/

More articles:


All Articles