End-to-End-Workload-Monitor und End-to-End-Laufzeitanalyse im SAP Solution Manager
Reduzierung der Softwareinstanzen
Der Erweiterte Speicher enthält also vor allem Nutzerkontexte von verschiedenen Workprozessen, falls diese nicht vollständig in den Rollbereich geladen werden können. Da der Speicherbereich für alle Workprozesse erreichbar ist, können die Workprozesse also auch auf fremde Nutzerkontexte, die hier liegen zugreifen. Außerdem enthält der Erweiterte Speicher einen Globalen Bereich in dem Daten unabhängig von Nutzerkontexten abgelegt werden können. Die Größe des erweiterten Speichers wird bestimmt durch die Werte von em/initial_size_MB und em/global_area_MB. Hierbei bestimmt der erste Parameter die Größe des Speicherbereichs in dem Nutzerkontexte abgelegt werden können und der zweite die Größe des globalen Bereichs. Parameter für den Privaten Speicher Zu guter Letzt gibt es noch den privaten Speicher, welcher nur dann genutzt wird, wenn der Nutzerkontext eines Workprozesses alle anderen ihm zur Verfügung stehenden Speicherbereiche aufgebraucht hat, also seinen Anteil des erweiterten Speichers und seinen Rollbereich. In diesem Fall geht der Workprozess in den PRIV modus. Ein Workprozess im privaten Modus ist an seinen aktuellen Nutzerkontext gebunden und wird erst dann wieder frei für andere Aufgaben, wenn die aktuelle Anfrage abgeschlossen ist. Falls er dabei den ihm zugewiesenen privaten Speicher vollständig aufgebraucht hat, wird der Workprozess anschließend neu gestartet und der Speicher wieder freigegeben. Dieses verhalten wird mit dem Parameter abap/heaplimit kontrolliert. Zeitweise kann der Nutzerkontext der Wert von abap/heaplimit dabei auch überschreiten. Die Parameter abap/heap_area_total, abap/heap_area_dia und abap/heap_area_nondia bestimmen eine obere Grenze für den privaten Speicher. Der Parameter abap/heap_area_total definiert wie viel privaten Speicher alle Workprozesse insgesamt nutzen können. Die Parameter abap/heap_area_dia und abap/heap_area_nondia hingegen bestimmen, wie viel privaten Speicher ein einzelner (Nicht-)Dialog-Workprozess nutzen darf.
Betriebssysteme verwalten in der Regel einen eigenen File System Cache. Dieser Cache konkurriert mit dem SAP-System und der Datenbank um die Nutzung des Hauptspeichers. Ist der Cache zu groß eingestellt, kommt es zu hohen Paging-Raten, obwohl mehr physischer Hauptspeicher verfügbar ist, als durch SAP-System und Datenbank allokiert wurden. Wir empfehlen Ihnen, diesen Cache auf maximal 7 bis 10 % des physischen Speichers zu reduzieren.
REIHENFOLGE DER OPTIMIERUNG EINHALTEN
Ein CPU-Engpass kann durch externe Prozesse verursacht werden. Finden Sie in der Prozessübersicht externe Prozesse (d. h. Prozesse, die nicht direkt zum SAP-System gehören) mit einem hohen CPU-Konsum, die zu einem CPU-Engpass führen, sollten Sie prüfen, ob diese für den Betrieb Ihres Systems notwendig sind oder ob sie abgeschaltet oder auf einen anderen Rechner verlagert werden können. Beispiele für externe Prozesse sind: Verwaltungssoftware, Virenscanner, Backup, externe Systeme, Bildschirmschoner (!) etc..
Am Anfang beschäftigten sich in unserer Firma mit der Installation und Verwaltung der Systeme die Funktionsberater/Consultants der jeweiligen Systeme. Der CRM-Berater war für das SAP CRM-System, der SRM-Berater für das SAP SRM usw, verantwortlich.
Das Tool "Shortcut for SAP Systems" eignet sich sehr gut, um viele Aufgaben in der SAP Basis einfacher und schneller zu erledigen.
Im Hauptspeicherkonfigurationsmonitor (Transaktionscode ST02) finden Sie eine Auflistung aller Speicherbereiche, die vom ABAP-Server allokiert werden – inklusive der Nutzungshistorien.
Und stehen Ihnen bei einem Plattform- oder Releasewechsel zur Seite.