O'Reilly Japan \ -Java Performance Zusammenfassung von Kapitel 3 dieses Buches
Kapitel 1 Einführung \ -Qiita Kapitel 2 Ansatz für Leistungstests \ -Qiita ← Vorheriger Artikel Kapitel 3 Java Performance Toolbox --Qiita ← Dieser Artikel Kapitel 4 Mechanismus des JIT-Compilers \ -Qiita ← Nächster Artikel Kapitel 5 Grundlagen der Speicherbereinigung \ -Qiita
Das Tool ist zunächst ein Tool, das nichts mit Java zu tun hat.
Auf Unix-basierten Systemen sar command, vmstat, iostat //qiita.com/pyon_kiti_jp/items/a44ac6e9229ba7b90c6b) gibt es prstat, In Windows gibt es einen Typ perf.
Die CPU-Auslastung kann in die folgenden zwei Typen eingeteilt werden.
--Benutzerzeit: Die Zeit, zu der die CPU die Anwendung ausführt
Ziel ist es, die CPU-Auslastung zu maximieren und die Ausführungszeit zu verkürzen.
Die Ursache für den Leerlauf der CPU
Umgekehrt möchten Sie möglicherweise die CPU-Auslastung pro Programm begrenzen. In einem solchen Fall kann der CPU-Zyklus für einen bestimmten Zeitraum zwangsweise im Leerlauf sein oder die Priorität kann gesenkt werden.
Sowohl Windows- als auch Unix-Systeme verfügen über einen Mechanismus zum Überwachen von ausführbaren Threads (ohne auf E / A zu warten oder zu schlafen). Dieser Mechanismus heißt Warteschlange ausführen. In Windows wird es als Prozessorwarteschlange bezeichnet und kann mit typeperf angezeigt werden.
C:> typeperf -si 1 "\System\Processor Queue Length"
"05/11/2013 19:09:42.678","0.000000"
"05/11/2013 19:09:43.678","0.000000"
Da die Ausführungswarteschlange die aktuell ausgeführte enthält, muss sie ** 1 oder mehr ** sein. Andererseits enthält die Prozessorwarteschlange von Windows nicht die aktuell ausgeführte, sodass sie ** 0 oder mehr ** ist.
Die Leistung leidet, wenn mehr Threads ausgeführt werden als CPUs vorhanden sind. Unter Unix sollte die Anzahl der Ausführungswarteschlangen == die Anzahl der CPUs festgelegt werden, und unter Windows sollte die Länge der Prozessorwarteschlange 0 sein. Dies ist jedoch kein absolutes Prinzip. Wenn die Länge der Ausführungswarteschlange von Zeit zu Zeit zunimmt, gibt es kein Problem. Wenn andererseits die Ausführungswarteschlange weiterhin zu lang ist, erhöht sich die Belastung des Computers. Sie müssen den Prozess auf einen anderen Computer verteilen oder Ihren Code optimieren.
Es ist ein Hinweis, um zu bestätigen, dass etwas nicht stimmt. Wenn beispielsweise die wMB / s (Anzahl der pro Sekunde geschriebenen Bytes) von "iostat -x" niedrig sind, die w / s (Anzahl der Schreibvorgänge pro Sekunde) jedoch groß ist, ist es möglicherweise besser, die Schreibvorgänge zu kombinieren, um eine bessere Leistung zu erzielen. Im Gegenteil, wenn zu viele Schreibvorgänge vorhanden sind, kann ein Engpass festgestellt werden.
Sie können sehen, ob das System austauscht. Kann die Leistung beeinträchtigen. In vmstat sehen Sie si (Swap In) und so (Swap Out).
Standard-Systemtools sind für die Überwachung des Netzwerkverkehrs nicht ausreichend. Netstat wird auf Unix-basierten Systemen verwendet. Geben Sie perf unter Windows ein.
Für die Netzwerkbandbreite wird nicstat für Unix-basierte Systeme verwendet.
--jcmd: Informationen zum angegebenen Prozess abrufen --jconsole: Sie können das Verhalten der JVM in der GUI sehen. --jhat: Sie können Heap-Dumps mit einem Webbrowser durchsuchen. --jmap: Sie können Heap-Dump- und Speicherinformationen abrufen. --jinfo: Kann JVM-Systemeigenschaften anzeigen --jstack: Den Stapel von Java-Prozessen sichern. --jstat: Zeigt Informationen zum Laden von GC und Klassen an. --jvisualvm: JVM-Überwachung. Kann Heap-Dumps analysieren.
jcmd ${Prozess ID} VM.uptime
Sie können den gleichen Wert wie "System.getProperties ()" sehen (den Wert, den Sie beim Start "-Dhogehoge" angeben).
jcmd ${Prozess ID} VM.system_properties
jinfo -sysprops ${Prozess ID}
jcmd ${Prozess ID} VM.version
jcmd ${Prozess ID} VM.command_line
jcmd ${Prozess ID} VM.flags -all
Wenn Sie -all entfernen, ist es nur das angegebene?
java -XX:+PrintFlagsFinal -version
Für diejenigen mit: = wird ein anderer Wert als der Standardwert angegeben.
Zunächst sehen Sie alle in ↓ eingestellten Werte.
jinfo -flags ${Prozess ID}
Wenn Sie jedes Einstellungselement sehen möchten
jinfo -flag PrintGCDetails ${Prozess ID}
Beim Ändern des Einstellwertes
jinfo -flag -PrintGCDetails ${Prozess ID}
jinfo -flag PrintGCDetails ${Prozess ID}
Sie können die Anzahl der auf der GUI ausgeführten Threads mit jconsole oder jvisualvm überprüfen.
So zeigen Sie den Thread-Stapel an
jstack ${Prozess ID}
jcmd ${Prozess ID} Thread.print
Verwenden Sie jconsole oder jstat. jstat gibt Ihnen auch Informationen zur Kompilierung.
In jconsole kann die Heap-Nutzung grafisch angezeigt werden. Sie können GC mit jcmd ausführen (wie mit jconsole?) jmap gibt einen Überblick über den Heap. jstat bietet verschiedene Ansichten, die zeigen, was der GC tut.
Kann mit jvisualvm (GUI-Tool) oder jcmd oder jmap abgerufen werden Kann mit jvisualvm oder jhat analysiert werden, wenn es sich um ein Standardwerkzeug handelt Es gibt auch ein Drittanbieter-Tool namens Eclipse Memory Analyzer Tool.
Es gibt Sampling-Modus und Instrumented-Modus Da der Abtastmodus den geringsten Overhead aufweist, können die Leistungsmerkmale aufgrund von Profilerinterventionen minimiert werden.
Viele Stichprobenprofiler sind jedoch nicht genau. Zum Beispiel ein Ereignis, das regelmäßig von einem Timer aufgerufen wird und nur den Thread erkennt, der ausgeführt wurde, als der Timer auftrat.
In den meisten Fällen macht die Methode, die zu Beginn des Profilerstellungsergebnisses angezeigt wird, nur 2-3% aus. Wenn Sie also Ihr Bestes tun, um sie doppelt so schnell zu machen, ist sie möglicherweise nur 1% schneller.
Im Gegensatz zum Stichprobentyp können Sie auch sehen, wie oft jede Methode aufgerufen wird und wie oft jede Methode durchschnittlich pro Sekunde aufgerufen wird. Daraus ist beispielsweise ersichtlich, ob die Implementierung beschleunigt oder verbessert werden sollte, um die Anzahl der Ausführungen zu verringern.
Der Profiler im instrumentierten Modus ist möglicherweise hinsichtlich der Leistung ungenau, da der Code, der die Anzahl der Anrufe zählt, im Bytecode neu geschrieben und aufgeladen wird. Beispielsweise kann sich die Größe des Methodencodes erhöhen und es kann festgestellt werden, dass Inlining nicht erforderlich ist (siehe Kapitel 4).
Sampling-Profiler können nur Threads profilieren, die sich an einem sicheren Punkt befinden (Speicher wird zugewiesen), Profiler im instrumentierten Modus jedoch.
Blockierungsmethoden (Wartemethoden wie LockSupport # park und Object # wait ()) verbrauchen keine CPU-Zeit (erhöhen die CPU-Auslastung nicht). Selbst wenn sie oben in den Profilerstellungsergebnissen angezeigt werden, können sie nicht optimiert werden. .. Daher zeigen die meisten Profiler standardmäßig keine blockierten Methoden an.
Bei der Blockierungsmethode können Sie das Verhalten anhand des Ausführungsstatus des Threads anzeigen. Für VisualVM die Registerkarte Threads.
Mit einem nativen Profiler können Sie die JVM selbst profilieren.
Es gibt einen nativen Profiler namens Oracle Solaris Studio. Es heißt Solaris, funktioniert aber auch unter Linux.
Wenn Sie unter Solaris ausgeführt werden, können Sie die interne Struktur des Solaris-Kernels nutzen, um weitere Informationen zu erhalten.
Es gab eine solche Beschreibung. Ich habe keine Solaris-Maschine, daher kann ich sie nicht ausprobieren.
Daten, die nur mit nativen Tools abgerufen werden können, umfassen die für die GC aufgewendete Zeit.
3.4 Java Mission Control Es ist in der kommerziellen Version von Java unter dem Namen jmc enthalten, nicht in der Open Source-Version. Für die Nutzung ist eine kommerzielle Lizenz erforderlich.
JFR
Eine Funktion namens JFR (Java Flight Recorder) ist eine Schlüsselfunktion von jmc. Sie können das Ereignis sehen, z. B. die Thread-Blockierung.
Sie können Ereignisse im Zusammenhang mit der Speicherbereinigung in der JFR-Speicheransicht anzeigen. In den Kapiteln 5 und 6 sollten Sie lesen, während Sie sich darüber im Klaren sind, wie nützlich dieses Tool ist.
Auf der Registerkarte Übersicht der JFR-Codeansicht können Sie die aggregierten Werte für jedes Paket anzeigen. Es ist ungewöhnlich, diese Funktion zu haben.
Sie können auch genaue Informationen zum Sperren der Inflation erhalten. Darüber hinaus können Sie Informationen abrufen, die mit jcmd oder jconsole nicht abgerufen werden können.
Um es zu aktivieren, in der Befehlszeile, die die Anwendung startet
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder
Wird eine Flagge gegeben.
JFR kann zwei Aufnahmemethoden verwenden. Es gibt eine kontinuierliche Aufzeichnung für einen bestimmten Zeitraum, und ein Ringpuffer wird für die kontinuierliche Aufzeichnung verwendet.
Sie können angeben, wie mit Parametern wie -XX: + FlightRecorderOptions = $ {parameter string} aufgezeichnet werden soll.
Optionen werden hier beschrieben [https://docs.oracle.com/javacomponents/jp/jmc-5-4/jfr-runtime-guide/comline.htm#BABJEIEH].
Sie können die laufende JVM auch mit dem folgenden Befehl einstellen (obwohl die Option -XX: + FlightRecorder im Voraus angegeben werden muss).
jcmd ${Prozess ID} JFR.start [Möglichkeit]
Für die kontinuierliche Aufzeichnung können die Daten im Ringpuffer mit dem folgenden Befehl in eine Datei ausgegeben werden.
jcmd ${Prozess ID} JFR.dump [Möglichkeit]
Informationen über die ausgeführte Aufnahme können mit dem folgenden Befehl ausgegeben werden (Übrigens scheinen mehrere Aufnahmen in einem Prozess gemacht werden zu können, daher frage ich mich, ob sie häufig verwendet werden, wenn mehrere Aufnahmen gemacht werden).
jcmd ${Prozess ID} JFR.check [verbose]
Beenden Sie bei ↓ die Aufnahme.
jcmd ${Prozess ID} JFR.stop [Möglichkeit]
JFR kann erweitert werden. Es scheint, dass Sie Ihr eigenes Ereignis erstellen können. Das Sammeln von Ereignissen ist zwangsläufig mit Overhead verbunden. Es gibt jedoch einige Ereignisse, die Sie erhalten möchten, auch wenn Overhead besteht. Überwachen Sie beispielsweise TLAB-Ereignisse (Thread Local Area Buffer) und prüfen Sie, ob Objekte direkt dem alten Bereich zugeordnet sind.
Recommended Posts