Filter
Top Products
Parameter / Description Default Value
-server
HotSpot-based JVMs generally use
low optimization levels, which
takes less time to start up, but leads
to low runtime performance.
Normally, a simple JIT compiler is
used. To increase the runtime
performance for applications such
as Sterling B2B Integrator, an
optimizing compiler is
recommended. Using this method
may, however, lead a JVM to take
longer time to warm up.
For both noapp and container JVMs:
v Solaris = -server (optimizing compiler)
v HP-UX = -server (optimizing compiler)
-Xmx
If this parameter is tuned correctly,
it can:
v Reduce the overhead associated
with the garbage collection and
the risk of encountering an
Out-Of-Memory (OOM)
condition
v Improve the server response time
and throughput
If you see a large number of
garbage collections, try increasing
the value. You can set a maximum
heap limit of 4 GB for a 32-bit JVM.
However, due to various
constraints such as available swap,
kernel address space usage,
memory fragmentation, and VM
overhead, it is recommended to set
a lower value. In 32-bit Windows
systems, the maximum heap size
can be set in the range from 1.4 GB
to 1.6 GB. Similarly, on 32-bit
Solaris kernels, the address space is
limited to 2 GB. The maximum
heap size can be higher if your
64-bit operating system is running
32-bit JVM, reaching until 4 GB on
Solaris systems. Java SE 6 does not
support Windows /3GB boot.ini
feature. If you require a large heap
setting, you should use a 64-bit
JVM on an operating system
supporting 64-bit applications.
Refer to “Edit Performance Configuration Settings”
on page 123 for the default values for the:
v Maximum heap size for the server JVM
(MAX_HEAP)
v Maximum heap size for the container JVM
(MAX_HEAP_CONTAINER)
Performance Management 67