The architecture of the Sun-developed, HP-ported HotSpot Java™ virtual machine (JVM) has evolved differently
than the IBM-developed software development kit (SDK.) Its internal
structure, for young or old generation and permanent regions, arises
to primarily support generational garbage collection, as well as other
garbage collection modes as necessary.
Before you begin
Note: 這個主題參照一或多個應用程式伺服器日誌檔。
此外,在分散式和 IBM® i 系統上,另外也建議您可以配置伺服器來使用「高效能可延伸記載 (HPEL)」日誌和追蹤基礎架構,而不使用 SystemOut.log、SystemErr.log, trace.log 及 activity.log 檔案。HPEL 與原生 z/OS® 記載機能也可以一起使用。如果您使用 HPEL,則可以從伺服器設定檔 bin 目錄,利用 LogViewer 指令行工具來存取您所有的日誌和追蹤資訊。請參閱有關利用 HPEL 疑難排解應用程式的資訊,以取得更多使用 HPEL 的相關資訊。
- Determine the type of JVM on which your application server is
running.
Issue the java –fullversion command
from within your application server app_server_root/java/bin directory. In response to this command, the
application server writes information about the JVM, including the
JVM provider information, into the SystemOut.log file. If your application server is running on an IBM virtual
machine for Java, see the topicTuning
the IBM virtual machine for Java.
- Verify that the following statements are true for your system:
- The most recent supported version of the JVM is installed on your
system.
- The most recent service update is installed on your system. Almost
every new service level includes JVM performance improvements.
About this task
Tuning the Sun HotSpot JVM is an iterative process where
the JVM configuration is developed, data gathered, primarily from
verbosegc data, and then analyzed, and any configuration revisions
applied on the next cycle. Perform one or more of the following steps
if you need to tune your Sun HotSpot JVM.
Procedure
- Provide enough Java Heap Memory.
The Java heap memory is a reserved, contiguous set of addresses. The size
of the Java heap memory is the maximum size for which
the Java heap is configured. These addresses are
not available for other native or system memory demands, and are maintained
and managed only by the JVM because the Java heap is used for Java object storage for the lifetime
of that JVM.
When the JVM initializes, secures resources for
the Java heap are obtained according to the JVM
configuration settings. If insufficient memory is available, the JVM
initialization fails. If inadequate memory is configured in the Java heap, the system eventually fails with
an OutOfMemory report, that is typically preceded by significant garbage
collection activity, during which almost no Java processing occurs.
Sufficient consideration for the native
memory needs of other components of your process must be made to accommodate
running threads, storing data for I/O, and satisfying such requirements
as alignment, and page size.
The Sun HotSpot Java heap comprises two physically independent parts that you must take
into consideration when you specify maximum Java heap sizes:
- The permanent region, which is a combination of young and old
generation regions that are further (subdivided into eden, survivor
spaces, and tenured regions.
- The provision memory for the Java components of this system.
The -XX:MaxPermSize= and -Xmx (Maximum Java Heap size) parameters respectively configure the maximum size of
the permanent region, where the class code and related data are logically
presented as part of the old generation region but are kept physically
separate, and the maximum size of the main heap where Java objects and their data are stored either
in the young or old generation regions. Together the permanent region
and the main heap comprise the total Java heap. An allocation failure in either of these regions either represents
the inability to accommodate either all the application code or all
the application data, both of which are terminal conditions, that
can exhaust available storage, and cause an OutOfMemory error.
Consult these tuning parameters:
- -XX:MaxPermSize (Permanent region)
- -Xmx (Maximum Java Heap size)
- Disable explicit garbage collection to eliminate any unnecessary
or mistimed major garbage collection cycles that might be introduced
in software components of the system.
Consult the tuning
parameter -XX:+DisableExplicitGC.
避免困難: By default, the JVM unloads a class from memory whenever there
are no live instances of that class available. You can use the
-Xnoclassgc
argument to disable class garbage collection. However, the performance impact of class garbage
collection is typically minimal, and turning off class garbage collection in a Java Platform, Enterprise Edition
(Java EE)
based system, with its heavy use of application class loaders, might effectively create a memory
leak of class data, and cause the JVM to throw an Out-of-Memory Exception.
If you use the
-Xnoclassgc argument, whenever you have to redeploy an application, you
should always restart the application server to clear the classes and static data from the pervious
version of the application.
gotcha
If you use the -Xnoclassgc argument, whenever you have to redeploy an
application, you should always restart the application server to clear
the classes and static data from the pervious version of the application.
- Tune region sizes to optimize garbage collection action.
Any garbage collection tuning endeavour decisions should
be based on the behavior of the garbage collectors. You should identify
the correct garbage collection mode to suit the operational needs
of you application. You should also verify that you are meeting your
performance requirements, and are efficiently recycling enough memory
resources to consistently meet the demands of your application. Any
changes that you make to garbage collection parameter settings should
produce sufficiently different results and show benefits that are
derived from exploiting different regions of the HotSpot Java heap.
An unwise choice typically
lengthens the tuning process as the iterative tuning process needs
to be substantially repeated. Further sections present the two principal
choices, parallel throughput or concurrent low-pause, and the relevant
options for further tuning. Both modes offer the potential for high
performance, but the key performance factor is that the behavior that
gets optimized is different for each mode.
The dominant tuning
activity concerns controlling resource utilization to service allocation
activity of the application, and to arrange efficient garbage collection
to recycle storage, as required. Inevitably, these tuning discussions
are dependent on the garbage collection mode employed. Two types of
garbage collection are discussed:
- The throughput collector that performs parallel scavenge copy
collection on the young generation. This type of garbage collection
is the default type on multi-processor server class machines.
- A concurrent low-pause collector.
The objective of tuning with these collectors is to deliver
the behavior that is most suited for the allocation patterns and object
lifetimes of your application system, and that maximizes the efficiency
of their collection actions.
- Option 1: Use the default throughput/parallel scavenge collector
with built-in tuning enabled.
Starting with Version 5, the Sun HotSPot
JVM provides some detection of the operating system on which the server
is running, and the JVM attempts to set up an appropriate generational
garbage collection mode, that is either parallel or serial, depending
on the presence of multiple processors, and the size of physical memory.
It is expected that all of the hardware, on which the product runs
in production and preproduction mode, satisfies the requirements to
be considered a server class machine. However, some development hardware
might not meet this criteria.
The behavior of the throughput
garbage collector, whether tuned automatically or not, remains the
same and introduces some significant pauses, that are proportional
to the size of the used heap, into execution of the Java application system as it tries to maximize the benefit of generational
garbage collection. However, these automatic algorithms cannot determine
if your workload well-suits its actions, or whether the system requires
or is better suited to a different garbage collection strategy.
Consult these tuning parameters:
- -XX:+UseParallelGC
- -XX:+UseAdaptiveSizePolicy
- -XX:+AggressiveHeap
- Option 2: Use the default throughput/parallel scavenge collector,
but tune it manually.
Disadvantages of using the built-in algorithm
that is established using the -XX:+UseAdaptiveSizePolicy parameter,
include limiting what other parameters, such as the -XX:SurvivorRatio
parameter, can be configured to do in combination with the built-in
algorithm. When you use the built-in algorithm, you give up some control
over determining the resource allocations that are used during execution.
If the results of using the built-in algorithm are unsatisfactory,
it is easier to manually configure the JVM resources, than to try
and tune the actions of the algorithm. Manually configuring the JVM
resources involves the use of half as many options as it takes to
tune the actions of the algorithm.
Consult these tuning parameters:
- -XX:NewRatio=2 This is the default for a server that is configured
for VM mode
- -XX:MaxNewSize= and -XX:NewSize=
- -XX:SurvivorRatio=
- -XX:+PrintTenuringDistribution
- -XX:TargetSurvivorRatio=
- Option 3: Use the concurrent low-pause mark-sweep collector
This collector is a radical departure from the evolution of generational
garbage collection that has under pinned the Hotspot architecture,
permitting the overlap of application thread processing with a dedicated
low-priority, background garbage collection thread. If your application
data is incompatible with the behavior of the default throughput collector,
then the concurrent mark-sweep (CMS) collector might be a viable strategy,
particularly for application systems that are intolerant of invasive
pauses. This collector is particularly helpful with the very large
heaps that are used with the 64-bit JVM, or applications that have
a large set of long-lived data, also referred to as a large tenured
generation, and that maintains comparatively good cache utilization,
largely preserving pages of the young generation, even while the background
thread must scan through all the pages of the entire heap.
To
employ the concurrent mark-sweep collector as the principle housekeeping
agent, add this option, instead of any other garbage collection modes,
to your JVM configuration.
Consult these tuning parameters:
- -XX:+UseConcMarkSweepGC
- -XX:CMSInitiatingOccupancyFraction=75
- -XX:SurvivorRatio=6
- -XX:MaxTenuringThreshold=8
- -XX:NewSize=128m
Among the difficulties for tuning with CMS, is that the worst
case garbage collection times, which is when the CMS cycle aborts,
can take last several seconds, which is especially costly for a system
that uses CMS precisely to avoid long pauses. Consequently, service
level agreements might dictate the use of CMS, because the average
or median pause times are very, very low, and the tuning must err
on the cautious side to ensure that CMS cycles don't abort. CMS succeeds
only when its anticipatory trigger ensures that the CMS cycle always
starts early enough to ensure sufficient free resources are available
before they are demanded. If the CMS collector is unable to finish
before the tenured generation fills up, the collection is completed
by pausing the application threads, which is known as a full collection.
Full collections are a sign that further tuning is required to the
CMS collector to make it better suit your application.
Finally,
unlike other garbage collection modes with a compaction phase, the
use of CMS theoretically raises the risk of fragmentation occurring
with the HotSpot. However, in practice this is rarely a problem while
the collection recovers a healthy proportion of the heap. In cases
when the CMS fails, or aborts a collection, an alternative compacting
garbage collection is triggered. Inevitably any other type of garbage
collection incurs a significant invasive pause compared to a normal
CMS collection.
避免困難: As with the
throughput collector, there are considerably more options available
for explicitly controlling CMS. However, those mentioned represent
the core of the options that you are likely to need to considered
using when you are tuning the HotSpot JVM.
gotcha
What to do next
Gather and analyze data to evaluate the configuration,
typically using verbosegc. Continue to gather and analyze data as
you make tuning changes until you are satisfied with how the JVM is
performing.