JVMD - Java Virtual Machine Diagnostic Best Practices

JVMD Teil 1 - Thread Diagnose Best Practices

Dieser Blog-Eintrag gibt einen Einstieg in das Thema JVMD (Java Virtual Machine Diagnostics) mit dem Oracle Enterprise Manager Cloud Control 12cR3 (FMW Plugin 12.1.0.5). Der Eintrag beleuchtet die Thread-Dump-Analyse-Fähigkeiten von JVMD. Der Eintrag beantwortet folgende Fragen:

Was ist JVMD?

Was kann JVMD?

Wie funktioniert JVMD?

Wie verwende ich JVMD, um Performance Bottlenecks zu finden?

Was ist JVMD?

JVMD steht für Java Virtual Machine Diagnostic und ist eine Komponente des Oracle Enterprise Managers 12c. JVMD ist im aktuellen Release des EM12c voll integriert und wird für viele andere Funktionalitäten verwendet (z. B. Execution Context ID Diagnose).

Was kann JVMD?

JVMD kann, wie der Name schon sagt, Probleme in einer Java VM ermitteln. Hauptsächlich wird es dafür verwendet, JEE-Anwendungen zu diagnostizieren. JVMD ist optimiert für den Oracle WebLogic-Server, kann aber auch für andere JEE-Server wie z. B. JBoss oder WebSphere verwendet werden. JVMD ist darauf ausgelegt, Probleme in Produktionsumgebungen zu finden, d. h. es werden keine Instrumentierungsmechanismen verwendet bzw. die Anwendung muss für JVMD nicht neu gestartet werden. Eine Funktionalität ist die Cross-Tier-Analyse, d.h. Performance-Probleme, die bei Oracle-Datenbank-Zugriffen aus einer JEE-Anwendung erfolgen, werden mit JVMD transparent.

Wie funktioniert JVMD?

JVMD bedient sich eines Betriebssystem-Konzeptes: Thread-Dumps. Mit einem Thread-Dump wird ein Speicherabbild der Server-Java-Threads erzeugt. Dies ist ein oft verwendeter Mechanismus unter Entwicklern, um Probleme innerhalb einer JEE-Applikation zu finden. Dieser Thread-Dump wird z. B. unter einem Linux-Betriebssystem mit dem Befehl kill -3 <PID> erzeugt. Der Kill-Befehl sendet über die Prozess ID ein Signal an den JEE-Prozess, um ein Thread-Abbild in die Standard-Log-Ausgabe zu schreiben. Jeder dieser Thread-Abbilder hat Informationen über den Zustand der Threads und der darin enthaltenen Java-Methoden.

Thread-Zustände können z. B. folgende sein:

NEW - Der Thread wurde erstellt, wird aber noch nicht abgearbeitet

RUNNABLE - Der Thread verwendet CPU und arbeitet Tasks ab

BLOCKED - Der Thread wartet auf einen anderen Thread, um ein Monitor Lock zu erhalten

WAITING - Der Thread wartet auf eine Wait-, Join- oder Park-Methode

etc.

Aus diesen Zuständen werden Performance Bottlenecks oder Locks der Java-Applikationen ermittelt.

Auf die Frage "Warum brauche ich JVMD, wenn ich das auch mit Betriebssystem-Tools kann?", die beim Lesen dieser Zeilen aufkommt, gibt es eine einfache Antwort: "Weil JVMD diesen manuellen Prozess ständig durchführt und so ein vollständiges Bild entsteht." JVMD macht alle zwei Sekunden einen Thread-Dump, speichert diesen im DB-Repository und filtert die unreleveanten Informationen heraus. Man erhält ohne weiteren manuellen Aufwand eine historische und/oder aktuelle Sicht über den Zustand der JEE-Applikation. 

Bild 1: Beispiel einer Ausgabe einer Thread-Dump-Erzeugung

Wie verwende ich JVMD, um Performance Bottlenecks zu finden?

JVMD-Funktionskontrolle

 JVMD ist vollständig in den EM12c integriert. Um JVMD und alle dazugehörigen Komponenten zu installieren, folgt man der offiziellen Dokumentation Link. Nach der Installation und Konfiguration gibt es einen einfachen Weg herauszufinden, ob JVMD korrekt funktioniert. Im EM12c Targets-Menü Middleware auswählen, die Domäne, auf dem der JVMD Agent installiert wurde anklicken, im Navigationsbaum auf der linken Seite den Java Virtual Machine Pool wählen und den gesamten Baum aufklappen. Jeder der WebLogic Server sollte eine _jvm-Endung besitzen. Wenn man nun auf eines der WebLogic-Ziele mit der _jvm-Endung klickt , sieht man im rechten Fenster im unteren Bereich den "Real Time Thread State". Dieser muss einen grünen Pfeil nach oben aufweisen.


Bild 2: Funktionskontrolle JVMD

JVMD Navigation

