This content has been marked as final. Show 8 replies
Default value of MaxPermSize in WLS 10.3.2.0 is -XX:MaxPermSize=128m
Following are few things which would help you in deciding what values should be given for the memory arguments.
- It is recommended to keep the max-heap (Xmx) and min-heap(Xms) size to the same values.
- MaxPermSize(XX:MaxPermSize) is also recommended to be 1/4 of the max-heap size, however in some special cases you have to use 1/3 of the max-heap size.
However it would be better if you keep your Xmx and Xms value as 1024 which is a stable value, thus the memory arguments would be
-Xmx1024m -Xms1024m -XX:MaxPermSize256m
BUT to keep in mind that these values is depends on the environment
Hope this helps you.
Yes, you are right WLS documentation dose not clearly states that you should keep max-heap or for any other memory arguments with a particular values as these values are totally depended on the end to end environments and their requirements.
However if you would like to make a confirmation on suggestion I gave you can even open a ticket with WLS support team as well.
Hope this information helps you and also do let me know if you need anything else on this issue will try to help you out.
Keep posting :)
Thank you very much Ravish for your quick response.
The documentation for JVM Tuning does recommend that -Xms should be equal to -Xmx to minimize garbage collections. (http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/JVMTuning.html)
However I was unable to find where it is recommended to set MaxPermSize to be 1/4 of Max heapsize.
Can you kindly point me to the documentation where this is stated?
Mitesh, perhaps trying to profile the application at the moment it throws the OOM could shed more light on the actual cause of the error.
This is much easier with JRockit, using the oomdiagnostics flag, which prints a thread dump and a heap profile at the time the OOM occurs.
With Sun JVM I am not sure....
you could try activating some -verbose:class flag to trace what is going on.... I am not sure if a alloclargeobjectorarray
can actually refer to a class being loaded by the classloader - only in this case it would make sense to increase the PermSpace.
But, definitely, being able to have a thread dump at the moment the OOM error occurs would be of great help.
Perhaps inside WLDF you can define a trap for this condition. Try also JConsole, but I think it's not as powerful as jrmc. JRockit excels when it comes to diagnostics.
java.lang.OutOfMemoryError: allocLargeObjectOrArray is due to the TLA size.
You will have to tune it.
Set the following parameters
You should also consider analyzing the heap size.
Follow the link
We were getting java.lang.OutOfMemoryError every few days in our production environment. Please find below the logs of the managed server which went out of memory.
We are using Weblogic 8.1.4 in the production environment.
Also, i could see that the memory parameter being set as -Xms96m -Xmx256m in the startManagedWebLogic.cmd file. There is another memory parameter that is being configured in the Admin console, in the Configuration section, under Remote Start, there is a field called Arguments which is set as "-Xms1792m -Xmx1792m - Dlog4j.configuration=file:D:\UAN_Home\Log4JConfig\LogCfg4hipad21.xml" and the description below this field is "The arguments to use when starting this server" (Node Manager is a stand-alone Java program provided with WebLogic Server that you can use to start, restart, monitor, and shut down Managed servers in normal or unexpected conditions. This page allows you to configure the startup settings that Node Manager will use to start this server on a remote machine.)
Could you help me is that possible to reconfigure the start up memory settings to XX:MaxPermSize. Will it resolve my problem.
I will be eagerly waiting for you reply, because this is production environment and i need to resolve this issue ASAP.
####<05.jan.2012 kl 10.54 CET> <Error> <T3Misc> <HIPD144APP21> <intHipd144app21> <weblogic.time.TimeEventGenerator> <<WLS Kernel>> <> <BEA-000712> <Exception invoking Scheduled Trigger
####<05.jan.2012 kl 10.54 CET> <Alert> <JMS> <HIPD144APP21> <intHipd144app21> <ExecuteThread: '9' for queue: 'BatchExecuteQueue'> <<anonymous>> <> <BEA-040059> <JMSServer "cgJMSServer_auto_1". Unhandled exception occurred during commit, java.lang.OutOfMemoryError.
####<05.jan.2012 kl 10.55 CET> <Info> <WLI-Core> <HIPD144APP21> <intHipd144app21> <ExecuteThread: '1' for queue: 'BatchExecuteQueue'> <<anonymous>> <BEA1-4AAD2BBA2BCA5230BF87> <BEA-489044> <ProcessControl invocation failed
java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size: 32784, Num elements: 32768 [ServiceException]
####<05.jan.2012 kl 10.55 CET> <Info> <JDBC> <HIPD144APP21> <intHipd144app21> <Thread-17> <<WLS Kernel>> <> <BEA-001128> <Connection for pool "UANErrorHandlingConnectionPool" closed.>
####<05.jan.2012 kl 10.55 CET> <Alert> <JMS> <HIPD144APP21> <intHipd144app21> <ExecuteThread: '3' for queue: 'BatchExecuteQueue'> <<anonymous>> <> <BEA-040059> <JMSServer "cgJMSServer_auto_1". Unhandled exception occurred during commit, java.lang.OutOfMemoryError.
####<05.jan.2012 kl 10.55 CET> <Notice> <Security> <HIPD144APP21> <intHipd144app21> <Thread-6> <<WLS Kernel>> <> <BEA-090170> <Loading the private key stored under the alias DemoIdentity from the jks keystore file C:\bea_8_1_4\weblogic81\server\lib\DemoIdentity.jks.>
####<05.jan.2012 kl 10.55 CET> <Alert> <JMS> <HIPD144APP21> <intHipd144app21> <ExecuteThread: '8' for queue: 'BatchExecuteQueue'> <<anonymous>> <> <BEA-040059> <JMSServer "cgJMSServer_auto_1". Unhandled exception occurred during commit, java.lang.OutOfMemoryError: nativeGetNewTLA.
####<05.jan.2012 kl 11.22 CET> <Warning> <Socket> <HIPD144APP21> <intHipd144app21> <ListenThread.Default> <<WLS Kernel>> <> <BEA-000402> <There are: 9 active sockets, but the maximum number of socket reader threads allowed by the configuration is: 8. You may want to alter your configuration.>