WebLogic is a very stable application server platform used for deploying Java applications. However, there may come a time when your WebLogic server may encounter memory issues. When troubleshooting OutOfMemoryErrors in WebLogic, there are some important key points to keep in mind. One part of JVM memory is heap where the other part consists of permanent space. As we do not recall seeing OutOfMemoryErrors pertaining to PermGen, we would not change anything with this unless directed otherwise. We would also ignore -XX:NewRatio (this is another version of –Xmn as it is the ratio between the young generation and the old generation heap except in a ratio format) as well as –XX:PermSize and –XX:MaxPermSize (these parameters are for managing the permanent space in JVM memory) initially.
Troubleshooting Tips:
We are in favor of trying out -XX:+UseG1GC (the Garbage-First or G1 garbage collector) as documented in these articles:
- https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection
- http://docs.oracle.com/javase/7/docs/technotes/guides/vm/G1.html.
The G1 garbage collector is supposed to achieve high performance and pause time goals. It has been supported since JDK 7. Oracle recommends using G1 when:
- Applications are using very large heaps to avoid running out of memory (especially 6 GB of heap or larger)
- More than 50% of the Java heap is being filled with live data
- The rate of object allocation rate varies significantly
- There is a very long garbage collection or compaction pauses longer than a second
Also, Oracle is currently planning to replace the existing garbage collector, Concurrent Mark-Sweep Collector (CMS), with G1.
If you use the G1 garbage collector, it will be important to set the parameter, -XX:InitiatingHeapOccupancyPercent=##, which also controls when garbage collection takes place as noted in Oracle Support note 1677981.1. We would test with having the value set to 55. Additionally, we would also use the –XX:MaxGCPauseMillis argument which is the pause time goal. This parameter, in milliseconds, is the pause time. We have seen this set to 200 milliseconds, so you could try configuring this and adjust as accordingly. You may also use -XX:MaxTenuringThreshold if you like which is another garbage collector tuning parameter specifying how many minor GC cycles an object will stay in “survivor spaces”. We recommend to only set this between 0 and 15 (one of PITSS’ customers used 10). It is advised to not set it greater than 15. If you go ahead with the G1 garbage collector, you can ignore the arguments “-XX:ParallelGCThreads” and “-XX:ConcGCThreads”.
In general, other reasons why the OutOfMemoryError messages are occurring even with the message “GC overhead limit exceeded” can be due to (as documented in http://www.jvmhost.com/articles/what-is-java-lang-outofmemoryerror-gc-overhead-limit-exceeded):
- Optimize the application to use less memory and/or reuse objects instead of creating new ones. This will reduce how often the garbage collector runs. Try reusing objects if a lot of temporary objects are created.
- Increase the JVM heap.
- Do not use -XX:-UseGCOverheadLimit. Although the “GC overhead limit exceeded” errors will disappear, they will be replaced by heap-related OutOfMemoryError messages.
When troubleshooting OutOfMemoryErrors in WebLogic, you can also test the JVM by debugging the garbage collector and the JVM. If you set these logging JVM parameters, -verbose:gc, -XX:+PrintGCDetails, and -XX:+PrintGCTimeStamps, you can check to see if a full garbage collection is done before the OutOfMemoryError appears. If the GC fails to complete before the error happens, it may be a JVM bug. Also, make sure the JVM does proper compaction work and the memory is not fragmented. If the JVM does its work properly, the error may be application-related. Oracle Support note 877172.1 in the “For Java OOM” section contains more information on this.