Java Diagnostic ist in drei Bereiche unterteilt: den JVM-Pool-Bereich, den Einzel-JVM-Bereich und den Realtime-Bereich. Der JVM-Pool-Bereich wird für die Lokalisierung eines Problems und Zuordnung der dazugehörigen JVM verwendet, der Einzel-JVM-Bereich für eine detailierte Untersuchung und eine historische Ursachenanalyse sowie der Realtime-Bereich für die Ursachenanalyse eines aktuellen Problems, wie z. B. ein "hängender" Thread oder Threads mit überdurchschnittlicher Laufzeit.

Beispiel: Analyse einer Applikation, die DB-CPU-Waits verursacht

Dieses Beispiel ist einfach und kann mit der EM12c Standalone-Installation nachvollzogen werden. Es ist nicht nötig, weitere Ziele hinzuzufügen, es wird in diesem Beispiel der OMS selbst analysiert. Dieses Analyse-Beispiel ist hervorragend geeignet, JVMD besser kennen zu lernen, da alle Komponenten verwendet werden.

Schritt 1: Start der Analyse durch die Betrachtung der gesamten Domäne

Auswählen der zu analysierenden Domäne unter Targets -> Middleware (in diesem Fall GCDomain), Öffnen des Baumes Java Virtual Machine Pool auf der linken Seite im Navigationsbereich, Klicken auf den GCDomain_jvmpool. Diese Seite dient als Einstiegsseite und gibt eine Übersicht über den akuellen Stand der WebLogic-JVMs in der Domäne.

Erklärung der Seiten-Komponenten:

Summary: Zeigt an, ob der Thread-Dump-Mechanismus (Poll Enabled) aktiviert ist und in welchem Intervall ein Thread-Dump erzeugt wird.

Availability: Übersicht über die im Pool enthaltenden JVMs, deren Status und die Verfügbarkeit der letzten 24 Stunden.

Incident: Falls die JVMs Systemfehler beinhalten, wird für jeden Fehler ein Incident im EM12c enthaltenden Incident-Manager erzeugt.

Realtime Thread States: In diesem Bereich wird der aktuelle Zustand der JVMs angezeigt, eine genaue Aufschlüsselung der Spaltenbeschreibung erhält man in der Online-Hilfe des EM12c.

Bild 3: JVMD Pool Homepage

Im nächsten Schritt wird überprüft, welche der JVMs ein Performance-Problem hat. Dazu wird auf JVM Performance Diagnostics oben im rechten Fenster geklickt.

Auf der folgenden Webseite befindet sich eine Übersicht des Verhaltens der JEE-Applikationen bezogen auf die jeweiligen JVMs. Dies betrifft sowohl Custom-Applikationen wie auch den WebLogic Server selber bzw. darauf installierte SOA-Suites, WebCenter etc.

Die Seite enthält folgende Komponenten:

Timeline: Welcher Zeitrahmen soll betrachtet werden, Default-Einstellung ist 24 Stunden.

Server States Charts for Selected Period: Eine grafische Ansicht der Thread-States, der CPU-Utilisierung und des Heap-Speicher Verbrauchs.

Filter Options: An dieser Stelle können für alle Top-Activities Filter-Optionen gesetzt werden. Soll ein gesetzter Filter entfernt werden, wird auf die Textbox mit dem Filter geklickt und der Text gelöscht.

Top Activities: In den Top Activities werden alle Komponenten-Statuten angezeigt, die in den Thread Dumps gefunden worden sind. Top Methods sind die Methoden, die am meisten in den Samples der Thread-Dumps gefunden wurden. Die Top Requests enthalten Informationen über HTTP-/HTTPS-Requests. Der Eintrag "None" bedeutet, dass eine Anforderung nicht von einem HTTP(S)-Aufruf stammt. Die Top DBWait Events beschreiben den Zustand der Datenbank während der Ausführung der SQL-Statements. Top SQL beschreibt die am meisten vorgefundenen SQL-Statements. Die Top Databases zeigen an, welche Datenbank verwendet wurde.

JVMs in Pool: Eine detaillierte Ansicht der "Server States Charts for Selected Period" bezogen auf die einzelnen im Pool vorhandenen JVMs.

Bild 4: Auschnitt JVM Pool Performance Diagnostics

In der Übersicht der "Server Stats Charts for Selected Period" wird auf den ersten Blick klar, welche der JVMs den größten Anteil der Thread-Dumps im DBWait-Status verbringt. Bei einem Blick auf den linken Graphen wird erkennbar, dass der größte Teil des Graphen grün ist. Grün steht für DBWait, wie man in der Agenda unter dem Graphen sieht. Daher liegt der Fokus auf den Datenbank-Events im Bereich "Top Activities". In der Tabelle "Top DBWait Events" ist erkennbar, dass verschiedene Wait-Events auf verschiedene Samples verteilt sind. Ein Sample entspricht jeweils einem Zustand, der in einem Thread-Sample gefunden wurde. Zum Beispiel: Der DBWait Event CPU hat 98 Samples, d. h. in 24 Stunden wurden bei 98 Thread-Dumps die Threads im Zustand DBWait-CPU gefunden. Bei einer Sample-Rate von zwei Sekunden in 24 Stunden (3600 * 24 = 86400 Sekunden/zwei Samples pro Sekunde = 43200 Samples) handelt es sich um 0,2 Prozent. Für den DB Event "wait for unread message on broadcast channel" mit 90323 Samples entspricht dies 200 Prozent. Allerdings agiert der Wait-Event "wait for unread message on broadcast channel" als eine Art Listener für die Anwendung und der Thread-Status ist systemspezifisch, daher wenden wir uns dem DBWait-Event-CPU zu. Dieser CPU-Event deutet an, dass die Datenbank auf CPU-Zeit wartet, um die jeweiligen SQL-Statements zu durchlaufen. 

