Eclipse's Optimization Gc.log

Original posts: http://www.javaeye.com/topic/756538

Performance optimization starts from the side.

First set up an evaluation system to close all the projects in the workspace, closing eclipse. The optimized use case is to start eclipse,open a project, and Eclipse will automatically build the project to ensure that no obvious cards are felt, i.e. no full GC.

Begin:

The parameters for printing GC conditions are included in the Eclipse.ini:

-xx:+printgctimestamps

-xx:+printgcdetails

-verbose:gc

-xloggc:gc.log

This allows eclipse to log GC logs during the run, display detailed GC scenarios, and print in Gc.log to look for Eclipse performance bottlenecks and optimizations by analyzing this log.
My initial argument was to raise the heap size on the original basis.

-xms512m

-xmx512m

Set the heap initialization and maximum value to the same, eliminating the impact of heap size changes based on current heap usage.
Start Eclipse and find a lot of full GC logs in Gc.log

Reference 4.226: [Full GC 4.226: [tenured:18470k->19304k (30544K), 0.1159544 secs] 25154k->19304k (44368K), [perm:24574k-& GT;24554K (24576K)], 0.1160431 secs] [times:user=0.13 sys=0.00, real=0.13 secs]

In the start of more than 6 seconds a total of 8 times full GC, so start slow, feel the boot time card. From the log can be seen FULLGC mainly in the recovery of tenured area and Perm area, where Perm has always been fast full state, perm:24574k->24554k (24576K), Perm size in constant adjustment, so need to fix the size of the Perm area, Guaranteed enough, Eclipse.ini added

-xx:permsize=64m

-xx:maxpermsize=64m

Restart: found no full GC has only a larger number of minor GC, pick start start to start to completion of the first and last log

Reference 0.209: [GC 0.209: [defnew:4416k->511k (4928K), 0.0034707 secs] 4416k->614k (15872K), 0.0035239 secs] [times:user= 0.00 sys=0.00, real=0.00 secs]
....
6.383: [GC 6.383: [defnew:18880k->1985k (21184K), 0.0055311 secs] 46992k->30098k (68040K), 0.0055694 secs]

This 6 seconds the GC log hit 69 times, and the memory recovery is quite high in the young area 18880-1985=16895 JVM 46992-30098=16894 are nearly 100%, you can see that the younger area is from small to large in constant resizing, so constantly GC, So set an initial value, it is said to set the heap 1/4 better, that is 128M, so Eclipse.ini joined

-xmn128m

Restart again, found that the GC log is four, eclipse started naturally fast

Reference 1.292: [GC 1.292: [defnew:104960k->10984k (118016K), 0.0334165 secs] 104960k->10984k (511232K), 0.0334603 secs] [ times:user=0.03 sys=0.00, real=0.03 secs]
2.182: [GC 2.182: [defnew:115944k->1852k (118016K), 0.0221714 secs] 115944k->11466k (511232K), 0.0222142 secs] [ times:user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [defnew:106779k->12531k (118016K), 0.0378228 secs] 116393k->22145k (511232K), 0.0378692 secs] [ times:user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [defnew:117491k->9403k (118016K), 0.0513728 secs] 127105k->31364k (511232K), 0.0514133 secs]

However, after launching open my multiple projects, these projects depend on each other, Eclipse auto build, feel a bit small card, found the log more than 4 times full GC, so on the card ...

Reference 67.320: [Full GC (System) 67.320: [tenured:88847k->68809k (393216K), 0.2121213 secs] 117385k->68809k (511232K), [ perm:41915k->41915k (65536K)], 0.2121747 secs] [times:user=0.20 sys=0.00, real=0.20 secs]
103.759: [Full GC (System) 103.759: [tenured:81882k->66784k (393216K), 0.3287387 secs] 185350k->66784k (511232K), [ perm:53464k->53414k (65536K)], 0.3287897 secs] [times:user=0.33 sys=0.00, real=0.33 secs]

