Freitag Jan 24, 2014

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.

Donnerstag Dez 19, 2013

ECID - Execution Context ID im Enterprise Manager Cloud Control

Der folgende Artikel beschreibt die Oracle Execution Context ID kurz ECID und wie der Oracle Enterprise Manager Cloud Control 12c R3 die ECID für Diagnose von Applikations-Problemen verwenden kann.

Was ist die Execution Context ID (ECID)?

Die ECID ist eine globale, eindeutige Kennzeichnung eines initialen Requests in der Fusion Middleware. Diese ID wird an alle nachfolgenden Oracle-Instanzen unverändert übergeben und ermöglicht eine durchgehende Verfolgung über verschiedenen Oracle-Instanzen. Die ECID ist sehr hilfreich beim Auffinden von Problemen im gesamten Oracle Stack.


Die ECID ist keine neues Feature der aktuellen FMW-Version, sondern existiert schon seit dem Oracle Application Server 10g (OC4J). Die ECID ist nicht nur im Oracle FMW-Kontext sichtbar, sondern auch in Oracle-Datenbanken (z. B. in den V$SESSION oder V$ACTIVE_SESSION_HISTORY View)


Die ECID ist ein Feature des Oracle Fusion Middleware Dynamic Monitoring Service (DMS). Der DMS ermöglicht der Oracle FMW die Bereitstellung von Monitoring-Daten, um diese z. B. im Oracle Enterprise Manager weiterzuverarbeiten. Der DMS wird vom Oracle WebCache, Oracle HTTP Server, Oracle Application Development Framework (ADF), Weblogic Diagnostic Framework (WLDF) und JDBC verwendet.


Wie kann man die ECID verwenden, um z. B. ein Performance Bottleneck innerhalb einer komplexen Applikation zu finden?


Man kann z. B. manuell in den Log-Dateien bzw. Datenbanken der verschiedenen beteiligten Komponenten suchen und diese in zeitlichen Ablauf stellen. An den Laufzeiten der beteiligten Threads lässt sich erkennen, an welcher Stelle die meiste Zeit in der Verarbeitung des Requests verbraucht wird.

ECID Performance Analyse mit dem Oracle EM12c

Wenn man den Oracle Enterprise Manager Cloud Control 12c im Einsatz hat, kann man die Request-Verfolgung über das GUI im Kontext mit wenigen Klicks grafisch darstellen. Der nachfolgende Artikel gibt eine Einführung, wie man die ECID im EM12c verwenden kann, um Laufzeiten der einzelnen Threads im Kontext des Requests darzustellen.  


Bevor die ECID verwendet werden kann, müssen folgende Voraussetzungen erfüllt sein:

  1. Das Ziel muss eine Fusion Middleware Installation sein, nur ein Stand-Alone WebLogic-Server Domäne erfüllt die Voraussetzungen nicht. Grund hierfür sind die sogenannten Java Requested Files (JRF). Diese sind nicht in einer WLS Stand-Alone Installation vorhanden. Man kann die JRF Files auf einen WebLogic Server hinzufügen indem man z. B. das Application Development Framework (ADF) hinzuinstalliert.
  2. Die FMW-Installation muss JRF-Enabled sein, dies kann man prüfen, indem man im EM12c in der gewünschte FMW-Instanz (Domäne) unter dem WebLogic-Server/Domain-Menü -> Target Setup -> die Monitoring Configuration aufruft. Der Parameter "Is JRF Enabled?" muss auf "true" stehen.


Bild 1: Überprüfung JRF Enabled = true


Das folgende Beispiel wurde auf einer EM12c R3-Installation mit dem FMW-Plug-In 12.1.0.5 erstellt.


Auswahl der ECID zur detaillierten Analyse
Die Auswahl der ECID erfolgt unter dem Menüpunkt Targets -> Middleware -> Middleware Features -> Request Instance Diagnostics dann auf den Button Select ECID drücken.


In dem Suchfenster können zahlreiche Einschränkungskriterien eingegeben werden. Es empfiehlt sich nicht nur den Suchzeitraum, sondern auch die Ziele einzuschränken. Durch Drücken des Buttons Search wird die Suchanfrage abgesendet. Die Ergebnisse können durch Drücken auf die jeweilige Spaltenüberschrift sortiert werden z. B. nach der Thread-Laufzeit in Millisekunden.



Bild 2: Suche nach einer ECID, Auswahl nach der längsten Laufzeit


In diesem Fall wähle ich die ECID mit der längsten Laufzeit (8 Sekunden) aus und drücke Select.


Im nachfolgenden Bild sind alle Threads aufgelistet, die zu der gewählten ECID gehören. Wie man sieht, handelt es sich hierbei um eine Kombination von verschiedenen Threads. Mann kann jetzt z. B. die Spalte Duration (ms) nach den Laufzeit ordnen,  die verwendeten SQL-Statements einsehen oder nach CPU-Auslastung, Speicherverbrauch, Garbage-Collection etc. ordnen, um Performance-Bottlenecks aufzudecken.


