Database Reference
In-Depth Information
-Xms and -Xmx
These are the minimum heap size (-Xms) and maximum heap size (-Xmx) .
We recommend setting both of these to the same value as it prevents the JVM
from trying to expand the heap (effectively fixing the heap size), which improves
performance. For small environments, a value of 1536 MB tends to be accept-
able, for medium environments, a value of 4 GB is acceptable, and larger imple-
mentations should start at 6 GB, but can go up to 16 GB if needed.
Note that bigger is not always better. On a 64-bit operating system, even though
the memory addressing is much larger, if possible, set the maximum heap size
below 4 GB to take advantage of JRockit's compressed references to reduce
memory usage. The size of the heap you require will depend on multiple factors:
The number of SOA composites deployed to the server.
The number of MDS artifacts referenced in your code. When an SOA com-
posite imports a schema from the MDS (for example, oramds:/apps/
CustomMetaData/schema/HelloWorld.xsd) , this is automatically
loaded into memory. The more artifacts from the MDS that are referenced by
your code, the more memory is going to be required to store them.
A general rule of thumb is to consider that for every 100 MB of MDS artifacts
referenced in the deployed SOA composites, increase your JVM by 1 GB. This
is sometimes very difficult to calculate, so consider basing your estimates on
the entire size of the artifacts in the MDS. Use the ant command described
in Chapter 2 , Management of SOA Composite Applications , to export the entire
contents of the MDS and get an estimate on the sizing after extracting its con-
tents.
-Xgcprio:throughput
This uses the default dynamic garbage collection mode, which, in JRockit JVM
R27.3.0 and later versions, is optimized for throughput and will dynamically set
the nursery size to an approximate optimal value. Thus, there is no need to
manually set the nursery size (via the -Xns argument) in most cases.
Search WWH ::




Custom Search