In the catalina.sh of Tomcat, a number of parameters are set through the JAVA_OPTS setting. This section gives an explanation on those parameters. For specific environments, these values of the parameters can be tailored to the corresponding requirements. For a full description of the Java virtual machine (JVM) options see http://java.sun.com/javase/technologies/hotspot/JVMoptions.jsp.
In This Section
General Parameters
-server
The client system is optimal for applications which require fast startup times and/or small footprints. The server system is optimal for applications where the overall performance is most important. Since startup is less important to XperienCentral than overall performance, the server system should be used.
-Duser.language=en and -Duser.country=US
These two options set the locale of the JVM and are mostly used to avoid problems while running on the Oracle database. The Oracle server is mostly installed with the en_US locale. If the JVM (in which XperienCentral is running) communicates with the Oracle server, it uses by default the locale of the operating system. If that locale is set to, for example, nl_NL, then problems might arise with date formats. To avoid any issues it’s best to set the locale of the JVM to en_US and install the Oracle server with that locale too.
–Xmx1024m
This option sets the maximum heap size for the Java virtual machine. XperienCentral uses memory for caching content from the database. A low value for this option can cause excessive garbage collection overhead and a lot database accesses. This option should be tuned based on the performance requirements of the application like number of concurrent users and the size of the content. If more memory is assigned to XperienCentral, more content can be cached in memory and the overhead of database access can be avoided.
Assigning more memory to the JVM will generally improve the performance. However, (excessive) swapping should be avoided as much as possible. Another drawback of a large heap is the fact that a full garbage collection will take more time. If the garbage collector uses a stop-the-world garbage collection policy, XperienCentral will be unresponsive for a longer period of time.
–Xms512m
Setting the minimum heap size can improve startup time.
-Djava.awt.headless=true
This option should be set to make sure the server is able to manipulated images without the presence of a display.
-Dsun.net.inetaddr.ttl=300
This option determines the number of seconds that the result of a hostname lookup should be cached in the JVM. The default behavior of the JVM is to cache it until a restart. This, however, is not desirable on a production environment. By adding this parameter with the value 300, the result of the hostname lookups stay cached for 5 minutes.
-Dorg.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false"
This system property disables Tomcat JSP custom tags pooling which can cause memory leaks in XperienCentral.
–Dwebmanager.clustering.id=x
This system property uniquely identifies an XperienCentral server in a clustered environment.
–Dwebmanager.clustering.readonly
This system property specifies that this XperienCentral server in a clustered environment does not have write access to the filestore.
–Dwebmanager.clustering.filestore=
This system property specifies whether the XperienCentral servers in a clustered environment use the custom XperienCentral filestore to synchronize files between them.
–Dwebmanager.clustering.scanner.interval
This system property controls how often uncontrolled files in a clustered environment are synchronized. The interval is in milliseconds.
-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
This command specifies the TransformerFactory implementation to use. This command must be implemented.
-Djava.net.preferIPv4Stack=true
If IPv6 is available on the operating system, the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect too, and accept connections from both IPv4 andIPv6 hosts. If an application has a preference to only use IPv4 sockets, then this property can be set to true. The implication is that the application will not be able to communicate with IPv6 hosts.
-Dorg.jackrabbit.repositoryfile
This system property should contain an absolute path to the repository.xml file when used. This makes it possible to place the repository.xml and accompanying repository-1.5.dtd files in a location other than work/jcr.
-Dwebmanager.configuration.startup
This system property should contain an absolute path to the startup_config.xml file when used. This makes it possible to remove the startup_config.xml file from the backend .WAR and place it in a user-defined location on the file system.
-Dwebmanager.configuration.initial
This system property should contain an absolute path to the config.xml file when used. This makes it possible to remove the config.xml file from the backend .WAR and place it in a user-defined location on the file system.
Garbage Collector Parameters
The garbage collection algorithm should be tuned to the characteristics of the XperienCentral application. XperienCentral caches content in memory. The content is stored in the tenured space. Cleaning up this tenured space would usually require a full garbage collect. Long garbage collection pauses should be avoided as much as possible. A long pause does not only make the site unresponsive but it also causes clients to send duplicate requests and causes a build-up of open requests on the server.
Stop-the-world pauses can be minimized by using the concurrent mark sweep collector. It performs most garbage collection activity concurrently, While the application threads are running it keeps garbage collection-induced pauses short. This is especially useful if there are unused processors available on the server. A slight drawback of this collector is that garbage collection uses some more CPU instructions.
-XX:+UseConcMarkSweepGC
The concurrent mark sweep collector should be activated using the command-line option -XX:+UseConcMarkSweepGC.
This option cannot be used together with the option -XX:+UseParNewGC.
-XX:+UseParNewGC
The new generations can be collected in parallel.
This option cannot be used together with the option -XX:+UseConcMarkSweepGC.
-verbose:gc
The overhead of the garbage collector can be measured and logged by setting the JVM option -verbose:gc. The duration of the garbage collections are logged in the Tomcat catalina.out. If the overhead becomes a problem, this log can be used for analyzing and tuning the garbage collector.
-Dsun.rmi.dgc.client.gcInterval=600000
The content ofXperienCentralis indexed by the XperienCentral search engine. This search engine is a separate application which runs in its own virtual machine. RMI is used as the protocol for communication between the XperienCentral server and the search engine.
RMI forces periodical full garbage collections in order to make sure all objects in the distributed environment can be freed. The default interval for this is one minute, which leads to a stop-the-world full garbage collect every minute. This creates detrimental performance issues especially for large heaps.
Setting this interval to ten minutes will not cause any problems because the number of RMI calls and the corresponding garbage is limited. If the full garbage collects still cause problems, this value could be changed to one hour (3600000).
-XX:+HeapDumpOnOutOfMemoryError
If an XperienCentral application in some cases throws an OutOfMemoryError and profiling locally doesn’t solve the problem, the JVM can be instructed to dump the contents of the heap to disk for analysis. This option should not be turned on by default on production environments because dumping the heap is stop-the-world and may take a long period of time.
-XX:-ReduceInitialCardMarks
A flaw in the implementation of a card-marking performance optimization in the JVM can cause heap corruption under some circumstances. This issue affects the CMS garbage collector prior to 6u18, and the CMS, G1 and Parallel Garbage Collectors in 6u18. The serial garbage collector is not affected. Applications most likely to be affected by this issue are those that allocate very large objects which would not normally fit in Eden or those that make extensive use of JNI Critical Sections (JNI Get/Release*Critical).