Mittwoch Apr 29, 2015

Debugging des Autodiscovery

Die Autodiscovery Fähigkeiten des Enterprise Managers 12c sind ein mächtiges und hilfreiches Werkzeug wenn es darum geht große, weit verteilte und/oder unbekannte Umgebungen schnell und effizient als Ziele in den Enterprise Manager zu integrieren.
Voraussetzung für ein ordnungsgemäßes Funktionieren des Autodiscovery ist allerdings, dass die Installationen der Oracleprodukte, die Oracle Homes und ganz besonders das Installer Repository "sauber" und frei von "Altlasten" sind.
Bei Entwicklungs- und Testumgebungen, die häufigen Wechseln unterliegen aber auch bei gewachsen Produktivumgebungen trifft dies nicht immer zu. Der normale Betrieb wird dadurch nicht weiter beeinflusst. das Autodiscovery kann an solchen Fehlkonfigurationen allerdings scheitern ohne das eine sinnvolle Fehlermeldung weiterhilft.

Zum Glück beruht das gesamte Autodiscovery, wie auch nahezu alle anderen Aktionen des Agent, auf Perl-Scripten, die auch direkt gestartet werden können und in diesem Fall etwas gesprächiger sind. Durch diese Hinweise und die schnelleren Turnaroundzeiten durch das direkte Ausführen, lässt sich meist schnell die Ursache finden an der das Autodiscovery scheitert.

Die vom Agent aufgerufenen Scripte finden sich in den Verzeichnissen unterhalb des Verzeichnisses <$AGENT_HOME>/plugins.
Welche Scripte vom Autodiscovery verwendet werden (können) und was sie finden ist im jeweiligen Verzeichnis in einer Datei namens "autodiscoverable.lst" vermerkt. Mit

cd $AGENT_HOME/plugins
find ./ -name autodiscoverable.lst

kann man sich eine Übersicht verschaffen.

Der Autodiscovery-Vorgang des EM startet mit dem Aufruf Scripts "OracleHomeDiscovery.p", welches eine XML-Datei mit allen gefunden Oracle Homes und deren Parameter zurück gibt.
Das Script liest nur aus und ändert nichts, kann also gefahrlos ausgeführt werden um in einem ersten Schritt zu klären, ob alle vorhanden Homes gefunden und richtig erkannt werden.
export AGENT_HOME=/opt/oracle/em/agent12104
export LD_LIBRARY_PATH=$AGENT_HOME/core/12.1.0.4.0/lib

$AGENT_HOME/core/12.1.0.4.0/perl/bin/perl -I$AGENT_HOME/core/12.1.0.4.0/sysman/admin/scripts/ \
-I$AGENT_HOME/core/12.1.0.4.0/perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi \
$AGENT_HOME/plugins/oracle.sysman.oh.discovery.plugin_12.1.0.4.0/OracleHomeDiscovery.pl 

Die Ausgabe sieht dann (beispielhaft) so aus:

