Some basic guidelines for setting the J2EE Application Server JVM memory

Please refer to WDK/Webtop deployment guide (version 6.5 sp1/sp2) and the recommended parameters should be applicable to WDK-based application versions 5.3x and 6.x.
Note see the section on "Setting the Java memory allocation" for full details and keep in mind the heap settings are specific to Sun JDK.   You might also search this pdf for 'maxperm' to find this section.
For IBM SDK (IBM WAS 6.x): refer IBM for equivalents.  Also see IBM "Tuning Java virtual machines" - http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tprf_tunejvm_v61.html

See related Solution esg104146 for thread sizing
-----------------------
Common Application Server heap settings (paraphrased from WDK/Webtop deployment guide):
-server
-XX:+UseParallelOldGC    (NOTE: per Sun, this only applies to Sun Java 1.5.0_06 and later.)
-XX:MaxPermSize=128m
Document caching can consume at least 80 MB of memory. User session caching can consume approximately 2.5 MB to 3 MB per user.   Fifty connected users can consume over 200 MB of VM memory on the application server. Increase the values to meet the demands of the expected user load.

Some additional heap and heap related parameters to consider researching:
-XX:PermSize=64m 
This sets the starting size for the permanent generation while -XX:MaxPermSize= sets the maximum size

-XX:MaxPermSize=128m
Per Sun, this space is reserved for class metadata and interned strings about classes that have been loaded/created.  Many applications servers will already apply this permanent generation setting.  Tomcat is an exception and you must set your own values.  Consider 128m-512m, or roughly up to 1/4  of xmx setting and size as needed.  The more WDK-based applications you have in the JVM, it's likely the more permanent generation space you need to set.

-Xloggc:<file.log> -XX:+PrintGCDetails
Sun Java 1.4.2 and later.  Option logs each garbage-collection event in the specified location & .log file.  Also simplifies review and montoring heap usage, as well as parsing via external tool.  For more information, perform an internet search.  For many more details, consider an internet search against: xloggc review.  If you are considering JVM heap tuning, unfortunately this type of tuning is beyond the scope of standard support and you will need to reach out to EMC Professional Services for assistance here.

For JVM syntax and details on JAVA_OPTS, please check with Oracle/Sun.  Following are suggested links to start with:
- "Java HotSpot VM Options" http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
- A Collection of JVM Options  http://blogs.sun.com/watt/resource/jvm-options-list.html

Java Method Server (JMS) example for CS 65x (JBoss):
    set USER_MEM_ARGS=-Xms1024m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m -Xss256k -XX:+DisableExplicitGC -Xrs
  -----
NOTES:
- Per java.sun.com, Java 5.0 (1.5.0_xx) release has many improvements over the earlier Java 4.0 version.  Such as improved garbage collection, which will add to application server stability.  Please refer to Oracle/java.sun.com for further details.
- Tomcat 5.x and higher installers on will look for and prefers a JRE.  This will imply that Tomcat runs in a '-client' mode which is the default Sun Java egonomics mode on the Windows platform.  The complex WDK-based applications benefit from running in '-server' mode.  To check for '-server' mode for Tomcat/Windows service, check the registry:
  [HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Procrun 2.0\Tomcat5\Parameters\Java]
  "Jvm"="C:\\jdk1.5.0_08\\jre\\bin\\server\\jvm.dll"
  If you instead see <jdk>\\jre\\bin\\client\\jvm.dll", this implies it's running 'client' mode and are utilizing Tomcat's bundled Eclipse compiler.  For client mode, this is along the lines of browser side JRE running applets.


-----------------------
NOTE: Following is LEGACY, 5.2x related details and may not be appropriate for 5.3x and D6 application deployments.

J2EE Memory Allocation

If the memory allocated to the J2EE server Java virtual machine (VM) is not correctly set, the VM will spend a lot of time destroying objects, garbage collecting, and creating new objects. To change the memory allocation, use a setting similar to the following in the Java arguments set in the J2EE server start script. Following are the locations for the file setting the Application Server memory allocation for BEA WebLogic (1) and Tomcat (2).:

Startup scripts to modify for some of the application servers:

=================================

1/ BEA:

J2EE server start script file:

- Unix: $BEA/user_projects/.../startDocumentum.sh

- Windows: $BEA/user_projects/.../startDocumentum.cmd

Look for the line that sets the MEM_ARGS variable. Following is an example of the default settings in BEA:

set MEM_ARGS -Xms256m -Xmx256m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=14 -verbose:gc

Note if BEA is set to run as a Windows service, update the service parameters in the registry. If you make any registry changes, be certain to have a current backup of that machine before making any changes. Following is an example of the registry settings:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\beasvc dadomain_daserver\Parameters]

