Performance und Ressourcenverbrauch überwachen 
Die Performance des Systems und die Auslastung der Systemressourcen sowie den Zustand der Manager und Services der J2EE Engine können Sie aus dem zentralen System heraus überwachen. Die Performance überwachen Sie vor allem anhand der Statistiksätze, die das System schreibt. Um die Statistiksätze anzusehen, verwenden Sie die Transaktion ST03G ihres zentralen Systems.
Die Systemressourcen sowie die von den Managern und Services gelieferten Daten können Sie in den Statusmonitoren des Monitor Service im Visual Administrator ansehen. Diese Daten werden ins zentrale System übertragen und mit dem Alert Monitor, Transaktion RZ20, überwacht.
Achtung
Wollen Sie ausschließlich die Performance und den Ressoucenverbrauch Ihres Java-Systems überwachen, sollten Sie den NWA verwenden. Weitere Informationen finden Sie unter Java System Reports.
Wenn Sie jedoch Änderungen in Ihrem Performance-Analyse-System vornehmen möchten, dann finden Sie unter diesem Thema die richtigen Informationen.
Performance
Voraussetzungen
Die J2EE Engine liefert über den SAPCCMSR-Agenten Statistiksätze an das zentrale Monitoring-System.
Im zentralen Monitoring-System ist der DSR-Kollektorjob SAP_COLLECTOR_FOR_NONE_R3_STAT eingeplant.
Überwachung der allgemeinen Performance
Die Performance der J2EE Engine und der deployten Anwendungen wird als Statistik, den so genannten Distributed Statistics Records (DSR), im globalen Systemlastmonitor (Transaktion ST03G) angezeigt. Die Daten können in verschiedenen Modi aufgerufen werden:
Als Systemlastübersicht des Tages, der Woche, des Monats
Als Aktions-, Zeit- oder Anwenderprofil, aufgeschlüsselt nach den einzelnen Services:
EJB Request
Web Request
Sicherheit
System
DSR Administration
Als Last der letzten Minuten
Für statistische Werte können keine Alarme gesetzt werden. Hier ist es also notwendig und wichtig, in gewissen Zeitintervallen die Performance-Werte zu überprüfen.
Hinweis
Die Interpretation der Performance-Daten beruht größtenteils auf Erfahrungswerten durch Beobachtung des eigenen Systems und z. B. auf gefühlter adäquater Antwortzeitdauer, je nach Größe und Komplexität der aufgerufenen Anwendung, der Anzahl an Datenbankzugriffen und Menge transportierter Daten.
Empfehlung
Vergleichen Sie beispielsweise die Antwortzeiten des aktuellen Tages mit denen der vergangenen Tage.
Überprüfen Sie anhand der Hitlisten (Top Antwortzeit, Top Aufrufzeit) und der Antwortzeitverteilung, ob und wann Probleme aufgetreten sind. Wie Sie fehlerhafte oder nicht performante Anwendungen erkennen können, sehen Sie im Beispiel Performance-Analyse mit DSRs.
Performance-Trace einschalten
Der Performance Trace ist grundsätzlich abgeschaltet, um keine zusätzliche und unnötige Last zu erzeugen. Aktivieren Sie diesen erst, wenn ein Problem aufgetreten ist. Aktivieren Sie im DSR Service des Visual Administrator den Performance Trace für die Module, die zur Untersuchung des aufgetretenen Problems von Interesse sein könnten. Die geschriebenen Trace-Daten können Sie in der Transaktion STATTRACE einsehen.
Weiterführende Analyseschritte bei nicht performanten Anwendungen
Ist das Problem bei einer SAP-Anwendung aufgetreten:
Aktivieren Sie den Single Activity Trace und analysieren Sie diesen.
Ziehen Sie die Dokumentation der SAP-Anwendung zu Rate.
Wenn Ihr System ein Entwicklungs- und kein Produktivsystem ist, können Sie die Anwendung mit dem Application Tracing bis auf Methodenebene untersuchen.
AchtungNutzen Sie das Application Tracing nicht im produktiven System, denn Sie müssen hierzu die Anwendung stoppen und durchstarten.
Ende der Warnung.
Statusmonitore des Monitor Service
Die vitalen Werte der einzelnen Manager und Services der J2EE Engine wie z. B. Speicherverbrauch, Poolauslastung, Queuegrößen, werden im Monitor Service des Visual Administrator mit Alarmfarben nach „Ampelsystem“ angezeigt.
Die hier angezeigten Daten werden durch den SAPCCMSR-Agenten mit der Option -J2EE ins CCMS des zentralen Systems übertragen und im Alert-Monitor (Transaktion RZ20) angezeigt. Hier können zusätzlich Benachrichtigungen im Alarmfall und Autoreaktionsmethoden eingerichtet werden.
Zur Identifizierung der aufgetretenen Probleme lesen Sie im Referenzhandbuch unter dem Manager oder dem Service nach, der den Fehler anzeigt.
Beispiel: Reaktion auf einen Alarm im Statusmonitor
Wenn ein Alarm im Pool-Manager-Monitor auftritt, der anzeigt, dass nicht genügend Byte-Objekte einer bestimmten Größe zur Verfügung stehen, gehen Sie in den Pool Manager des Servers und erhöhen Sie die Anzahl der maximalen Einträge.
Achtung
Bevor Sie Änderungen an den Konfigurationen vornehmen, sollten Sie sich über die Abhängigkeiten der Änderungen im Klaren sein. Zusätzlicher Speicher wird normalerweise allokiert, falls Sie zum Beispiel Pools vergrößern. Eine Vergrößerung der Anzahl angenommener Threads im HTTP Provider führt zu größerer Last im System und den jeweiligen Anwendungen usw.