<Targets>
    <Target TYPE="oracle_home" NAME="OraDB12Home2_24_em12c.demo.com" DISPLAY_NAME="OraDB12Home2_24_em12c.demo.com">
        <Property NAME="HOME_TYPE" VALUE="O" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/db/db121020" />
        <Property NAME="INVENTORY" VALUE="/opt/oracle/oraInventory" />
    </Target>
    <Target TYPE="oracle_home" NAME="OracleHome_31_em12c.demo.com" DISPLAY_NAME="OracleHome_31_em12c.demo.com">
        <Property NAME="HOME_TYPE" VALUE="O" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/mw/12.1.3.0.0" />
        <Property NAME="INVENTORY" VALUE="/opt/oracle/oraInventory" />
    </Target>
    <Target TYPE="oracle_home" NAME="Oracle_BI11_3_em12c.demo.com" DISPLAY_NAME="Oracle_BI11_3_em12c.demo.com">
        <Property NAME="HOME_TYPE" VALUE="O" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/em/oms12104/oms12104/Oracle_BI1" />
        <Property NAME="INVENTORY" VALUE="/opt/oracle/oraInventory" />
        <Property NAME="MW_HOME" VALUE="/opt/oracle/em/oms12104/oms12104" />
    </Target>
    <Target TYPE="oracle_home" NAME="WebLogicServer10_3_6_0_em12c.demo.com_2346" DISPLAY_NAME="WebLogicServer10_3_6_0_em12c.demo.com_2346">
        <Property NAME="HOME_TYPE" VALUE="W" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/em/oms12104/oms12104/wlserver_10.3" />
        <Property NAME="MW_HOME" VALUE="/opt/oracle/em/oms12104/oms12104" />
    </Target>
    <Target TYPE="oracle_home" NAME="agent12c1_10_em12c.demo.com" DISPLAY_NAME="agent12c1_10_em12c.demo.com">
        <Property NAME="HOME_TYPE" VALUE="O" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/em/agent12104/core/12.1.0.4.0" />
        <Property NAME="INVENTORY" VALUE="/opt/oracle/oraInventory" />
    </Target>
    <Target TYPE="oracle_home" NAME="common12c1_22_em12c.demo.com" DISPLAY_NAME="common12c1_22_em12c.demo.com">
        <Property NAME="HOME_TYPE" VALUE="O" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/em/oms12104/oms12104/oracle_common" />
        <Property NAME="INVENTORY" VALUE="/opt/oracle/oraInventory" />
        <Property NAME="MW_HOME" VALUE="/opt/oracle/em/oms12104/oms12104" />
    </Target>
    <Target TYPE="oracle_home" NAME="oms12c1_4_em12c.demo.com" DISPLAY_NAME="oms12c1_4_em12c.demo.com">
        <Property NAME="HOME_TYPE" VALUE="O" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/em/oms12104/oms12104/oms" />
        <Property NAME="INVENTORY" VALUE="/opt/oracle/oraInventory" />
        <Property NAME="MW_HOME" VALUE="/opt/oracle/em/oms12104/oms12104" />
    </Target>
    <Target TYPE="oracle_home" NAME="webtier12c1_23_em12c.demo.com" DISPLAY_NAME="webtier12c1_23_em12c.demo.com">
        <Property NAME="HOME_TYPE" VALUE="O" />
        <Property NAME="INSTALL_LOCATION" VALUE="/opt/oracle/em/oms12104/oms12104/Oracle_WT" />
        <Property NAME="INVENTORY" VALUE="/opt/oracle/oraInventory" />
        <Property NAME="MW_HOME" VALUE="/opt/oracle/em/oms12104/oms12104" />
    </Target>
</Targets>

Die Informationen bezieht das Script im wesentlichen aus dem Installer-Repository (.../oraInventory/ContentsXML/inventory.xml), sollte das Script also Fehlermeldungen ausgeben oder nicht alle erwarteten Homes finden, dann ist die Ursache meistens ein inkonsistentes Installerrepository (z.B wenn Installationen gelöscht anstatt deinstalliert wurden).

Nach dem initialen Script zum Discovern der OracleHomes werden im Anschluss produktspezifische Scripte aufgerufen. Für Weblogic Domänen ist dies

export AGENT_HOME=/opt/oracle/em/agent12104
export LD_LIBRARY_PATH=$AGENT_HOME/core/12.1.0.4.0/lib
export DISC_ROOT=$AGENT_HOME/plugins/oracle.sysman.emas.discovery.plugin_12.1.0.7.0

$AGENT_HOME/core/12.1.0.4.0/perl/bin/perl -I$AGENT_HOME/core/12.1.0.4.0/sysman/admin/scripts/ \
-I$AGENT_HOME/core/12.1.0.4.0/perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi \
$AGENT_HOME/plugins/oracle.sysman.emas.discovery.plugin_12.1.0.7.0/scripts/wls/autodisco/fmw_discover.pl

Der Aufruf sollte eine XML-Datei aller erkennbaren Domänen liefern die diesem Beispiel ähnelt.