"CmdLine"="-server -Xms256m -Xmx256m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=14 -verbose:gc \"-Dda52.war=C:\\bea\\user_projects\\dadomain\\applications\\da52.war\" -classpath \"C:\\Program Files\\Documentum\\shared\\dfc.jar;C:\\Program Files\\Documentum\\shared\\bsf.jar;C:\\Program Files\\Documentum\\shared\\log4j.jar;C:\\Program Files\\Documentum\\shared\\xalan.jar;C:\\Program Files\\Documentum\\shared\\xml-apis.jar;C:\\Program Files\\Documentum\\shared\\workflow.jar;C:\\Program Files\\Documentum\\shared\\subscription.jar;C:\\Program Files\\Documentum\\shared\\admin.jar;C:\\bea\\jdk131_06\\lib\\tools.jar;C:\\bea\\weblogic700\\server\\lib\\weblogic_sp.jar;C:\\bea\\weblogic700\\server\\lib\\weblogic.jar;C:\\Program Files\\Documentum\\dctm.jar;C:\\Documentum\\config;C:\\bea\\user_projects\\dadomain\\applications\\da52-config\" \"-Dweblogic.Name=daserver\" \"-Dbea.home=C:\\bea\" \"-Dweblogic.management.username=dmadmin\" \"-Dweblogic.ProductionModeEnabled=\" \"-Djava.library.path=C:\\Program Files\\Documentum\\shared\" \"-Djava.security.policy=C:\\bea\\weblogic700\\server\\lib\\weblogic.policy\" weblogic.Server"

=================================

2/ Tomcat:

- Unix: $Tomcat/bin/catalina.sh

- Windows: $Tomcat/bin/catalina.bat

For example with Tomcat, if you check the catalina.bat startup file you should see something like the following for the Memory settings:

set CATALINA_OPTS=%CATALINA_OPTS% -Djava.library.path="C:\Program Files\Documentum\shared" -Xms256m -Xmx256m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=14 -verbose:gc

=================================

Additional information on the memory allocation variables and the values to set:

... -Xms256m -Xmx256m -XX:NewSize=64m -XX:MaxNewSize=64m

Where:

-Xms Starting heap size (default is 256m)

-Xmx Maximum Heap size (default is 256m)

-XX:NewSize Starting NewSize memory allocation (default is 64)

-XX:MaxNewSize Maximum NewSize allocation (default is 64)

-XX:SurvivorRatio Fraction of NewSize reserved for survivor (not GC) space (default is 14)

The typical defaults are mentioned above in parenthesis ().

NOTE: Expect to use 20+ MB per user, more if busy users. The resources used will also depend on the application session timeout on how the sessions will tie up resources. See Support Note 23351 for details on how to check or set the session timeout for a WDK-based application.

Ensure that MaxNewSize is around 20% of total memory and NewSize is about 20% of starting heap size. For most implementations, set -Xms = -Xmx, and NewSize=MaxNewSize, unless it is a very large implementation. This will allow the servers to spend less time growing and sizing the heap. For more information on these settings, see Sun documentation at the Sun Web site.

Memory usage by the Java process can be monitored with third party J2EE tools or simply using the OS tools. You can use the Windows task manager to compare with memory allocations and monitor the java.exe process that corresponds to the application server process. Likewise, on Unix, you can use similar tools. For Solaris, you can use 'top' if installed. If not installed, you may want to check The Freeware for Solaris web site http://sunfreeware.com/. Also check the link at the end of this support note for some related J2EE tools on the BEA web site page "Related Reading: Performance Tools and Information".

You can monitor Java garbage collection by setting the command -verbose:gc in the J2EE server start script. Increased Java memory settings will increase the amount of time before a major garbage collection takes and will also increase the amount of time that garbage collection takes to execute. Garbage collection is the greatest bottleneck in the application, and all application work pauses during garbage collection.

Garbage collection tracing has the following syntax:

[GC 776527K->544591K(1040384K), 0.4283872 secs]

The trace can be interpreted as follows:

1/ [GC 2/ 776527K-> 3/ 544591K( 4/ 1040384K), 5/ 0.4283872 secs]

1. GC indicates minor garbage collection event, Full GC indicates full garbage collection

2. Amount of total allocated memory at start of minor collection

3. Amount of total allocated memory at end of minor collection

4. Amount of total memory on host

5. Time in seconds to run garbage collection

Allocated memory as shown in consecutive GC traces continues to grow until full garbage collection occurs. Full garbage collection takes much longer than minor garbage collection, often on the order of 10 times as long.

The following describes some memory troubleshooting inferences that can be drawn from garbage collection.

Symptom Reason

Frequent full GC, starting point higher Total memory too small, or memory leak

after each full GC, decreasing number of

GC between full GC

Garbage collections take too long (GC 1 Too much memory allocated to JVM

sec, full GC 5 sec), server cannot create

new threads

Too many minor GC, high CPU usage NewSize allocation too small

No GC, terrible performance NewSize allocation too large

(>20% of total memory)

Please check the Application Server Vendor Web sites for more details on tuning and performance settings. Following are a few links:

BEA: WebLogic Server Performance and Tuning

81x http://edocs.bea.com/wls/docs81/perform/WLSTuning.html

70x http://edocs.bea.com/wls/docs70/perform/WLSTuning.html#1112119

Related Reading: Performance Tools and Information

70x http://edocs.bea.com/wls/docs70/perform/appa_reading.html#1027383

Note, much of the above information was compiled from page 54+ of the Web Development Kit Applications Configuration Guide Version 5.2 June 2003. Also see this guide for some thread management suggestions. For further details both on memory management and threads, please check the Application Server Vendor Web site.

For some Websphere specific info and how to set via the console, also see Support Note 25522 - How do I modify the Java Heap Size in Websphere used in WDK Applications?