FAQ: OutOfMemory in WebLogic
From time to time I see questions like this:
Q: "We are seeing OutOfMemory error in the WebLogic log, after that our app becomes inaccessible. The application is not under heavy load. In fact, we can see it even if the server is idle. WebLogic performance console shows that there is plenty of heap available. What's wrong?".
A: Given the symptoms above, the most likely cause of the problem is that the default size of the heap allocated by JVM for long living objects is often too small for a J2EE application is general and for one under WebLogic in particular. Weblogic uses caching a lot, so if you've got many EJBs, there will be plenty of long living object, and they may not fit into perm heap.
To fix this problem, you need to increase MaxPermSize JVM parameter. Go to WebLogic startup script and add -XMaxPermSize=64m or -XMaxPermSize=128m to JVM startup parameters. If you don't have an application memory leak, this change should take care about the problem.
Q: But how do I know if it's not an app memory leak?
A: The first symptom of the app memory leak is that in addition to OutOfMemory, you will see that the memory graph in WebLogic performance console hits the top, and forcing ** *oesn't change anything. Fixing this problem is relatively easy. Get a good profiler tool, like OptimizeIt of JProfiler, and run a load test while memory profiling is enabled. Set up a filter to see only your classes and fined ones taking most of memory. It's likely that the same objects will have largest instance counts.
Tips for setting up a profiler.
First, set the JVM memory to as minimum as possible. If you expect WebLogic to run with 1Gb of JVM heap, set it to much lower values at which app can run. It can be 32M, 64M, depending on the app. Is sounds odd, but the reason is that the memory profiler catches JVM GC activities, and as there will be much more object in 1GB than in 64Mb, that GC under profiler will be dead slow, it can be hours, virtually. Set memory to as low as possible.
Second, turn off anything except the memory profiling. Memory profiling itself is slow, so you will want yo avoid any additional overhead in this case. Performance profiling is to be turned off in any case.
From time to time I see questions like this:
Q: "We are seeing OutOfMemory error in the WebLogic log, after that our app becomes inaccessible. The application is not under heavy load. In fact, we can see it even if the server is idle. WebLogic performance console shows that there is plenty of heap available. What's wrong?".
A: Given the symptoms above, the most likely cause of the problem is that the default size of the heap allocated by JVM for long living objects is often too small for a J2EE application is general and for one under WebLogic in particular. Weblogic uses caching a lot, so if you've got many EJBs, there will be plenty of long living object, and they may not fit into perm heap.
To fix this problem, you need to increase MaxPermSize JVM parameter. Go to WebLogic startup script and add -XMaxPermSize=64m or -XMaxPermSize=128m to JVM startup parameters. If you don't have an application memory leak, this change should take care about the problem.
Q: But how do I know if it's not an app memory leak?
A: The first symptom of the app memory leak is that in addition to OutOfMemory, you will see that the memory graph in WebLogic performance console hits the top, and forcing ** *oesn't change anything. Fixing this problem is relatively easy. Get a good profiler tool, like OptimizeIt of JProfiler, and run a load test while memory profiling is enabled. Set up a filter to see only your classes and fined ones taking most of memory. It's likely that the same objects will have largest instance counts.
Tips for setting up a profiler.
First, set the JVM memory to as minimum as possible. If you expect WebLogic to run with 1Gb of JVM heap, set it to much lower values at which app can run. It can be 32M, 64M, depending on the app. Is sounds odd, but the reason is that the memory profiler catches JVM GC activities, and as there will be much more object in 1GB than in 64Mb, that GC under profiler will be dead slow, it can be hours, virtually. Set memory to as low as possible.
Second, turn off anything except the memory profiling. Memory profiling itself is slow, so you will want yo avoid any additional overhead in this case. Performance profiling is to be turned off in any case.
扫一扫
6818
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