<Targets>
  <Target TYPE="weblogic_domain" NAME="/base_domain" DISPLAY_NAME="base_domain" ON_HOST="em12c.demo.com">
    <Property NAME="DOMAIN_HOME" VALUE="/opt/oracle/mw/12.1.3.0.0/domains/base_domain"/>
    <Property NAME="version" VALUE="12.1.3.0.0"/>
    <Property NAME="Protocol" VALUE="t3s"/>
    <Property NAME="Port" VALUE="7002"/>
    <Property NAME="MachineName" VALUE="em12c.demo.com"/>
  </Target>
  <Target TYPE="weblogic_domain" NAME="/Farm_GCDomain/GCDomain_em12c.de.oracle.com_7102" DISPLAY_NAME="GCDomain" ON_HOST="em12c.demo.com">
    <Property NAME="DOMAIN_HOME" VALUE="/opt/oracle/em/oms12104/gc_inst/user_projects/domains/GCDomain"/>
    <Property NAME="version" VALUE="10.3.6.0"/>
    <Property NAME="Protocol" VALUE="t3s"/>
    <Property NAME="Port" VALUE="7102"/>
    <Property NAME="MachineName" VALUE="em12c.demo.com"/>
  </Target>
</Targets>

Hierzu werden erst wieder die passenden OracleHomes gesucht (mit der gleichen Routine, die auch das initiale Script verwendet. Wenn das also schon nicht sauber durchläuft, dann läuft dieses Script auch nicht sauber!) und dann in diesen Homes die Datei "domainlocation.properties" an unterschiedlichen Stellen gesucht und ausgelesen. In dieser Datei stehen die konfigurierten Domänen mit ihren DomainHomes.
In diesen DomainHomes wird jetzt jeweils die Datei <DOMAIN_HOME>/config/config.xml ausgelesen und die wesentlichen Parameter der Domänen zurück gegeben.
Der Autodiscovery-Vorgang bzw. das manuelle Aufrufen der Perlscripte für das Datenbankdiscovery funktioniert analog.

 An dieser Stelle endete der eigentliche Autodiscovery-Vorgang, weitergehende Discoveryschritte benötigen jetzt die Ein- bzw. Übergabe von Parametern zur genaueren Lokalisierung (Hostname, Port, etc) und Authentisierung (Benutzername, Passwort). Auf der Enterprisemanager Website sind diese Schritte unter dem Menuepunkt "promote" (Vorziehen) zu finden und gehören nicht mehr zum Autodiscovery im engeren Sinn.

Ulf Lämmerhirt

Freitag Aug 29, 2014

Oracle Middleware Patch Management mit EM12c R4

Dieser Blog-Eintrag beschreibt das automatisierte Patchen von Oracle FMW-Komponenten mit dem Oracle Enterprise Manager 12c Release 4. 

Grundsätzlich existieren Drei Ansätze, um eine Oracle Platform zu Patchen:

  1. OPatch/SmartUpdate - Oracle Patch-Tools zum Verwalten und Bereitstellen von Patches
  2. Custom Scripts - Angepasste Skripte, zur Unterstützung des Patch-Vorgangs (z.B. SQL-Skript zum Ändern von DB-Tabellen)
  3. Deployments - Um z.B. Applikationen zu Patchen

Alle Ansätze können mit dem EM12c Framework automatisiert werden.

Vorteile:

  • Kompabilitätsprüfung - Es wird im Vorfeld geprüft ob die neuen Patches mit existierenden Patches auf der Ziel-Platform kompatibel sind.
  • Template-Erstellung - Der Bereitstellungvorgang kann beliebig oft wiederholt werden. Zum Beispiel Patchen einer Test-Umgebung und Ausrollen in Produktion.
  • Fehlerminimierung - Durch automatisches Prüfen aller Eingaben.
  • Sicherheit - Framework bezüglich Passwort-Verwaltung und Zugriffs-Steuerung.


Schemazeichnung: Patchen mit dem Oracle Enterprise Manager Cloud Control 

Im nachfolgenden werden die obigen Schritte aufgezeigt und mit praktischen Tips angereichert.

1. Aufsetzten der Infrastruktur

Alle benötigten Schritte sind in der öffentlichen EM Dokumentation beschrieben. Ich fasse hier die wichtigsten Punkte zusammen.

  • Konfiguration der EM-Software-Library 
  • Erstellen und hinterlegen der benötigten Zugriffsrechte
  • ggf. Erstellen von EM-Benutzer-Accounts
  • Optional: Zugriff auf My Oracle Support, EM-Self-Update und Email Benachrichtigungen

!!Tip!!: Für den Patchvorgang benötigt der EM Zugriff auf die Domäne und das Oracle-Home, deshalb sollte man für beides Prefered-Credentials im EM12c hinterlegen.