Schritt 2: Filtern der Thread-States, um das Problem zu lokalisieren

Wird nun auf CPU in der Tabelle "Top DBWait Events" geklickt, erscheint ein Pop-Up-Fenster mit zwei Wahlmöglichkeiten. Beim Klicken auf "OK" wird der DBWait-Event CPU als Filter gesetzt und nur die Methoden, TOP SQLs etc. angezeigt, die mit dem DBWait-Event in Verbindung stehen. Beim Klicken auf den Datenbank-Link im Pop-Up öffnet sich die Active Session History-Diagnose der betroffenen Datenbank und erlaubt es,  die betroffene Session weiter zu diagnostizieren. In unserem Fall wählen wir den Filter DBWait-Event CPU durch Klicken des OK-Buttons und erhalten eine Ansicht aller Aktivitäten, die mit dem DBWait-Event CPU im Zusammenhang stehen.


Bild 5: Ansicht nach setzten des DBWait-Event Filters "CPU"

Bild 5 lässt erkennen, dass durch das Setzen des Filters weniger Top-Methoden, Top Requests und Top SQLs dargestellt werden.

Schritt 3: Lokalisieren Java-Methodenaufrufe zum DBWait-Event "CPU"

Um im dritten Schritt zu ermitteln, welche Methodenaufrufe für die DBWaits verantwortlich sind, wird die Methode(n) mit den höchsten Samples aus der Tabelle "Top Activities" ausgewählt.


Bild 6: Ansicht des Methoden-Aufruf-Stacks für den DBWait-Event CPU

In dieser Ansicht werden die Methodenaufrufe nach dem verursachenden Methodenaufruf durchsucht oder der ausgewählte Methodenaufruf wird als Filter gesetzt. Im Call-Stack ist zu erkennen, dass die Hauptursachen für das DBWait die Methodenaufrufe oracle.sysman.emas.mda.fwk.dal.RawQueryImpl->update und oracle.sysman.emas.mda.fwk.dal.RawQueryImpl->insert sind. Beide Aufrufe sind EM12c-eigene Methoden zur Verwaltung des Enterprise Managers. Durch Drücken des "OK" Buttons wird ein Filter auf diese Methoden gesetzt. Es werden auschließlich die SQL-Statements angezeigt, die durch diese Methodenaufrufe ausgeführt wurden. 

Bild 7: Filtern nach DBWait-Event und Methodenaufruf zur Vorbereitung der SQL-Analyse

Schritt 4: Analyse der verursachenden SQL-Statements

In diesem Fall sind es Fünf SQL-Statements, die für den DBWait-Event CPU verantwortlich sind. Durch Auswählen der SQL-Statements erhält man das detaillierte Statement zur Ansicht.


Bild 8: Anzeige der SQL-Details

Wenn das Datenbank Diagnostic Pack für den Enterprise Manager lizensiert wurde, kann durch Klicken auf den Datenbank-Link im SQL-Detail-Fenster der SQL-Analyzer aufgerufen werden. Diese Datenbank-Analyse-Funktion ermöglicht eine detallierte Betrachtung des SQL-Statements.


Bild 9: Aufrufen der SQL Details im Datenbank SQL-Analyzer

Fazit

Dieser Blog-Eintrag gibt einen Einstieg in die Analyse von Performance Bottlenecks innerhalb von JEE-Applikationen mittels JVMD. Das aufgezeigte Beispiel beschreibt die Ursachenermittlung von DBWait-Events. Das weitere Vorgehen, um z. B. Locks oder hohe CPU-Auslastungen zu finden, ist analog zu dem obigen Beispiel.

JVMD bietet noch eine Reihe weitere Funktionalitäten, wie z. B. Echtzeit-Thread-Analyse, Erzeugen von Diagnostic Snapshots, Aufnahme eines detaillierten Thread-Snapshot oder das große Thema Memory-Leak-Analyse. Alle diese Themen werden in nachfolgenden Blogs detailliert beleuchtet. Dieser erste Eintrag in der JVMD-Reihe soll einen Einstieg in das Thema bieten.

Kommentare:

Senden Sie einen Kommentar:
  • HTML Syntax: Ausgeschaltet
About

Dieser deutschsprachiger Blog behandelt alle Themen rund um Oracle Middleware Management mit dem Oracle Enterprise Manager 12c.

Search

Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute