Curious to how others might have their java memory configurations set on their Client/Web tiers.

For example, I have a 8-CPU, Windows 2008R2 Server with 24GB RAM with the following settings:

-XX:PermSize=512M
-XX:MaxPermSize=512M
Initial memory pool: 2146MB
Maximum memory pool: 4295MB
Thread stack size: null

Peak web sessions (via Tomcat Manager) are about 400 (avg = 250) in Production.

I'm thinking about testing this configuration:

-XX:PermSize=1024M
-XX:MaxPermSize=1024M
Initial memory pool: 3220MB
Maximum memory pool: 6441MB
Thread stack size: null

as we are experiencing incidents of not being able to create new sessions (Server's RAM was only at 25% utilization).

Thank you.

This message has been edited. Last edited by: <Kathryn Henning>,

Are you using 64bit Java? If not, consider moving to it.

Put a value for thread stack size. I usually do trial and error and start at 128. If I can't get the session to respond, then I double it to 256. 265 is usually way more than you should need, and it is much lower than the default.

Yes, we are currently on 64bit:

 
C:>java -D64 -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)
 

Thanks for the tip on Thread Stack - will look into that further and test.

I also found this doc:

https://techsupport.informatio...om/sps/81802512.html

which gives 1/8 and 1/4 total memory suggestions for "Initial memory pool" and "Maximum memory pool".

Settings currently being tested - to monitor the effects of these changes, I am using JConsole.exe in my PC's $JRE_HOME/bin.

Have to first enable JMX Monitoring requiring these changes to JAVA_OPS in Tomcat config by adding these lines:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false

Stop, clear work cache and restart Tomcat...