Freitag Mai 02, 2014

JVMD Teil 2 - Java Virtual Machine Diagnostic Best Practices

JVMD Teil 2 - Echzeit-Diagnose, Thread- und Diagnostic-Threadshots 

Einleitung

Dies ist der zweite Teil der Reihe "Java Virtual Machine Diagnostic" Best-Practices. In diesem Teil wird näher auf die Komponenten Echtzeit-Diagnose (Real-Time-Analysis) und Snapshots eingegangen. Die Echtzeit-Analyse ist für einen Einblick in die aktuellen Vorgänge innerhalb der JVM. Snapshot bedeutet in diesem Zusammenhang, dass die Informationen für eine spätere Analyse verwendet werden können. Die Snapshots werden in zwei Bereiche unterteilt, der Thread-Snapshot und der Diagnostic-Snapshot. Der Thread-Snapshot bietet sehr detaillierte Offline-Thread-Diagnose-Möglichkeiten in einem begrenzten Zeitraum (unter Einer Minute). Der Diagnostic Snapshot ermöglicht dies ebenfalls, allerdings nicht so detailliert und für einen größeren Zeitraum (mehrere Stunden).

So können durch diese drei Möglichkeiten verschiedene Fälle abgedeckt werden, zum Beispiel:

Das System hat akute Probleme und "hängt" durch zum Beispiel einen Thread-Lock -> Einsatz von Echtzeit-Diagnose (Real-Time-Analysis)

Ein Business-Critical-System hat akute Probleme und "hängt" durch zum Beispiel einen Thread-Lock. Ein Neustart muss sofort durchgeführt werden -> Einsatz von Thread-Snapshots

Das System hat Performance-Schwierigkeiten die unregelmäßig auftreten, die Lösung: Eine Langzeit-Analyse -> Einsatz von Diagnostic-Snapshots

Echtzeit-Diagnose

Die Echtzeit-Diagnose ermöglich Einsicht in den aktuellen Zustand der JVM. Mögliche Use-Cases sind:

Identifizierung langlaufender Threads (IO,CPU,RMI), Dead-Locks, langlaufende SQL-Statements etc.

Wie kommt man zur Echtzeit Diagnose?

Es gibt mehrere Möglichkeiten zur Echtzeit-Diagnose (Active Threads) zu gelangen:

a.) Über das Hauptmenü: Targets -> Middleware -> Bei Anzeige aller Middleware-Ziele, Aufklappen der Domäne  -> Aufklappen *_jvmpool -> *_jvm Auswählen -> "Live Thread Analysis" klicken

b.) Über das WebLogic-Server-Menue: Kontext Menü -> Diagnostic -> "Live Thread Analysis"

c.) Über die Suche: Suchen jvm -> Mauszeiger auf gewünschte JVM -> Rechte Maustaste (Kontext-Menü) -> "Live Thread Analysis"

d.) Über "All-Targets: Im Baum Middleware, Java Virtual Machine auswählen -> Mauszeiger auf gewünschte JVM -> Rechte Maustaste (Kontext-Menü) -> "Live Thread Analysis"

Welche Möglichkeiten bietet die Echtzeit-Diagnose?

Durch das Öffnen der "Live Thread Analyse" Seite wird eine Momentaufnahme des aktuellen Thread-Status gespeichert und angezeigt. Diese Ansicht bleibt so lange erhalten, bis die Seite manuell Erneuert wird. Dieser Refresh kann durch Einstellen des Auto-Refresh auf 30 Sekunden, 1 Minute oder einem eigenen Zeitinterval fixiert werden. 

Die Seite unterteilt sich in die Bereiche: JVM, JVM Threads, Thread Details, Thread Info und Thread Stack. Im Bereich JVM ist eine Auflistung des allgemeinen Zustand der JVM zum Zeitpunkt der Anforderung der Echtzeitanalyse. Der Bereich JVM Threads zeigt alle aktiven Threads an, die zum Zeitpunkt der Anforderung in der JVM waren. Durch setzten des Häkchens "Show Idle Threads" werden auch die Idle-Threads dargestellt. In der Tabellenansicht der JVM Threads werden folgende Informationen dargestellt: Thread Name, Request (Welcher HTTP Request hat den Thread erzeugt), Laufzeit, OS Process ID und Sub-Process-ID, momentan ausgeführter Methodenaufruf, Dateiname der Java Datei, Line of Code, Thread-Status des aktuellen Threads, Wait-On, Art des Wait-Requests, Lock Held, ECID (siehe Blog-Eintrag über ECID) und RID.

Die Relationship ID (RID) gibt an in welcher Position des Aufruf-Baums eines Multi-Threads sich die Sub-Threads befinden. Die erste Nummer ist üblicherweise Null, eine Eins signalisiert, dass es nicht möglich ist die anderen Sub-Tasks zuzuordnen.

