Nachdem ich das Betriebssystem des Arbeitscomputers durch Win7 ersetzt hatte, war meine MyeClipse bei Start und Laufgeschwindigkeit unbefriedigend. Insbesondere beim Ändern und Debuggen mehrerer Seitenvorlagen gleichzeitig wird das Umschalten zwischen zwei Dateien immer etwa zehn Sekunden lang festsitzt. Der Versuch, verschiedene Plugins auszuschalten und diese zu überprüfen, hilft nicht. Nachdem ich das JVM grob studiert hatte, beschloss ich, dieses Problem aus der Perspektive des JVM zu lösen.
Startoptimierung:
Schauen wir uns zunächst die Standard -Startparameter in myeClipse.ini an:
-Xmx512m: Setzen Sie den maximalen Heap -Speicherwert auf 512 m
-Xx: maxpermSize = 256m: Setzen Sie den Maximalwert der persistenten Generation auf 256 m
-XX: ReservedCodeCachesize = 64 m: Setzen Sie die vom Code besetzte Speichergröße auf 64 m
Aus den Startparametern ist nichts zu erkennen. Fügen Sie daher die entsprechenden Parameter für den Druckspeicheränderungen hinzu:
-XX:+printgctimestamps: Drucken Sie den Zeitstempel jedes GC aus
-XX:+printgcdetails: detaillierte Informationen für jeden GC drucken
-Xloggc: myeclipsegc.log: Ausgabe -GC -Datensätze in Datei ausgeben
-Verbose: GC: Ausgabe der relevanten Situation jedes GC ausgeben
Starten Sie dann MyeClipse und überprüfen Sie die Informationen in myeClipsegc.log:
Das Startup dauert ungefähr 30 Sekunden. Abfangen einen kleinen Teil der Protokolle selektiv. Sie können sehen, dass in den ersten 10 Sekunden des MyeClipse -Startups die JVM mehr als 300 GCs und 9 Voll -GCs ausgeführt hat.
Aus der GC -Häufigkeit und den Informationen ist ersichtlich, dass die Speicherwiederherstellungsrate sehr hoch ist und die Größe ständig eingestellt ist. Dies sollte auf unzureichendem Platz in der jüngeren Generation zurückzuführen sein, und ein erheblicher Anfangswert ist erforderlich.
Konzentrieren Sie sich dann auf die volle 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] [Zeiten: Benutzer = 0,14 sys = 0,00, real = 0,14 Sekunden]
9.030: [Full GC 9.030: [Tenured: 53310K-> 52332K (64588K), 0,2034757 Sekunden] 56020K-> 52332K (69516K), [Perm: 43007K-> 42996K (43008K), 0,20303030303030303003003030300303030030300303.2030, 0,20303030303030, 0,203030303030, 0,2030303030, 0,2030303030, 0,203030303030, 0,2030303030, 0,2030303030, 0,203030303030. sys = 0,00, real = 0,20 Sekunden]
Aus dem Vergleich der beiden Protokolle können wir feststellen, dass Full GC hauptsächlich die beiden Bereiche von festem und perm recycling und die Größen dieser beiden Bereiche ständig angepasst werden. Deshalb haben wir uns entschlossen, ihre Größe zuerst zu beheben.
Die angepassten Parameter sind also wie folgt:
-Xms512m: Setzen Sie den Mindestwert des Stapels auf 512 m
-Xmn192m: Setzen Sie die Größe der jüngeren Generation auf 192 m
-Xx: permsize = 192m: Setzen Sie den Anfangswert der persistenten Generation auf 192m
-Xx: MaxpermSize = 192 m
-Xx: ReservedCodecachesize = 64 m
-Xx:+printgctimestamps
-Xx:+printgcdetails
-Xloggc: myeclipsegc.log
-Verbose: GC
Starten Sie MyeClipse einmal neu, um die Protokollinformationen anzuzeigen:
Das Startup dauerte ungefähr 12 Sekunden. Aus dem Protokoll ist ersichtlich, dass in den ersten 10 Sekunden nur 5 GCs durchgeführt wurden und keine Anpassungen an die Größe jedes Bereichs beteiligt waren. Dieses Ergebnis ist akzeptabel, da es während der Arbeit keine häufigen Neustarts erfordert.
Optimierung der Arbeitsreaktionsgeschwindigkeit:
Als nächstes studierte ich die häufigen Verzögerungen und große Kartenprobleme beim Umschalten von HTML -Dateien hin und her, die mich schon lange beunruhigt hatten. Um die Speicheränderungen von JVM intuitiver zu untersuchen, habe ich mich entschlossen, JConsole, ein Helfer -Tool mit Java, zu verwenden. Stellen Sie zunächst die Parameter von myeClipse.ini wieder her, um Störungen aus der ersten Stufe der Optimierung zu vermeiden.
Starten Sie MyeClipse, starten Sie JConsole und stellen Sie eine Verbindung zum JVM, in dem sich MyeClipse befindet. Das Speicherdiagramm des gesamten Haufens nach dem Stall lautet wie folgt:
Versuchen Sie als nächstes, ein paar Vorlagen zu öffnen und dann die Speicheränderungen zu beobachten.
Zunächst die Gesamtnutzung des Heap -Speichers:
Es ist ersichtlich, dass nach dem Öffnen mehrerer Vorlagen die Verwendung des Heap -Speichers plötzlich vom Original unter 100 m auf mehr als 300 m erhöht wurde. Die Nutzung hat sich verdreifacht, aber sie befindet sich immer noch im 512m -Bereich, den ich festgelegt habe. Daher können Sie vorübergehend nicht in Betracht ziehen, den Heap -Speicher weiter zu erhöhen, sondern die Speichergrößenverhältnis jeder Zone anzupassen.
Deshalb beobachten wir die Speicherverwendung jeder Zone in dieser Zeit, unter der die Edenzone wie folgt ist:
Die Speicherverbrauchsrate des Edenbereichs stieg in diesem Zeitraum signifikant an und GC trat mehrmals auf. Durch die folgenden Überwachungsinformationen können wir wissen, dass der Edenbereich standardmäßig nur 31 m maximaler Speicher zuweist, was offensichtlich nicht ausreicht. Die Ausführung eines kleinen Punktes löst den GC im Edenbereich aus. Dies sollte einer der Gründe für die Verzögerungsverzögerung im Vorlagenöffnungsschalter sein und muss angepasst werden.
Als nächstes kommt der feste Bereich:
Der maximale Speicherplatz von JVM in diesem Bereich beträgt standardmäßig 470 m. Wenn sich die Speicherverwendung ändert, wird die tatsächliche Größe dieses Bereichs ständig angepasst. Jedes Mal, wenn die Flächengröße angepasst wird, tritt eine vollständige GC auf, was einer der Gründe für häufige große Blöcke sein sollte. Die Öffnung der neuen Vorlage ist der Hauptgrund für die Auslösung dieser Anpassung. Aus Sicht der Speicherverbrauch in diesem Bereich ist es immer noch erforderlich, eine bestimmte Menge an Redundanz aufrechtzuerhalten, indem der Speicherplatz in diesem Bereich bei rund 450 m aufrechterhalten und festgelegt wird.
Aus dieser Sicht ist es immer noch notwendig, den Heap -Speicher von JVM zu erweitern, um einen größeren Bereich und Edenbereich aufrechtzuerhalten.
Schauen wir uns schließlich den Perm -Bereich an:
Im Rahmen des Methodenbereichs sind die Speicheränderungen in diesem Bereich nicht groß und relativ stabil, sodass nicht zu viel Redundanz zurückgelassen werden muss. In Anbetracht der Tatsache, dass das tatsächliche Codevolumen des aktuell eröffneten Projekts nicht groß ist, wird beschlossen, es vorübergehend bei rund 128 m zu pflegen und in Zukunft langsam anzupassen.
Entsprechend der obigen Analyse werden die Parameter so angepasst:
-Xmx768m
-Xms768m
-Xmn256m
-Xx: permSize = 192 m
-Xx: MaxpermSize = 192 m
-Xx: ReservedCodecachesize = 64 m
Starten Sie MyeClipse neu, stellen Sie eine Verbindung zu JConsole und öffnen Sie gleichzeitig dreißig Vorlagen, um den Test durchzuführen. Bei der Betrachtung der Speichernutzungsrate jeder Zone fand ich ein Problem. Nach der Einstellung der jungen Generation auf 256 m, da Eden in GC nicht mehr häufig vorkommt, wird die Datenmenge, die in den festgelegten Bereich eintreten, erheblich reduziert. Das Speicherverbrauchsdiagramm des festen Bereichs lautet wie folgt:
Wie in der obigen Abbildung gezeigt, nutzt der 450 m+ Platz nur weniger als 250 m, wenn viele Vorlagen absichtlich geöffnet werden, und die Raumnutzungsrate zu niedrig ist, sodass Anpassungen vorgenommen werden müssen.
Zusammenfassen
Die oben genannten sind einige Ideen und einen tatsächlichen Abstimmungsprozess für mich, um meine Myeclipse einzustellen. Im tatsächlichen Gebrauch habe ich einige Anpassungen und Anpassungen gemäß meinen Vorlieben vorgenommen. Die endgültigen Parameter von myeClipse.ini sind wie folgt:
-Vmargs
-Xmx512m
-Xms512m
-Xmn192m
-Xx: permSize = 128m
-Xx: maxpermSize = 128m
-Xx: ReservedCodecachesize = 64 m
Bei dieser Parametereinstellung ist die Reaktionsgeschwindigkeit von myeclipse relativ garantiert und die Häufigkeit verschiedener Verzögerungsverzögerungen erheblich reduziert. Der Nachteil ist, dass der vom ständige Bewohner besetzte Systemspeicher relativ hoch ist. Schüler, die gleichzeitig mehrere MyeClipse eröffnen möchten, können angemessene Anpassungen entsprechend ihren Bedürfnissen und den tatsächlichen Bedingungen vornehmen.
Das Obige dreht sich alles um diesen Artikel, ich hoffe, es wird für das Lernen aller hilfreich sein.