After replacing the operating system of the working computer with win7, my MyEclipse has been unsatisfactory in startup and running speed. Especially when modifying and debugging multiple page templates at the same time, switching between two files will always be stuck for about ten seconds. Trying to turn off various plugins and verify them will not help. So after roughly studying the JVM, I decided to try to solve this problem from the perspective of the JVM.
Start Optimization:
First, let’s take a look at the default startup parameters in myeclipse.ini:
-Xmx512m: Set the maximum heap memory value to 512M
-XX:MaxPermSize=256m: Set the maximum value of the persistent generation to 256m
-XX: ReservedCodeCacheSize=64m: Set the memory size occupied by the code to 64m
Nothing can be seen from the startup parameters, so add the relevant parameters for printing memory changes:
-XX:+PrintGCTimeStamps: Print the timestamp of each GC
-XX:+PrintGCDetails: Print detailed information for each GC
-Xloggc:myEclipseGC.log: output GC records to file
-verbose:gc: Output the relevant situation of each GC
Then start MyEclipse and check the information in myEclipseGC.log:
The startup takes about 30 seconds. Selectively intercept a small part of the logs. You can see that in the first 10 seconds of myeclipse startup, the JVM executed more than 300 GCs and 9 FULL GCs.
From the GC frequency and information, it can be seen that the memory recovery rate is very high and the size is constantly adjusting. This should be due to insufficient space in the younger generation, and a considerable initial value is needed.
Then focus on FULL GC:
Copy the code as follows: 5.961: [Full GC 5.961: [Tenured: 34568K->34456K(49676K), 0.1397651 secs] 35336K->34456K(53452K), [Perm: 26623K->26458K(26624K)], 0.1398562 secs] [Times: user=0.14 sys=0.00, real=0.14 secs]
9.030: [Full GC 9.030: [Tenured: 53310K->52332K(64588K), 0.2034757 secs] 56020K->52332K(69516K), [Perm: 43007K->42996K(43008K)], 0.2036030 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]
From the comparison of the two logs, we can see that FULL GC is mainly recycling the two areas of Tenured and Perm, and the sizes of these two areas are constantly being adjusted, so we decided to fix their size first.
So the adjusted parameters are as follows:
-Xms512m: Set the minimum value of the stack to 512m
-Xmn192m: Set the size of the younger generation to 192m
-XX:PermSize=192m: Set the initial value of the persistent generation to 192m
-XX:MaxPermSize=192m
-XX: ReservedCodeCacheSize=64m
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xloggc:myEclipseGC.log
-verbose:gc
Restart MyEclipse once to view the log information:
The startup took about 12 seconds. From the log, it can be seen that only 5 GCs were performed in the first 10 seconds, and no adjustments to the size of each area were involved. This result is acceptable because it does not require frequent restarts during work.
Optimization of work response speed:
Next, I studied the frequent delays and big card problems when switching html files back and forth that had troubled me for a long time. In order to more intuitively study the memory changes of JVM, I decided to use jconsole, a helper tool that comes with Java. First restore the parameters of myeclipse.ini to avoid interference from the first stage of optimization.
Start myeclipse, start jconsole and connect to the JVM where myeclipse is located. The memory diagram of the entire heap after the stable is as follows:
Next try opening a few templates and then observing the memory changes.
First of all, the overall usage of heap memory:
It can be seen that after opening several templates, the use of heap memory suddenly increased from the original below 100M to more than 300M. The usage has tripled, but it is still within the 512M range I set. Therefore, you can temporarily not consider continuing to increase the heap memory, but instead consider adjusting the memory size ratio of each zone.
So we observe the memory usage of each zone during this period, among which the Eden zone is as follows:
The memory usage rate of the Eden area increased significantly during this period, and GC occurred several times. Through the monitoring information below, we can know that by default, the eden area only allocates 31M of maximum memory, which is obviously not enough. Execution of a little point will trigger the GC in the eden area. This should be one of the reasons for delay lag in the template opening switch and needs to be adjusted.
Next is the Tenured area:
The maximum space allocated by JVM to this area by default is 470M. As memory usage changes, the actual size of this area is constantly being adjusted. FULL GC will occur every time the area size is adjusted, which should be one of the reasons for frequent big blocks. The opening of the new template is the main reason for triggering this adjustment. From the perspective of memory usage in this area, it is still necessary to maintain a certain amount of redundancy by maintaining and fixing the memory space in this area at around 450M.
From this point of view, it is still necessary to expand the heap memory of jvm to maintain a larger Tenured area and Eden area.
Finally, let’s take a look at the perm area:
As part of the method area, the memory changes in this area are not large and relatively stable, so there is no need to leave too much redundancy. However, considering that the actual code volume of the currently opened project is not large, it is decided to temporarily maintain it at around 128M and slowly adjust it in the future.
So according to the above analysis, the parameters are adjusted to:
-Xmx768m
-Xms768m
-Xmn256m
-XX:PermSize=192m
-XX:MaxPermSize=192m
-XX: ReservedCodeCacheSize=64m
Restart myeclipse, connect to Jconsole, and open thirty templates at the same time to do the test. When looking at the memory usage rate of each zone, I found a problem. After adjusting the young generation to 256M, since Eden no longer frequently occurs in GC, the amount of data entering the Tenured area is significantly reduced. The memory usage diagram of the Tenured area is as follows:
As shown in the figure above, when many templates are deliberately opened, the 450M+ space only uses less than 250M, and the space utilization rate is too low, so adjustments need to be made.
Summarize
The above are some ideas and actual tuning process for me to tune my myeclipse. In actual use, I made some adjustments and customizations according to my preferences. The final parameters of myeclipse.ini are as follows:
-vmargs
-Xmx512m
-Xms512m
-Xmn192m
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX: ReservedCodeCacheSize=64m
Under this parameter setting, the response speed of myeclipse is relatively guaranteed, and the frequency of various delay lags is greatly reduced. The disadvantage is that the system memory occupied by the permanent resident is relatively high. Students who like to open multiple myeclipse at the same time can make appropriate adjustments according to their needs and actual conditions.
The above is all about this article, I hope it will be helpful to everyone's learning.