Eine Liste der unterstützten Oracle FMW-Ziel-Typen und Releases findet man hier

2. Identifizieren der Patches

Um herauszufinden welche Patches in das System eingespielt werden sollten gibt es zwei Möglichkeiten:

  • Manuelle Suche über My Oracle Support
  • Offline/Online Überprüfung und Darstellung im Enterprise Manager

Der zweite Punkt stellt den Best-Practice Ansatz dar. Der Oracle Support erstellt täglich eine Liste mit den neusten Patches bereit. Diese Liste wird in den Enterprise Manager Cloud Control hochgeladen. Der EM12c vergleicht die Liste mit den überwachten Zielen und generiert Empfehlungen welche Patches eingespielt werden sollten. Diese Liste lässt sich nach Patch-Klassifizierung und Zieltypen anzeigen.


Patchvorschläge nach Target Typen
  

Patchvorschläge nach Patch-Klassifizierung 

3. Patchen

Im ersten Schritt wird der ausgewählte Patch vom Oracle Support in die EM-Software-Library hochgeladen. Dies erfolgt entweder Offline oder Online. Hat der EM eine Internet-Verbindung kann dies aus dem EM direkt erfolgen, wenn keine Internet-Verbindung vorliegt müssen die Patch- und Metadaten-Datei manuell heruntergeladen werden. Die Metadaten-Datei wird benötigt, um die Kompabilität des Patches mit der geplanten Umgebung sicher zu stellen. Offline werden Patch und Metadaten auf der "Saved Patches"-Seite hochgeladen (Menü: Enterprise -> Provisioning and Patching -> Saved Patches)

Manuelles Hochladen des Patches und der Metadaten-Datei
  
  
  

!!Tip!!: Wärend des Patch-Vorgangs wird vom EM immer überprüft, ob die OPatch-Version aktuell ist. Daher empfiehlt es sich vor dem Patchen immer die aktuelleste OPatch-Version in die Software Library zu laden. Der Update von OPatch bzw. SmartUpdate wird automatisch vom EM durchgeführt.

Im nächsten Schritt wird ein Patch-Plan erstellt. Ein Patch-Plan ist eine Ausführungsanweisung für den den Patch-Prozess. Ein Patch-Plan wird zum Beispiel aus der "Saved-Patches"-Seite erstellt. Dafür wird die gewünschte Patch-Nummer ausgewählt in der Detailansicht kann der Patch einen bestehenden Plan hinzugefügt werden, bzw. es kann ein neuer Patch-Plan erstellt werden. Ein Patch-Plan kann nur aus einem Patch erzeugt werden, es ist nicht möglich einen leeren Patch-Plan zu erstellen und diesen dann mit weiteren Patchen anzureichern.

Das Durchführen des Patchen geschied durch den Aufruf (view) des Patch-Plans. Der Patch-Plan ist ein Workflow gesteuerter Prozess der aus den nachfolgenden Schritten besteht: 

  1. Allgemeine Informationen - In diesem Schritt können weitere EM-Benutzer Zugriff auf den Patch-Plan erhalten
  2. Patches - In diesem Schritt können weitere Patches den Plan hinzugefügt bzw. entfernt werden
  3. Bereitstellung-Optionen -In diesem Schritt werden die Patch Ziele festgelegt, in welcher Form gepatched werden soll (Nacheinander oder Parallel) und es werden Umgebungs-Credentials gesetzt
  4. Validierung - In diesem Schritt wird die Kompabilität zu den bestehenden Patches in den Ziel-Komponenten geprüft
  5. Review und Bereitstellung - In diesem Schritt werden die ausgewählten Patches auf den Komponenten bereitgestellt

Im Anschluß erhält der Benutzer die Möglichkeit den Patch-Plan als Patch-Template zu speichern. Ein Anwendungsfall für Templates ist das Testen des Patches auf einer Testumgebung und anschließender Bereitstellung in einer Produktionsumgebung


Erfolgreiches Patchen mit EM12c 

Anschließend können in der ORACLE_HOME Seite alle eingespielten Patches bezogen auf die WLS-Domänen angezeigt werden.


4. Troubleshooting

