Optimization of eclipse startup parameters during website construction

Eclipse is often used in website construction. It takes a lot of time to start each time. How can we optimize it?

Version: eclipse3.6

Parameter configuration file: Eclipse. ini

Result: After modification, the startup speed is obviously faster.

Note: The focus is on the settings of the red part

First establish the evaluation system, for example, we need to establish a website http://www.hualai.net.cn, first close all the projects in the workspace, close eclipse. The optimized use case is to start eclipse and open a project. eclipse will automatically build this project to ensure that there is no obvious card, that is, there is no full GC.

Start:

Add the following parameters to the eclipse. ini file to print GC:

 

-XX: + printgctimestamps
-XX: + printgcdetails
-Verbose: GC
-Xloggc: GC. Log

In this way, eclipse will record the GC log during running, display the detailed GC information, and print it in GC. log to find eclipse performance bottlenecks and optimization methods by analyzing this log.

My initial parameter is to adjust the heap size based on the original version.

 

-Xms512m
-Xmx512m

Set heap initialization to the same value as the maximum value to eliminate the impact of heap size changes based on the current heap usage.

Start eclipse and find that many full GC logs are output in GC. log.

4.226: [full GC 4.226: [tenured: 18470 K-> 19304 K (30544 K), 0.1159544 secs] 25154 K-> 19304 K (44368 K), [perm: 24574 K-> 24554 K (24576 K)], 0.1160431 secs] [times: User = 0.13 sys = 0.00, real = 0.13 secs]

During the six-second startup, a total of eight full GC times were detected. Therefore, the startup was slow and it was difficult to start. From the log, we can see that fullgc is mainly used to recycle tenured and perm areas. perm is always in the full state, Perm: 24574 K-> 24554 K (24576 K ), the perm size is constantly adjusted, so the size of the perm area needs to be fixed to ensure adequate use, Eclipse. add in ini

-XX: permsize = 64 m
-XX: maxpermsize = 64 m

Restart: If no full GC is found, there are only a large number of minor GC logs. Select the first and last logs from start to start.

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

In the past 6 seconds, the GC logs were played 69 times, while the memory recovery rate was still very high in the young district 18880-1985 = 16895 JVM 46992-30098 = 16894, almost close to 100%, it can be seen that the young area is constantly adjusting the size from small to large, so it is constantly GC, so set an initial value. It is said that it is better to set the heap 1/4, that is, 128 M, so eclipse. add ini

-Xmn128m

Restart the system and find that there are only four GC logs. Eclipse is faster to start.

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

However, after the startup, open my multiple projects, these projects are mutually dependent, and the eclipse Automatic Build feels a little tricky. I found that the log contains four full GC times, so I got stuck...

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

At this time, tenured and perm are not very close to the maximum value, but why is there full GC, in the beginning, I thought that the JVM was pessimistic and thought that the remaining space in the tenured zone was insufficient to cope with the next minor GC, So I adjusted the tenured space in full GC, the maximum heap size is directly increased to-xmx728m (the memory of the working computer is 3.5 GB), but the full GC is still 4 times after restart, the number of minor GC times exceeds 0.1 seconds. This is because the heap size is increased, which leads to an increase in GC time and is unacceptable. So change back to-xmx512m.

Then carefully observe the log and find the full GC (system), which means that the system is called in eclipse. GC () manually triggers the system GC. Well, you have allocated enough space for it. You can save it in eclipse. add in ini:

-XX: + disableexplicitgc

This is almost the same. There was no full GC in the whole process, and the code was coded for another two hours. There was only one full GC in the middle. When a 50 million lines of code in open build +, eclipse is stuck...

At last, I slightly adjusted the size of each generation to obtain the current parameters:

-Xms512m
-Xmx512m
-XX: permsize = 96 m
-XX: maxpermsize = 96 m
-Xmn168m
-XX: + disableexplicitgc

In addition, the GC policy has not been adjusted. The main reason is that eclipse is a client program. The default GC policy for a single client thread should be more suitable. Try again later.