Beispiel:

Root Thread, ECID = 007, RID = 0

Sub Task, ECID = 007, RID = 0:1

Zweite Sub-Task, ECID = 007, RID = 0:1:1

Paralleler Task vom Zweiten Sub-Task, ECID = 007, RID = 0:1:2

In den Thread Details wird angezeigt welchen Thread Stack der ausgewählte Thread enthält. Der Thread Stack enthält die Aufruf-Hierarchie des ausgewählten Threads. Es werden alle Methodenaufrufe angezeigt, die in dem ausgewählten Thread durchgeführt wurden. Der Bereich Thread Info enthält detaillierte Informationen zum ausgewählten Thread. Es handelt um die gleichen Informationen wie in der der Tabelle JVM Threads in einer anderen Darstellungsweise. Die Unterscheidung zur Tabellendarstellung liegt in der weiterführenden Verarbeitung der Einträge. Zum Beispiel sind die Parameter State, ECID, State, Wait Request und Lock Held auswählbar. Bei der Auswahl eines Parameter-Links wird eine detailliertere Diagnose aufgerufen. Wählt man z.B. das im Parameter Wait-Request enthaltende SQL-Statement auf, wir man automatisch auf die SQL-Diagnose der Datenbank weitergeleitet.

Bild 1: Ansicht der Real-Time-Analyse Seite

Die Tabelle des Thread Stack ermöglicht es den Methodenaufruf, Tiefe des Aufrufs innerhalb des Threads, Dateiname in der die Methode aufgerufen wird und die Line-of-Code in der sich der Methodenaufruf befindet. Diese Informationen helfen den Entwicklern exakt die Stelle zu lokalisieren, in der die Methode aufgerufen wird. Diese Funktion ist sehr hilfreich im Debuggen des Quellcodes. 

Der Button "Browse Local Objects" ermöglicht das Anzeigen aller Parameter, die im Aufruf der Methode übergeben worden sind. Wählt man eine Methode aus und drückt den Button werden alle Object Parameter angezeigt. Diese Funktion erlaubt das Identifizieren eines einzelnen Request inklusive Parameter, dadurch können die z.B. die fachlichen Eingaben ermittelt werden, die dazu geführt haben das ein Fehler auftritt.

Eine wichtige Information an dieser Stelle: Die Abfrage der Parameter (Browse Local Object Button) erfolgt in Echtzeit. Das heißt wenn das Objekt zur Zeit der Abfrage im Speicher nicht mehr vorhanden ist, kann es auch keine Parameter anzeigen. Aus diesem Grund eignet sich diese Methode zum Auffinden von Langläufern und nicht um Objekte zu Analysieren die nur für kurze Zeit im Speicher vorhanden sind. Aus diesem Grund ist im oberen, linken Bereich des Pop-Up-Fensters eine Export-Funktion, die es erlaubt die ermittelten Informationen für eine nachgelagerte Analyse in eine Datei zu Exportieren.

Snapshots

Wie in der Einleitung bereits beschrieben existieren zwei Snapshot-Funktionen: Thread Snapshot und Diagnostic Snapshot. Der Thread Snapshot eignet sich für die sehr detaillierte Kurzzeitanalyse und der Diagnostic Snapshot für die eine Langzeitanalyse bei z.B. länger auftretenden Performance-Engpässen.

Thread Snapshot

Um einen Thread Snapshot zu erzeugen navigiert man in das WebLogic Server bzw. WebLogicServer_Name_jvm Kontext-Menü und wählt den Punkt Thread Snapshot aus. Die nachfolgende Webseite enthält eine Tabelle mit den bereits erzeugten Thread Snapshots. Die Snapshots können gelöscht, analysiert, exportiert oder erzeugt werden. Wichtig: In dieser Tabelle werden sowohl die Thread Snapshots wie auch die Diagnostic Snapshots angezeigt. Die Unterscheidung zwischen diesen beiden Typen erfolgt über die Duration (Dauer) der Snapshots. Alles im Sekunden-Bereich deutet auf einen Thread Snapshot und alles im Stunden/Tage-Bereich auf einen Diagnostic Snapshot.

