long-lived, and some are not. The ones that are not become de-referenced, which
means that the JVM no longer has a link to them because they have ceased to be useful.
These may be variables that were used for methods which have already returned
their values, objects retrieved from the database for a user that is no longer logged
on, or a host of other things. These objects sit in memory and fill up the heap space
until the JVM decides it's time to clean them up.
Normally, when garbage collection (GC) runs, it stops all processing in the JVM
while it goes through the heap looking for dead objects. Once it finds them, it frees up the memory they were taking up, and then processing can continue. If this happens in a server environment, it can slow down the processing of requests, as all processing comes to a halt while GC is happening.
There are some JVM switches that you can enable which can reduce the amount
of time processing is halted while garbage collecting happens. These can improve the
performance of your Liferay installation if applied properly. As always, you will need to use a profiler to monitor garbage collection during a load test to tune the numbers properly for your server hardware, operating system, and application server.
The Java heap is divided into sections for the young generation, the old generation,
and the permanent generation. The young generation is further divided into
three sections: Eden, which is where new objects are created, and two “survivor
spaces,” which we can call the From and To spaces.
Garbage collection occurs in stages. Generally, it is more frequently done in the
young generation, less frequently done in the old generation, and even less frequently done in the permanent generation, where long-lived objects reside. When garbage collection runs in the young generation, Eden is swept for objects which are no longer referenced. Those that are still around are moved to the “To” survivor space, and the “From” space is then swept. Any other objects in that space which still have references to them are moved to the “To” space, and the “From” space is then cleared out altogether. After this, the “From” and the “To” spaces swap roles, and processing is freed up again until the next time the JVM determines that garbage collection needs to run.
After a predetermined number of “generations” of garbage collection, surviving
objects may be moved to the old generation. Similarly, after a predetermined number
of “generations” of garbage collection in the old generation, surviving objects may be moved to the permanent generation.By default, the JDK uses a serial garbage collector to achieve this. This works very well for a short-lived desktop Java application, but is not necessarily the best performer for a server-based application like Liferay. For this reason, you may wish to switch to the Concurrent Mark-Sweep (CMS) collector.
Rather than halting application processing altogether, this garbage collector
makes one short pause in application execution to mark objects directly reachable
from the application code. Then it allows the application to run while it marks all objects which are reachable from the set it marked. Finally, it adds another phase called the remark phase which finalizes marking by revisiting any objects modified while the application was running. It then sweeps through and garbage collects. This has the effect of greatly reducing the amount of time that execution needs to be halted in order to clean out dead objects. Just about every aspect of the way memory management works in Java can be tuned. In your profiling, you may want to experiment with some of the following settings to see if any of them can increase your performance.NewSize, MaxNewSize: The initial size and the maximum size of the New or
Young Generation.
+UseParNewGC: Causes garbage collection to happen in parallel, using multiple
CPUs. This decreases garbage collection overhead and increases application throughput.
+UseConcMarkSweepGC: Use the Concurrent Mark-Sweep Garbage Collector.
This uses shorter garbage collection pauses, and is good for applications that have a
relatively large set of long-lived data, and that run on machines with two or more
processors, such as web servers.
+CMSParallelRemarkEnabled: For the CMS GC, enables the garbage collector to
use multiple threads during the CMS remark phase. This decreases the pauses during
this phase.
ServivorRatio: Controls the size of the two survivor spaces. It's a ratio between
the survivor space size and Eden. The default is 25. There's not much bang for the
buck here, but it may need to be adjusted.
ParallelGCThreads: The number of threads to use for parallel garbage collection.
Should be equal to the number of CPU cores in your server.
A sample configuration using the above parameters might look something like
this:
JAVA_OPTS="$JAVA_OPTS -XX:NewSize=700m -XX:MaxNewSize=700m -Xms2048m
-Xmx2048m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:
+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XX:ParallelGCThreads=8"
No comments:
Post a Comment