Es gibt zwei Punkte im Ablauf möglicherweise für eine Fehlermeldung sorgen. Der fehlende OPatch-Update und ein fehlendes/fehlerhaftes ORACLE_HOME. Der erste Punkt ist einfach zu lösen: Man lädt den neusten OPatch Update von support.oracle.com  herunter und lädt diesen in die Software-Library (Menü: Enterprise -> Provisioning and Patching -> Saved Patches), der zweite Punkt ist etwas komplizierter....

Ohne ein valides ORACLE_HOME kann die Oracle FMW nicht mit dem EM12c gepatched werden. Es gibt mehrere Möglichkeiten zur Kontrolle eines existierenden und validen ORACLE_HOMEs.

  1. Über Host-Related-Targets: Im EM12c das Host-Ziel aufrufen, auf dem die FMW installiert ist. Dann im "Host-Kontext-Menue -> Related Targets" aufrufen. Hier werden alle Ziele Angezeigt auch die ORACLE_HOMEs mit den dazugehörigen Installations-Orten der FMW-Installationen
  2. Über die Konfigurationeigenschaften: Jedes Oracle FMW-Ziel im EM12c hat Konfigurationsinformationen. Wählt man als Ziel z.B. einen WLS-Managed-Server oder WLS-Admin-Server und geht auf "Configuration > Last Collected" wird in der Konfigurations-Tabelle das ORACLE_HOME angezeigt.

Was kann man jetzt machen, wenn kein ORACLE_HOME vorhanden ist?

Auch hier gibt es zwei Möglichkeiten:

1. Einrichten eins Jobs: Im Enterprise Menü "Job > Activity" Create Job "Discover Promote Oracle Home Targets" dann den Host auswählen und unter Parameter das ORACLE_HOME-Verzeichnis angeben. Dies ist in den meisten Fällen ähnlich $WLS_INSTALLATIONS_VERZEICHNIS/wlserver10_3. Dann den Job starten und das ORACLE_HOME wird ermittelt.

Discover ORACLE_HOME für eine WLS-Installation 

2. Einrichten mit Auto Discovery: Unter "Setup > Add Target > Configure Auto Discovery" werden im Reiter "Targets on Hosts" die Hosts angezeit. Man wählt den Host auf dem das ORACLE_HOME ermittelt werden soll und drückt den Schalter "Discover Now". In der Spalte Discoverd Targets klickt man auf den Eintrag und erhält alle Ziele die gefunden worden sind. Hier wählt man die gewünschte Domäne und drückt "Promote". Die Parameter werden auf Default-Werte belassen.

Es gibt noch eine dritte, sehr systemnahe, Möglichkeit zu testen, ob ein ORACLE_HOME korrekt für den Patch-Prozess eingerichtet ist. Mit folgenden SQL-Befehl im EM-Datenbank-Repository als Benutzer "SYSMAN" werden alle patchbaren Oracle FMW ORACLE_HOMEs aufgelistet.

select inst_target_name, oh_target_name from mgmt$oh_installed_targets where inst_target_type = 'weblogic_j2eeserver'

5. Zusätzliche Funktionen

Für einige Patches im Oracle FMW Umfeld müssen zusätzliche Patch-Schritte durchgeführt werden, wie z.B. ausführen von SQL-Skripten oder PL/SQL-Prozeduren. Dies kann ebenfall im EM12c Patch-Prozess eingebunden werden. Dafür wird der bestehende Patch-Workflow kopiert und kann mit zusätzlichen Schritten versehen werden. Eine genaue Beschreibung dieser Schritte findet sich in der Dokumentation. Meine Empfehlung ist, dies manuell durchzuführen, da sich solche Erweiterungen der Patch-Prozeduren nur dann lohnen, wenn man sehr viele Datenbank-Instanzen betreibt.

Fazit:

Das Patch-Modul des EM12c bietet eine Reihe von Vorteilen gegenüber dem manuellen Patchen. Es ist einfach zu bedienen, stabil und ermöglicht eine Dokumentation der durchgeführten Arbeiten. Es kann das Patchen durchführen oder Simulieren (siehe Schritt Validierung), daher ist es  für große und weniger große Oracle-Umgebungen zu empfehlen. Probieren Sie es einfach aus!

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.


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
« Mai 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