Java Memory Management

Establishing Java Virtual Memory Settings

Your application server provides options to establish the amount of memory set aside for the Java virtual machine; that is, the amount of memory that the Java environment itself manages in order to run the application server itself and the ARCHIBUS Web Central application.

For instance, with Tomcat, you can use the Start/Apache Tomcat 5.0/Configure Tomcat option, select the "Java VM" tab, and at the end of the "Java Options" preference append the memory switches for the Java virtual machine. If you are using Jetty, the memory switches used when running as a console are specified in c:\Program Files\archibus\xx\SmartClient\SmartClient.Common.dll.config and when running as a service they are specified in the initmemory and maxmemory preferences in \WEB-INF\config\jetty-service.conf.

Common Switches

The two most common switches to use are "-Xms" and "-Xmx":

-Xms512m. Sets the minimum heap size allocated to the given value, in this example 512 MB.
-Xmx1g. Sets the maximum heap size allocated to the given value, in this example 1 GB. Otherwise the memory grows as needed. Do not set this value near or greater than the available memory, as then the system will begin to use virtual paging unnecessarily as the operating system and the Java environment compete to manage the same memory.

Some guidelines for using these switches are:

Set both values to the same figure (e.g. "-Xms512m -Xmx512m"). This practice speeds load times.
Use a minimum value of 256MB (i.e. "-Xms256m -Xmx256m") even for light duty or demonstration installations. If you get "out of memory" errors after loading a large number of views, you most likely have not set these minimums.
On dedicated application servers -- that is, on computers not also tasked to run the database server or other tasks -- dedicate 70% of the memory in the machine to the Java environment.
On production computers with mixed responsibilities, use a minimum value of 512MB (i.e., "-Xms512m -Xmx512m"). The logging messages product will warn you on startup if the available Java memory is less than 400MB.

Scalability Recommendations

If you have a large number of users, maximize the amount of memory effectively available for each instance of your application server.
If you have more than 4 GB of memory, split it between multiple instances of the application server running in the same operating system instance or within multiple virtual machines. Over 4 GB, garbage collection for each instance starts to become a dominant consumer of CPU resources.
If you have hundreds of concurrent users, budget time to tune garbage collection for your particular stack. Best results will vary with hardware, application server, JDK version -- and of course the volume and type of requests from your enterprise users.
Unless you have identified specific target-user profiles that dominate your server load, garbage collection configurations simple. ARCHIBUS users have wide-ranging demands on the server -- from interactive reports to queries supporting CAD and BIM users to server-side document creation and storage -- and optimizing for one task tends to degrade others. In general, the standard Java garbage collection algorithms do a good job of balancing memory use for the needs of the moment.
On multi-processor machines, benchmarks on thousands of concurrent users have shown good results with these Java options:

SET JAVA_OPTS=-Xmx4000m -Xms4000m -XX:+AggressiveOpts -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=16 –server

These benchmarks found best results using mark and sweep for long-lived (old generation) objects and parallel GC for short-lived (new-generation or Eden space) objects. This recommendation is consistent with Sun’s recommendation for obtaining minimum user delay. An exception is smaller servers, such as 2-core servers, often do better with the parallel collection for long-lived objects rather than with the mark-and-sweep collection. And single-processor servers do not benefit from parallel garbage collection.