JVM tuning-Starting with eclipse

Overview

What is JVM tuning? JVM tuning is based on the GC log analysis of the JVM memory allocation, recovery of the situation to adjust the memory ratio of each region or GC recovery strategy; The deeper layer is based on the memory structure of the dump and the Cheng of the line analysis code to give improvements. The eclipse optimization primarily involves the former, which is analyzed by GC logs. This article focuses on analyzing the Eclipse GC log as an example of how to tune the JVM memory based on the GC logs, like optimizing eclipse based on the actions of shutting down Eclipse startup items, turning off various checks, and so on, there are many online The eclipse of this test has been configured with the above optimizations.

Prepare the Environment

Eclipse version: Release 4.5.0

Eclipse Default configuration: Eclipse.ini

-startupplugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar--launcher.libraryplugins/ org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.300. V20150602-1417-productorg.eclipse.epp.package.jee.product--launcher.defaultactionopenfile--launcher.xxmaxpermsize256m-sho Wsplashorg.eclipse.platform--launcher.xxmaxpermsize256m--launcher.defaultactionopenfile--launcher.appendvmargs-vmargs-dos gi.requiredjavaversion=1.7-xms256m-xmx1024m

Add the following configuration file at the end of the configuration:

-xx:+printgcdetails//VERBOSE log of output GC

-xx:+printgcdatestamps//timestamp of the output GC (in the form of a date)

-xloggc:gc.log//VERBOSE log of output GC

Eclipse Startup Timing Plugin:

Http://www.chendd.cn/information/viewInformation/experienceShare/148.a

GCHISTO.JAR:GC Log Analysis tool jar package One

Visual Gc:java's own memory monitoring tool enables real-time monitoring of changes in each memory area through visual GC.

How to analyze GC logs

Extract GC Log part (blue for young generation GC recycle; green for full GC recycle):

2016-07-05t10:43:18.093+0800:25.395: [GC [psyounggen:274931k->10738k (274944K)] 371093k->147186k (450048K), 0.0668480 secs] [times:user=0.17 sys=0.08, real=0.07 secs]

2016-07-05t10:43:18.160+0800:25.462: [Full GC [psyounggen:10738k->0k (274944K)] [paroldgen:136447k->140379k ( 302592K)] 147186k->140379k (577536K) [pspermgen:85411k->85376k (171008K)], 0.6763541 secs] [times:user=1.75 sys= 0.02, real=0.68 secs]

Through the above log analysis, Psyounggen, Paroldgen, Pspermgen belong to the parallel collector. Which Psyounggen represents the memory change of the younger generation before and after GC recycling; Paroldgen represents the memory change of the old age before and after GC recycling; Pspermgen represents the memory change of the permanent area before and after GC reclamation. Young GC is mainly for the younger generation of memory recovery is more frequent, time-consuming, full GC will be the entire heap of memory to return to the town, time consuming, so generally minimize the number of complete GC

The GC log composition is clearly seen through two graphs:

Young GC Log

Full GC Log

Start tuning

Start Eclipse View the default configuration startup time is about 22 seconds.

According to the GC log of Gchisto analysis, it takes about 0.65 seconds for a full gc,19 minor gc;full GC and young GC to start the process.

First Step optimization:

In order to avoid the frequent dynamic expansion of memory, directly-XMS configuration and-xmx consistent, modified as follows:

-xms1024m

After modification, reboot:

The boot time is reduced to 17 seconds, and the GC logs are analyzed to get young gc22 times, and the full GC is gone! But the young GC increased two times.

Second Step optimization:

Because the memory of this machine is 8G, it is a little bit small to allocate 1g to eclipse, it is simply rude to double all the memory configuration directly.

The configuration is as follows:

--launcher. Xxmaxpermsize

512M

--launcher. Xxmaxpermsize

512m

-xms2048m

-xmx2048m

The start-up time is reduced to 15 seconds, but the young GC has been shortened to only 7 times, indicating that the issue of slow eclipse startup due to GC recycling has been initially resolved

Third Step optimization:

The visual GC sees the time at which ClassLoader loads the class at eclipse startup, and turning off bytecode may optimize part of the startup time by adding the following parameters:

-xverify:none (Turns off Java bytecode validation, which speeds up class loading)

Restart the test, the start time has been optimized to 9 seconds!

To view the boot log, the number of young GC is only once!

End of optimization, with final Eclipse.ini file

-startupplugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar--launcher.libraryplugins/ org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.300. V20150602-1417-productorg.eclipse.epp.package.jee.product--launcher.defaultactionopenfile--launcher.xxmaxpermsize512m-sho Wsplashorg.eclipse.platform--launcher.xxmaxpermsize512m--launcher.defaultactionopenfile--launcher.appendvmargs-vmargs-dos Gi.requiredjavaversion=1.7-xms2048m-xmx2048m-xverify:none-xx:+printgcdetails                 -XX:+PRINTGCDATESTAMPS-XLOGGC : Gc.log

Reference: JVM Series (vi): JVM tuning-Starting with eclipse

JVM tuning-Starting with eclipse