This time tenured district and Perm are not very close to the maximum, but why there is a full GC, and began to think that the JVM is pessimistic that the remaining space in the tenured area is not enough to deal with the next minor GC, so we have to adjust the amount of GC tenured space, Simply increase the heap maximum to-xmx728m (the working computer's memory is 3.5G), but after restarting the full GC is still 4 times, and there are several times minor GC for more than 0.1 seconds, because the increase in heap size, resulting in GC time also increased, unacceptable. So I changed back to-xmx512m.
Then carefully observe the log, found the full GC (System) Word, this means that Eclipse called System.GC () manually triggered the system GC, OK, Brother has allocated enough space for you, you save it, in the Eclipse.ini add:

-xx:+disableexplicitgc

This is almost there, the whole process did not appear full GC, and then encoded 2 hours, in the middle only a full GC, in the open build a 50W line + code, Eclipse is still a card ...
Finally, a little bit of the size of the generations to get the current parameters:

-xms512m

-xmx512m

-xx:permsize=96m

-xx:maxpermsize=96m

-xmn168m

-xx:+disableexplicitgc

In addition, there is no GC policy, mainly think that Eclipse is a client program, the default client single-threaded GC policy should be more appropriate, there is time to try again later.

The Java Virtual machine allocates 64M of memory by default, and if your application is larger and exceeds 64M of memory, the Java Virtual machine will throw OutOfMemoryError and stop running. No matter what application (Web application, application, etc.), you only need to modify the running Java command on your machine, add-XMS (minimum memory use),-XMX (maximum use memory) in the JAVAXXX command to resolve. Of course, the memory capacity here refers to the physical memory, not exceeding the total capacity of your machine's physical memory.

For a separate. Class, you can set the JVM memory of the test runtime using the following method.
java-xms64m-xmx256m Test
-XMS is the size of the set memory initialization
-XMX is to set the maximum amount of memory that can be used (preferably not exceeding the physical memory size)

How to set up in eclipse

Method 1: The corresponding setting in Eclipse is: Window----preferences->java-> installed JRE, added in default VM arguments:-xmx256m (You can also add other parameters such as-xms128m-xx:permsize=64m- xx:maxpermsize=128m)

Method 2: Modify the Eclipse.ini
-vmargs-xms128m-xmx512m-xx:permsize=64m-xx:maxpermsize=128m
Here are a few questions:
1. What are the meanings of each parameter?
2. Why do some machines I set-xmx and-xx:maxpermsize to 512M after eclipse can be started, and some machines will not boot?
3. Why is the above parameter written to the Eclipse.ini file eclipse does not perform the corresponding settings?
Here's a reply.
1. What are the meanings of each parameter?
The-vmargs in the parameter is to set the JVM parameters, so the following is actually the JVM parameters, we first understand the JVM memory management mechanism, and then explain the meaning of each parameter represents.
Heap and non-heap (non-heap) memory
According to the official statement, "Java virtual machines have a heap, the heap is a runtime data region, and all class instances and arrays of memory are allocated from here." The heap is created when the Java virtual machine is started. "" The memory outside the heap in the JVM is called non-heap (non-heap memory) ". You can see that the JVM primarily manages two types of memory: heap and non-heap. In a nutshell, a heap is a Java code-readable memory that is left to the developer, not a heap, which is left to itself by the JVM, so the method area, the JVM internally processes or optimizes the required memory (such as the JIT-compiled code cache), each class structure (such as running a constant pool, field, and method data) And the code for methods and construction methods are in non-heap memory.
Heap memory allocation
The initial memory allocated by the JVM is specified by-XMS, the default is physical memory 1/64;JVM the maximum allocated memory is specified by-XMX, which defaults to 1/4 of the physical memory. When the default free heap memory is less than 40%, the JVM increases the heap until the maximum limit of-xmx, and when the free heap memory is greater than 70%, the JVM reduces the heap until the minimum limit of-XMS. So the server generally sets-xms,-xmx equal to avoid resizing the heap after each GC.
Non-heap memory allocation
The JVM uses-xx:permsize to set the non-heap memory initial value, which defaults to 1/64 of the physical memory, and the maximum non-heap memory by Xx:maxpermsize, which by default is 1/4 of physical memory.
JVM Memory Limit (max)
First, the JVM memory is limited to the actual maximum physical memory (nonsense!). hehe), assuming that the physical memory is infinitely large, the maximum value of the JVM memory is very much related to the operating system. Simply put, 32-bit processor Although the controllable memory space has 4GB, but the specific operating system will give a limit, this limit is generally 2GB-3GB (generally speaking, Windows system under the 1.5g-2g,linux system for 2G-3G), There is no limit to processors over 64bit.
2. Why do some machines I set-xmx and-xx:maxpermsize to 512M after eclipse can be started, and some machines will not boot?
We have learned from the above introduction to JVM memory management that there are two types of JVM memory: heap memory and non-heap memory, and the JVM's maximum memory depends first on actual physical memory and operating system. So there are several reasons why setting a VM parameter causes the program to fail to start:
1) The value of-XMS in the parameter is greater than-XMX, or the value of-xx:permsize is greater than-xx:maxpermsize;
2) The sum of-XMX values and-xx:maxpermsize exceeds the maximum limit of JVM memory, such as the maximum memory limit of the current operating system, or actual physical memory, and so on. When it comes to physical memory, it is important to note that if your memory is 1024MB, the actual system is not likely to be 1024MB, because a portion of it is consumed by the hardware.
3. Why is the above parameter written to the Eclipse.ini file eclipse does not perform the corresponding settings?
Why is the same argument valid on a shortcut or command line and is not valid in the Eclipse.ini file? This is because we have not complied with the setup rules for Eclipse.ini files:
Parameter shape such as "Item Value" In this form, there are spaces in the middle of the need to write a newline, if there are spaces in the value need to be enclosed in double quotation marks. For example, we use the-VM C:\Java\jre1.6.0\bin\javaw.exe parameter to set up the virtual machine, in the Eclipse.ini file to write this:
-vm