Um einen Thread Snapshot zu erzeugen drückt man den "Create"-Button und erhält auf der nachfolgenden Seite die Aufforderung Parameter einzugeben. Die Parameter bedeuten folgendes:

  • Poll Intervall (ms): Gibt die zeitlichen Abstände zwischen den Thread-Dumps an. Je geringer das Interval, desto detaillierter die Informationen. Das voreingestellte Intervall von 300 ms ist Ideal. Eine Verringerung erzeugt zu viel Last auf dem überwachten System.
  • Poll Duration (sec): Gibt an wie lange der Snapshot-Vorgang durchgeführt werden soll. Hier empfiehlt es sich dies nicht länger als 30 Sekunden durchzuführen, da ansonsten zu viel Last auf dem überwachten System erzeugt wird.
  • Desciption: Eine Möglichkeit Kommentare für den Erzeuger des Thread Snapshots einzutragen
  • Thread Detail: Gibt an ob Detaillierte Angaben über die Threads gespeichert werden sollen. Dieser Parameter sollte immer gesetzten bleiben, da ansonsten keine Informationen über den Aufruf-Stack der Methoden gesammelt werden.
  • Try Changing Threads: Bei schnell wechselnden Threads, kann es sein das während der Snapshot Phase der Trace den Zustand ändert. Mit diesem Parameter wird der Thread im aktuellen Zustand gehalten und der Snapshot wird erzeugt.
  • Include Network Waits: Normalerweise werden Threads im Status Network Wait nicht aufgezeichnet. Sollte dies gewünscht sein, muss man den Haken an dieser Stelle setzten.
  • All Threads: Es werden alle Threads aufgezeichnet, auch die nicht Aktiven.
  • Allow Trace Interrupt: Angeblich soll man den Trace unterbrechen können. Ich habe es bis jetzt allerdings nicht geschafft das Erzeugen des Snapshots zu unterbrechen auch nicht bei gesetzten Flag.

Die Analyse der vorhandenen Snapshots erfolgt nach dem gleichen Muster, wie im ersten Teil dieser Serie erklärt.

Tipp: Die Korrelation der Datenbank Informationen kann nur so lange erfolgen, wie diese Daten in den Datenbank Tabellen (z.B: V$SESSION) vorhanden sind. Daher sollte man entweder die Analyse zeitnah durchführen oder mit dem DBA's eine längere Aufbewahrungszeit in diesen Tabellen vereinbaren. Dies erfolgt mit der PL/SQL Prozedur DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS, eine Beschreibung über die Parameter der Prozedur steht in der Datenbank Dokumentation.

Bild 2: Snapshot Analyse zu einem späteren Zeitpunkt

Diagnostic Snapshot

Beim Diagnostic Snapshot wird ein längerer Diagnosezeitraum für die spätere Analyse gespeichert. Da bei der JVM-Diagnose eine große Datenmenge anfällt, die im Enterprise Manager Cloud Control Repository gespeichert wird, werden die historischen Daten der JVM-Analyse einen begrenzten Zeitraum vorgehalten. Um die Daten für einen bestimmten Zeitraum zu konservieren, wird die Funktion Diagnostic Snapshot verwendet.

Voraussetzungen für einen JVMD Diagnostic Snapshot ist ein installierter, konfigurierter und laufender JVMD Agent auf dem Ziel. Nach Auswahl der gewünschten WebLogic Domäne navigiert man auf den "Java Virtual Machine Pool" in der Target Navigation, wählt den gewünschten Server (*_jvm) aus, klickt auf JVM Performance Diagnostics. Auf der JVM Performance Diagnostics Seite befindet sich auf der rechten, oberen Seite der Button "Create Diagnostic Snapshot".

In dem sich nachfolgend öffnen Dialog wird der gewünschte Diagnostic Zeitraum, die berücksichtigten Ziele und der Diagnose Typ angegeben und bestätigt. Der Snapshot wird im Hintergrund durchgeführt und steht anschließend zur Verfügung. Um einen gespeicherten Snapshot zu öffnen, navigiert man wie beschrieben auf das JVMD Target (*_jvm) und wählt aus dem Kontext-Menü den Punkt "Thead Snapshots" aus. In der angezeigten Tabelle sind alle Thread und Diagnostic-Snapshots aufgelistet. Nach Auswahl des gewünschten Snapshots und drücken des Details-Button am oberen Rand der Tabelle wird die Analyse-Komponente aufgerufen. Das detaillierte Vorgehen bei einer Analyse wird im ersten Teil der Serie "JVMD" erklärt.

Bild 3: Erzeugen eines Diagnostic-Snaphots

Fazit

Die Echtzeit-Analyse und die Snapshot-Funktionalität ermöglichen eine sehr genaue Analyse der JVM-Umgebung. Diese Analyse kann sofort oder zu einen späteren Zeitpunkt durchgeführt werden. Ein weiterer Vorteil der Snapshot-Funktionalität ist eine mögliche Übergabe der Analyse-Daten an z.B. einen Entwickler, der dadurch ein Debugging mit Metriken aus dem produktiven Betrieb durchführen kann.


About

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

Search

Archives
« August 2015
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
31
      
Heute