!TIP: Das Ergebnisfenster, in dem die Threads dargestellt werden, bekommt teilweise erst durch das Vergrößern einen Scroll-Balken, daher kann es gut sein, dass zu der ECID mehr Threads gehören, als auf den ersten Blick erscheinen. Am besten mit der Maus einen Thread fokussieren und dann Scrollen oder die Targets Tabelle vergrößern.



Bild 3: Anzeige der Threads, die zu der ausgewählten ECID gehören


Wenn man das SQL von einem bestimmten Thread sehen möchte, klickt man auf das SQL Statement in der Tabelle und erhält die nachfolgende Ansicht:



Bild 4: Detaillierte SQL-Statment Ansicht


Eine detaillierte Sicht auf den Aufrufpfad (Stack Thread) erhält man, indem man den gewünschten Thread in der Tabelle auswählt und im unteren Bereich der Webseite Thread Stack Details auswählt. Diese Details stellen den Aufrufpfad des Threads dar und dienen dazu, z. B. die exakte Position innerhalb des eignen JAVA-Codes zu ermitteln, an dem der Methoden-Aufruf initiiert wird. Es werden in der Detailansicht der Dateiname und die Zeilennummer des Methodenaufrufs angezeigt. Dieses schließt die Systemaufrufe mit ein, es ist aber möglich anhand der Dateinamen zu unterscheiden, ob es sich um einen Systemaufruf oder eine eigene Klasse handelt.



Bild 5: Methoden-Aufruf-Hierachie Darstellung


Der untere Bereich der Request Instance Diagnostic-Seite enthält zusätzliche Informationen bezüglich des Systemverhaltens während der Abarbeitung der ECID. Das Instance Sample z. B. zeigt an in welchem Zustand der Threads (bzw. die Sub-Threads) während der Messung war.
Die Zustände haben folgende Bedeutung:

  • RMI Wait - der Thread wartet auf eine RMI event z. B. auf einen nicht TCP-basierenden Aufruf
  • IO Wait - der Thread wartet auf IO z. B. Festplattenzugriff
  • Network Wait - der Thread wartet auf Netzwerkzugriff z. B. auf eine Aktion auf einer Webseite
  • DB Wait - der Thread wartet auf eine Datenbank-Aktion z. B. das Beenden eines SQL-Statements
  • Runnable - der Thread belegt die CPU und bearbeitet einen Task (Er kann aber auch im Wartezustand sein, z. B. durch eine Ressourcenverteilung des Betriebssystems)
  • Lock - der Thread belegt eine Ressource und hindert somit andere Threads daran, diese Ressource zu verwenden

Wählt man den Reiter Request Aggregate aus, erhält man die Systemzustände der ausgewählten Metrikgruppen während der Laufzeit des ECID-Threads. Zum Beispiel kann man sich anschauen, wie sich der Host verhalten hat, während die ECID abgearbeitet wurde. Dies ist sehr hilfreich, um Performance-Engpässe zu finden, die nicht unbedingt durch die FMW direkt verursacht wurden. Ein Beispiel hierfür sind Host-Operationen, die von externen Progammen auf dem FMW-Host durchgeführt werden und dadurch der FMW-Applikation Ressourcen entziehen.



Bild 6: Aggregate Zustände der Datenbank wärend der Abarbeitung der ECID


Wählt man der Reiter JVM Metrics werden die JVM Metriken und Threads-States in der gesamtem Laufzeit der ECID angezeigt. Dies dient der Übersicht und ist eine gute Stelle, um eine detaillierte Einsicht in das Verhalten der JVM innerhalb der ECID-Laufzeit zu bekommen. In dem  gezeigten Beispiel sieht man, dass die Anzahl der Threads im DB-Wait-Status linear ansteigen. In diesem Fall lohnt es sich detaillierter in die SQL Statements zu schauen und diese ggf. zu tunen.



Bild 7: Thread Zustände während der ECID Abarbeitung


Möchte man sich einen einzelnen Thread aus der Target-Liste anschauen, um z. B. detaillierte Informationen über die Gründe der langen Laufzeit zu bekommen, wählt man diesen aus und klickt auf Thread Sample Inspector im unteren Bereich der Webseite. Der Thread Sample Inspector zeigt viele Informationen zu dem ausgewählten Thread an.

!TIP: Mann kann den Aufruf-Stack auch in Excel exportieren, um diesen z. B. an Entwickler zu geben, wenn diese keinen direkten Zugriff auf das System haben.



Bild 8: Single Thread Detail-Ansicht


Wenn man z. B. einen Thread hat, der einen DB Wait-Status hat, kann man durch klicken auf die SQL_Id in die Anzeige der SQL-Details der Datenbank navigieren, um z. B. mittels SQL-Worksheet das Statement zu tunen.



Bild 9: SQL-Ansicht in der Datenbank-Diagnose


Zusammenfassung
Die ECID-Funktionalität ist eine performante und durchgängige Möglichkeit, um Probleme innerhalb der Oracle-Welt schnell und mit geringem Aufwand zu finden. Durch das Verwenden des EM12c ist dies auf grafischer Ebene und mit geringen Aufwand möglich. Der EM12c führt alle beteilligten Komponenten zusammen und ermöglicht ein durchgängiges Konzept, um mit Problemen innerhalb von Threads umzugehen.




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