C:\Java\jre1.6.0\bin\javaw.exe
As stated above, the final parameter can be written in Eclipse.ini:
-vmargs
-xms128m
-xmx512m
-xx:permsize=64m
-xx:maxpermsize=128m
The results of the actual operation can be viewed through the "Configuration Details" button in the "Help" – "About Eclipse SDK" window in Eclipse.

Another article: a Java garbage collection tuning combat

1 Information

• JDK5.0 garbage Collection Optimization--don ' t Pause (spending the years)
• Write a GC-friendly, non-leaking code (spending the years)
• JVM Tuning Summary
• JDK 6 all options and default values

2 GC Log Printing

GC tuning is a very experimental and Galileo job, GC logs are pre-requisite data references and final validation:

-xx:+printgcdetails-xx:+printgctimestamps (time GC occurs)-xx:+printgcapplicationstoppedtime (how much time is consumed by GC)-XX:+ Printgcapplicationconcurrenttime (How much time is running between the GC)

3 Collector Select CMS Collector: Pause time First

Configuration parameters:-XX:+USECONCMARKSWEEPGC
Parameters that are not configured by default:-XX:+USEPARNEWGC (Parallel collection Generation)-xx:+cmspermgensweepingenabled (CMS collection Persistence generation)-XX: Usecmscompactatfullcollection (full GC compression old generation)

Initial effect: 1g heap memory of the Cenozoic about 60m,minor GC about 5-20 milliseconds, full GC about 130 milliseconds.

Parallel Collector: Throughput priority

Configuration parameters:-XX:+USEPARALLELGC-XX:+USEPARALLELOLDGC (parallel collection old generation, starting from JDK6.0 support)

Parameters that are not configured by default:-xx:+useadaptivesizepolicy (dynamically adjust Cenozoic size)

Initial effect: 1g heap memory of the Cenozoic about 90-110m (dynamic adjustment), minor GC about 5-20 milliseconds, full GC has no USEPARALLELOLDGC parameters of 1.3/1.1 seconds, the difference is not small.

In addition-xx:maxgcpausemillis=100 sets the desired maximum time for the minor GC, which the JVM will use to adjust the size of the Cenozoic, but the object dies too quickly in this test environment and this parameter does little.

4 Tuning Combat

Parallel collect up to 1 seconds of pause time is basically intolerable, so choose the CMS collector.

In the Mule 2.0 application that is being measured, approximately 400M of short-lived objects are produced per second:

1. Since the new generation of the default 60M is too small, frequent minor GC, which occurs approximately 0.2 seconds.
2. Because the CMS collector in Maxtenuringthreshold (generation object over how many times minor gc to enter the old generation of settings) by default 0, the surviving temporary object does not go through the survivor area directly into the old generation, and soon takes over the old generation of full GC.

The tuning of these two parameters, both to improve the above two cases, but also to avoid the Cenozoic too large, too many copies of the minor GC pause time is too long.

1. Use-xmn to tune to 1/3 total memory. After observation set-xmn500m, the new generation actually about 460m. (Invalid setting with-xx:newratio, only with-xmn).
2. Add the-xx:+printtenuringdistribution parameter to observe the total size of each age object and set-xx:maxtenuringthreshold=5 after observation.

Once optimized, the minor GC occurs in about 1.1 seconds, and the speed remains between 15-20ms. At the same time, the growth rate of older generations slowed considerably, and a full GC took place a long time ago.

Final parameters:

-SERVER-XMS1024M-XMX1024M-XMN500M-XX:+USECONCMARKSWEEPGC  -xx:maxtenuringthreshold=5-xx:+ Explicitgcinvokesconcurrent

The final service processing speed rose from 1180 TPs to 1380 TPS, adjusting two parameters to 17% performance or a very good deal.

In addition, the JDK6 Update 7 comes with a VISUALVM tool, which is a useful netbean Profiler, similar to Jconsole, and can be used to see the thread state, the objects in memory, and the CPU time of the method as important reference. Free bundle Ah, Sun is so pointers, other companies doing the profiler will be closed.

Top

0

Step

Eclipse's Optimization Gc.log