Performanceanalyse
Werbung
Michael Kauth SAP Certified Technical Consulting Performanceanalyse Inhalt Hardwareanalyse ..................................................................................................................................2 CPU ...............................................................................................................................................2 Hauptspeicher................................................................................................................................2 I/O ..................................................................................................................................................2 Netz ...............................................................................................................................................2 Datenbankanalyse .................................................................................................................................3 Datenbankmonitor ST04................................................................................................................3 Teure SQL-Statements ..................................................................................................................4 Datenbank I/O................................................................................................................................4 Exclusive Lockwaits .......................................................................................................................5 R/3 Speicherkonfiguration .....................................................................................................................6 R/3-Puffer ......................................................................................................................................6 SAP-Memory .................................................................................................................................6 Insgesamt allokierter Speicher ......................................................................................................6 R/3 Workprozessanalyse ......................................................................................................................8 Lokale Workprozessübersicht .......................................................................................................8 Globale Workprozessübersicht......................................................................................................8 R/3 Workloadanalyse mit ST03 (ST03N ab 4.6) ...................................................................................9 Richtwerte Dialog ..........................................................................................................................9 RFC-Profile ................................................................................................................................. 10 Allgemeine Performanceprobleme ............................................................................................. 10 Spezielle Performanceprobleme ................................................................................................ 11 Performanceprobleme nach Anwendung ................................................................................... 11 Analyse von ABAP-Programmen ....................................................................................................... 12 Einzelsatzstatistik ....................................................................................................................... 12 SQL-Trace .................................................................................................................................. 12 RFC-Trace .................................................................................................................................. 12 Enqueue-Trace ........................................................................................................................... 12 ABAP-Trace ................................................................................................................................ 12 ABAP-Debugger ......................................................................................................................... 13 RFC .................................................................................................................................................... 14 GUI ..................................................................................................................................................... 15 Tabellenpufferung .............................................................................................................................. 16 Tabellenpufferung überwachen .................................................................................................. 16 Analyse gepufferter Tabellen...................................................................................................... 16 Analyse nicht gepufferter Tabellen ............................................................................................. 16 Optimieren von SQL-Anweisungen durch Sekundärindizes .............................................................. 18 Quellen ............................................................................................................................................... 19 SAP Basis-Beratung Basisbetreuung von Einführungsprojekten Schulungen Michael Kauth SAP Certified Technical Consulting Hardwareanalyse CPU ST06 idle im Stundenmittel (Detail Analysis | Previous Hours) < 35% Richtwert unterschritten < 20% Problem Noch CPU-Kapazität auf anderen Rechnern? bessere Lastverteilung Prozesse mit hohem CPU-Bedarf suchen Detail Analysis | Top CPU Processes R/3-Workprozesse? Identifizieren mit SM50 Verschieben in den Nachtbetrieb möglich? Detailanalyse mit ABAP-Trace SE30 DB-Prozesse ? ST04 DB-Prozessmonitor Detailanalyse teure SQLStatements Externe Prozesse? abklemmen ST06 Load average (Anzahl der Prozesse, die im Mittel auf CPU warten) sollte bei Null sein. Liegt der Wert der letzten 15 Minuten über 3.00, so sollte nach der Ursache geforscht werden. Hauptspeicher Hauptspeicherengpässe können CPU-Engpässe verursachen. (Vermehrtes Swapping) Swap: 3mal physischer Hauptspeicher. Minimal 3,5 GB. (20 GB auf 64-bit Systemen) ST06 Pagingrate pro Stunde (Detail Analysis | Previous Hours) > 20% des phsyischen Hauptspeichers (Pages out; NT: Pages in) Hauptspeicherengpaß - Noch freie CPU-Kapazität auf anderen Rechnern? bessere Lastverteilung - Prozesse mit hohen Memorybedarf suchen ST02 Modusliste SM04 Memory - File System Cache auf 7-10% des physischen Hauptspeichers minimieren. (HP-UX: dbc_max_pct, AIX: maxperm, NT: Network | Services | Server | Maximize Throughput for Network Appl.) ST06 Sehr hohe Werte von “physical memory free” deuten darauf hin, dass die Speicherzuordnung in den R/3-Profilen noch erhöht werden kann. Niedrige Werte können zu Engpässen z.B. auf Betriebssystemebene führen. I/O ST06 Detail Analysis | Disk Auslastung (Util.) > 50% Problem Bessere Verteilung der Daten. Ziel: gleichmäßig belastete Platten Netz ST06 Detail Analysis | LAN Check by Ping Applicationserver – Datenbankserver sollte < 10 ms sein. Applicationserver – Frontend s. Abschnitt GUI Parameter Unter UNIX werden Parameteränderungen verfolgt mit: ST06 Detail Analyse | Parameter Changes | History of File -2- Michael Kauth SAP Certified Technical Consulting Datenbankanalyse Datenbankmonitor ST04 Oracle - Datenpuffer - Data buffer: Size - logische Zugriffe: Read, physische Zugriffe: Physical Read - init<sid>.ora: DB_BLOCK_BUFFERS in 8KB-Blöcken - Qualität rule-based Optimizer >= 97% - Qualität cost-based Optimizer >= 95% - Buffer busy waits > 5% Detailanalyse - Undo-head, undo-block > 1% u.U. Rollbacksegmente hinzufügen - data-block > 1% u.U. Data Buffer vergrößern - Shared Pool (bildet zusammen mit dem Datenpuffer die SGA) - Enthält Verwaltungsinformationen in - Row Cache (Data-Dictionary-Cache: Namen und Eigenschaften von Tabellen, Benutzern…) - DD-Cache quality > 90% - Shared SQL Area (Ausführungspläne und Statistiken von SQL-Statements) - Pinratio >= 98% - Init<sid>.ora: SHARED_POOL_SIZE in Byte - Ist noch Platz im Shared Pool frei? V$SGASTAT -> Free memory - Redo Log Buffers - init<sid>.ora: LOG_BUFFER als Vielfaches von DB_BLOCK_SIZE - Alloc fault rate > 1% u.U. Online Redologs vergrößern - Calls - User Calls: Aus der Anwendung stammende SQL-Zugriffe - Recursive Calls: Zusätzlich durch das Oracle generierte Zugriffe, z.B. bei Misses im DataDictionary Cache oder beim Anlegen neuer Tabellenextents - User Calls/Recursive Calls < 1 – 2 Shared Pool vergrößern, init<sid>.ora: row_cache_cursors > 100 (prüfen), sapdba -next - rollbacks: Hoher Wert Auf fehlerhafte Transaktionen prüfen; Oracle-Alert-Log prüfen - Parses: Anzahl der Parse-Vorgänge für SQL-Statements - User Calls/Parses < 4 Shared SQL Area u.U. zu klein - Reads/User Calls > 30 Prüfen auf „Teure SQL-Statements“ (s.u.) - Time Statistik - busy wait time: Die Oracle-Schattenprozesse warten auf eine Resource - idle wait time: Die Oracle-Schattenprozesse haben nichts zu tun - total wait time: busy + idle wait time - busy wait time/total wait time sollte klein sein - Sessions busy: (CPU-time + busy wait time)/(CPU-time + total wait time) - Details finden sich über ST04 Detail Analysis | Wait Events - Program Global Area (prozesslokaler Speicher) - Variabel (Richtwert 2,5 – 5 MB pro Prozess) - Prozesse: ST04 Detail Analysis | Oracle Sessions SQL-Server - Datenpuffer (Data cache) - Data cache KB: Size - Cache hit ratio > 95% - Größe: Rest des Server-Speichers - Procedure-Puffer (Procedure Cache) - Stored Procedures und Ausführungspläne für SQL-Statements - ST04 Procedure cache KB, Procedure cache KB in use -3- Michael Kauth SAP Certified Technical Consulting - - Größe wird dynamisch festgelegt. Fester Speicheranteil für Connections, Sperren… (ca. 20-100 MB) - Größe wird dynamisch festgelegt. Server-Speicher (Summe der 3 vorhergehenden Arten) - ST04 Dynamic memory KB - Variiert zwischen Maximum (Minimum) memory KB oder 0 und 2 GB bei Auto Growth - Parameter MAX (MIN) SERVER MEMORY - Empfehlung: Kein Auto Growth DB2/OS390 - Datenpuffer (Buffer-Pools und Hiperpools) - Puffert Daten- und Index-Pages - Read Random Hit Ratio >= 95% - Hiperpool Efficency >= 10% - EDM-Pool - Globaler Teil des Dynamic Statement Cache - Global Cach Hit Ratio >= 95% - Tread-lokale Caches - Lokaler Teil des Dynamic Statement Cache - Local Cache Hit Ratio >= 50% - Reprepare Ratio (Verdrängung) < 50% Teure SQL-Statements - können zu Hardwareengpässen führen (z.B. CPU, I/O) - blockieren R/3-Workprozesse - verdrängen andere Daten aus dem DB-Datenpuffer Aktuell laufende SQL-Statements (Oracle): ST04 Detail Analysis | Oracle Sessions mehrfach auffrischen - zugehöriges R/3-Programm in SM50 ermitteln Nachtbetrieb? - Ansonsten Analyse wie bei „Statistik von SQL-Anweisungen auswerten“ Statistik von SQL-Anweisungen auswerten (Shared SQL Area) (Oracle): ST04 Detail Analysis | SQL Request - sortieren nach Buffer Gets - Buffer Gets/ST04-Reads = Prozentualer Anteil der Anweisung an der Gesamtlast - Disk Reads/ST04-Physical Reads analog - wenige Statements > 5% Gesamtlast? Tuning erforderlich - SQL-Statement ermitteln - Wird ein passender Index verwendet (Explain)? - Kann ein neuer oder modifizierter Sekudärindex weiterhelfen? Kandidaten sind SQL-Statements, bei denen das Verhältnis von „Buffer Gets“ zu „Records“ schlechter als 10 zu 1 ist. - SAPNet-Recherche mit „Performance“ und Tabellenname - ABAP-Optimierung (Kandidaten sind SQL-Statements, die viele Gets/Execution aufweisen, also möglicherweise unnötig viele Daten lesen.) DB2/OS390: Aktuell laufende SQL-Statements: DB2 Thread Activity Statistik von SQL-Anweisungen: DB2 Statement Cache Statistics Datenbank I/O ST04 Detail Analyse | Filesystem Request I/O pro Datei Hoch? ST04 Goto | Statistics | Filesystem Waits Wartesituationen? Auslastung der Platte untersuchen (ST06), gegebenenfalls Datenverteilung ändern Lastintensiv: - Redo-Logs (Oracle) -4- Michael Kauth SAP Certified Technical Consulting - (PSAPROLL) (saparch) Transaction Log (Tempdb) (SQL-Server) Exclusive Lockwaits DB01 über Client-Host, Client-PID und SM50 zugehörigen R/3 Prozess ermitteln - falls kein R/3 Prozess Datenbankprozess beenden Parameter Änderungen von Datenbankparametern werden verfolgt mit ST04 Detail Analyse | Parameter Changes | History of File Tabellenstatistiken für Datenbankoptimierer Regelmäßige Ausführung mit DB13 prüfen. Datenbankindizes Missing Indizes mit DB02 prüfen. -5- Michael Kauth SAP Certified Technical Consulting R/3 Speicherkonfiguration R/3-Puffer ST02 Buffer Swaps? Entsprechenden Profilparameter erhöhen Ausnahme: Beim Programm-Puffer können bis zu 10000 Swaps pro Tag toleriert werden. ST02 Buffer Hitratio sollte über 98% liegen. Ausnahmen: Program, Single record und Export/Import-Buffer. Alle Puffer sollten mindestens 20% Free Space aufweisen. Ausnahmen: Nametab, CUA, screen und Calender-Buffer, die in produktiven Umgebungen nur einem geringen Wachstum unterliegen. SAP-Memory Extended Memory ist im Shared Memory abgebildet und wird beim Kontextwechsel in den Adressraum eines Workprozesse hineingemapped. Initial allokiert das System Extended Memory in der Grösse em/initial_size_MB. Für einen einzelnen Benutzerkontext steht maximal Extended Menory in der Grösse von ztta/roll_extension zur Verfügung. (NT s.u.) Roll Memory wird beim Kontextwechsel aus dem Roll-Puffer (shared) in den lokalen Speicher des Workprozesses kopiert (was aufwendiger ist). Heap Memory ist lokal zu einem Workprozess. Kontextwechsel sind nicht mehr möglich. Heap Memory wird erst mit Durchstarten des entsprechenden Workprozesses wieder freigegeben. Reihenfolge der Speicherbelegung durch Dialogworkprozesse (NT auch sonstige): - Roll Speicher bis ztta/roll_first (Minimum ca. 100 KB) - Extended Memory bis nichts mehr da ist, oder die Grenze ztta/roll_extention bzw. em/address_space_MB erreicht ist. - Roll Speicher bis ztta/roll_area erschöpft ist - Heap Speicher ST02 Extended Memory Max. use > 80% in memory? Problem Benutzer mit hohem Speicherverbrauch? Detailanalyse (ztta/roll_extention nutzen) em/initial_size_MB erhöhen, notfalls auf Kosten anderer Speicherbereiche. Faustregel: 6-10 MB pro Benutzer, 70 –120% des physical Memory. ST02 Roll area Max. Use > in memory Problem rdisp/ROLL_SHM erhöhen, falls genügend physical Memory. NT: Zero-Administration Memory (Hinweis 88416) - PHYS_MEMSIZE 70-100% des phys. Memory - Alle anderen Speicherparameter löschen. - Das Extended Memory vergrössert sich bei Bedarf dynamisch - In den Adressraum eines Workprozesses wird Extended Memory in der Grösse von em/address_space_MB eingebunden (ztta/roll_extention ist hier obsolet). Es lässt sich also trotz des 32-bit Charakters von NT auch RAM von mehr als 2 GB effektiv nutzen, da er auf die Workprozesse verteilt wird. Insgesamt allokierter Speicher ST02 Detail analysis | Storage Storage shared between processes (R/3-Puffer) + User storage for all work processes + Size of Extended Memory = Beim Starten von R/3 allokierter Speicher Kann wachsen um + Maximum heap area for all work processes (abap/heap_area_total) -6- Michael Kauth SAP Certified Technical Consulting aktueller Wert: ST02 Heap memory Current use Hinzu kommt noch + von der Datenbank allokierter Speicher ST04 + 50 – 100 MB für das Betriebssystem Die Summe des allokierten Speichers sollte den physisch vorhandenen um maximal 50% übersteigen. Der maximal allokierbare Speicher darf die Summe aus phys. Memory und Swap nicht überschreiten!! -7- Michael Kauth SAP Certified Technical Consulting R/3 Workprozessanalyse Lokale Workprozessübersicht Infos zu den verschiedenen Gründen für den Status „hält“ und zu den verschiedenen Semaphoren mit F1. Semaphore: Resourcen, wie der Roll-Buffer, die serialisiert werden müssen. (Grün: WP hält Semaphore, Rot: WP wartet auf Semaphore) Die Bedeutung der Semaphore ist in Hinweis 33873 erklärt. SM50 Es sollten genügend frei Workprozesse (Status „wartet“) jeden Typs vorhanden sein. SM50 Programm mit hohem Zeit-Wert? Mit Benutzer klären, ob alles klar ist. SM50 mehr als 20% der Workprozesse im PRIV-Mode möglicherweise Speicherproblem SM50 mehr als 40% der Workprozesse in einer DB-Aktion möglicherweise DB-Problem SM50 mehr als 20% der Workprozesse lesen dieselbe Tabelle möglicherweise Problem mit teuren SQL-Statements oder exclusive Locks SM50 Aktion „Report laden“ oder Semaphore 1 Program-Buffer prüfen SM50 Aktion „Roll In, Out“ oder Semaphore 6 Extended Memory und Roll-Buffer prüfen SM50 Status „hält“, Grund „CPIC“ Probleme im Zielsystem? SM50 CPU WPs einer Art weichen von „Dreiecksform“ ab (Betriebsartenumschaltungen berücksichtigen.) Anzahl WPs prüfen Lastverteilung prüfen SM50 WPs im Status „beendet“ und nicht mehr zu starten? Prozesses | Trace | Anzeigen dev-Trace lokal speichern. Globale Workprozessübersicht SM66 bietet Zusatzinformationen wie Transaktionscode, Name des aufrufenden Programmes, Jobname, aktuelle Extended Memory Belegung, aktuelle Heap Memory Belegung. Bei ausgeschaltetem RFC werden Informationen vom Message Server geholt und sind möglicherweise veraltet. Dispatcher-Queue SM51 Springen | Queue Info Höchststand wartenden Anfragen gibt Info zu WP-Mangel. Workprozessübersicht auf Betriebssystemebene dpmon pf=/usr/sap/<SID>/SYS/profile/Instanzprofilname -8- Michael Kauth SAP Certified Technical Consulting R/3 Workloadanalyse mit ST03 (ST03N ab 4.6) Av. response time = Wait time + Load+gen time + Roll-in time + Roll-wait time + Processing time + DB time + Enqueue time + GUI time (ab 4.6) Die Aussage von ST03 zur av. response time kann durch einzelne langlaufende oder auch regelmäßig ausgeführte schlecht programmierte Programme verzerrt werden. Eine solche Verzerrung kann über STAT/STAD ermittelt werden. Wird der Schnitt nicht durch solche Ausreißer kaputt gemacht, kann man sich an folgenden Richtwerten orientieren Richtwerte Dialog Av. response time sollte nicht größer als ca. 1000 ms sein. Av. CPU time sollte bei 40% der av.response time liegen. Wait time >> 10% der av. Response time allgemeines Problem >> 50 ms z.B. zu wenig WPs1 oder WPs blockiert Load+gen time >> 50 ms Programmpuffer (CUA- oder ScreenPuffer) zu klein oder CPU-Engpass Roll-in time >> 20 ms Roll-Puffer oder Extended Memory zu klein oder CPU-Engpass Roll-wait time >> 200 ms Problem in der Frondend-Kommunikation (ab 4.6; zusammen mit hoher GUI-Zeit) oder Komunikationsproblem mit externer Komponente bei sonstigem synchronem RFC GUI-Zeit >> 200 ms (ab 4.6) Probleme mit Frontendkommunikation (zusammen mit Hoher Roll-wait time) Enqueue time >> 5 ms Problem mit Enqueue oder Netz Processing time >> 2 x CPU-time CPU-Engpass oder (Processing time verstreicht, ohne dass CPU Workprozess im Zustand “hält” (SM50) genutzt werden kann) (s. auch „Fehlende Zeiten“ bei der Einzelsatzstatistik weiter unten) DB request time>> 40% von (av. Response time Datenbank-, Netz- oder CPU-Problem - Wait time) Richtwert (200 – 600 ms) Time per DB request >> 5 ms Datenbankproblem Direct Reads >> 2 ms Datenbankproblem Sequential Reads >> 10 ms Datenbankproblem Changes and commits >> 25 ms Datenbankproblem Av. RFC+CPIC time >> 10 ms Kommunikationsproblem Die Processing time ist die Differenz von av. Response time und allen Zeiten, in denen keine CPUZeit benötigt wird. Sie berechnet sich aus Av. Response time – Wait (for workprocess) time – DB request time – Enqueue time – Roll in time – Roll wait time – Load+gen time. Richtzeit für die durchschnittliche Roll in/out time: 10 ms. Die Roll-out time geht nicht in die av. Response time ein. 1 Die Erhöhung der Anzahl der Workprozesse bringt nur etwas, wenn Workprozesse durch Wartesituationen blockiert werden, die keine CPU-Leistung kosten (z.B. PRIV-Mode oder Sperrsituationen auf der Datenbank), UND CPU und Speicher des Rechners noch nicht voll ausgelastet sind. Im Zweifel ist das Warten auf CPU teurer als das Warten auf Workprozesse. Bei CPU- bzw Hauptspeicherengpässen und hoher Processing-time kann die Reduzierung der Anzahl der Workprozesse die Performance verbessern. -9- Michael Kauth SAP Certified Technical Consulting Die Av. RFC+CPIC time ist bei asynchronem RFC die Zeit, die zum Aufbau der Verbindung und zur initialen Datenübergabe benötigt wird (Richtwert < 50 ms). Beim synchronen RFC ist es die Gesamtzeit des Aufrufs inclusive der Roll wait time und der Zeit für die Übergabe der Ergebnisdaten. Die Roll wait time ist die Zeit in der ein Programm auf die Antwort eines synchronen RFC-Aufrufes wartet. In dieser Zeit ist das Programm aus dem Speicher herausgerollt, die Antwortzeit läuft aber weiter. Im gerufenen System wird ein Statistiksatz des Task-Typs RFC erstellt. Ab 4.6 entsteht Roll wait time auch bei der Kommunikation mit dem GUI. Aktivität oder Durchsatz := Anzahl Transaktionsschritte pro Zeiteinheit Last := Gesamte Antwortzeit Richtwerte Update Direct Reads Richtwert 10 ms Sequential Reads Richtwert 15 ms Changes and commits Richtwert 40 ms RFC-Profile Client-/Server-Destinationen - Summenstatistiken zu einzelnen Destinationen. (Angaben zu Funktionsbausteinen haben hier keine Bedeutung und werden in neueren Releases nicht mehr aufgeführt.) Client Profil - das lokale System stellt den RFC-Request (Sender) Server Profil - das lokale System bearbeitet den RFC-Request (Empfänger) Call time/Aufrufzeit (gemessen im Sender-System) Call time – Execution time > 20% von Call time Probleme in der Verbindung zwischen Sender und Empfänger SM59 Verbindungstest bzw. RFC-Trace Execution time/Ausführungszeit (gemessen im Empfänger-System) Sichten: Funktionsbausteine - Es werden Statistikinformationen zu den 5 teuersten Funktionsbausteinen gesammelt. (Anzahl stat/rfcrec im Profil) Allgemeine Performanceprobleme Indikatoren: Wait time, DB request time, Processing time oder av. Response time zu hoch. Zeitliche Einordnung: ST03 Auswahl von „Total“, „Dialog“, „Background“... Time Profile. Interessant ist z.B., ob die Hintergrundlast Ursache für eine hohe Gesamtlast zu Hauptarbeitszeiten ist. Lastverteilung zwischen Servern: ST03 Goto | Performance Database | Analyse all Servers | Compare all Servers - Bei gleichen Rechnern sollte die „CPU time total“ ungefähr gleich sein. - Starke Unterschiede in den Datenbankzeiten weisen auf Netzprobleme hin. 2 2 Dies gilt auch für datenbankintensive Batchjobs: Wenn Batchjobs auf dem Datenbankserver schneller als auf Applicationservern laufen, so ist dies ein Indikator für Netzprobleme. - 10 - Michael Kauth SAP Certified Technical Consulting Spezielle Performanceprobleme Einzelne Übeltäter findet man über: ST03 Auswahl von „Total“, „Dialog“, „Background“... Transaction Profile Interessant sind - die erzeugte Systemlast, insbesondere von selbstgestrickten Transaktionen - die mittlere Antwortzeit der Kerntransaktionen - Datenbanklast (Datenbankzeit > 60% der Gesamtzeit SQL-Trace) - CPU-Last (CPU-Zeit > 60% der Gesamtzeit ABAP-Trace) Einige Exoten: - MainMenu: Aktionen im Menü <= 100 ms (Richtwert Antwortzeit) - AutoAbap: läuft periodisch im Hintergrund < 1000 ms Buf.Sync: Puffersynchronisation < 1000 ms RSM13000: Alle Verbuchungsbausteine, die nicht einer Transaktion zugeordnet werden können < 3000 ms ST03 Auswahl von „Total“, „Dialog“, „Background“... Memory Profile Performanceprobleme nach Anwendung Der Anwendungsmonitor ST07 schlüsselt nach Benutzern pro Modul auf. Durch Doppelklick steigt man in der Hierarchie in die Tiefe. Last pro Anwendung: ST07 Antwortzeit Pufferverbrauch pro Anwendung: ST07 SAP-Puffer - 11 - Michael Kauth SAP Certified Technical Consulting Analyse von ABAP-Programmen Einzelsatzstatistik STAT/STAD Auswahl der verdächtigen Transaktion/des verdächtigen Programms Doppelklick zur Einzelauswahl All Details Hohe Datenbankzeiten Datenbankproblem Häufig: “Note: Tables were saved in the table-buffer” Verdrängung/Invalidierung im Tabellenpuffer. Hohe Roll wait time, hohe GUI time Möglicherweise Kommunikationsproblem Hohe CPU-Zeiten Aufwendige Berechnungen o. häufige Zugriffe auf den Tabellenpuffer. CPU > 50% ABAP-Trace oder ABAP-Debug. „Fehlende Zeiten“ bei langlaufenden Jobs können anhand der Processing time (s.o.) ermittelt werden. Die Processing time sollte im Wesentlichen die Zeit sein, in der die CPU genutzt wird. Ist die Processing time deutlich grösser als die CPU-Zeit, so könnte: - Ein Statistik-Couter einen Overflow haben - Ein Paging-Problem oder ein CPU-Engpass vorliegen - Eine zum Application-Server lokale Datei verarbeitet werden (auch Sort mit Auslagerung auf Platte) - Ein Batch-Job „Commit work and wait“ abgesetzt haben SQL-Trace ST05 List Trace RFC-Trace ST05 Vor dem Trace Programm einmal ausführen, um Puffer zu füllen. Trace zu lastarmen und lastintensiven Zeiten wiederholen. Der Trace läuft lokal dort, wo er eingeschaltet wurde. 3 Ausführen Zeiten in Mikrosekunden. Direct Read (Rec = 1 !) 2-10 ms. Nur in Einzelfällen höher. Sequential Read nutzt Array Fetch. Es passen umso mehr Sätze in einen Array rein, um so weniger Felder beim Select gewählt wurden. Richtzeit für einen optimalen Array Fetch 5 ms im Mittel (< 10 ms) pro selektiertem Satz oder < 100 ms pro Fetch im Mittel. Fetch > 250 ms und nur wenige Sätze selektiert Möglicherweise kann ein neuer oder modifizierter Sekundärindex weiterhelfen. Goto | Summary | Verdichten Sortieren nach Laufzeit liefert die teuersten SQLs. Goto | Identical Selects liefert Mehrfachzugriffe, die sich vielleicht einsparen lassen. Object: Name des Empfängers Oper: „Client“ (Instanz, auf der der Trace läuft ist Client) oder „Server“ Statement: U.a. Name des Funktionsbausteins, übertragene Datenmenge Enqueue-Trace ST05 Object: Name des Enqueue-Objektes Oper: Einzelne Enqueues setzen/freigeben (ENQUEUE/DEQUEUE); DEQ ALL zu Objekt oder zum Ende der Transaktion; ENQPERM vererbt die Sperre an die Verbuchung ABAP-Trace SE30 3 Zu analysierendes Programm zunächst einmal ohne Analyse durchführen, um alle Puffer entsprechend zu füllen. Analyse zu lastarmen und lastintensiven Zeiten wiederholen. Performancebeeinträchtigung durch den Trace ca. 5% - 12 - Michael Kauth SAP Certified Technical Consulting Auswerten Hitliste: Ausführungszeiten je Anweisung sortiert nach Bruttozeiten 4 Hierarchie: Chronologischer Ablauf Bruttozeiten enthalten alle enthaltenen Aufrufe. (z.B. Perform: Brutto > Netto) Analyse: Einstieg in die Hitliste – Sortieren nach Nettolaufzeit zur Ermittlung der Anweisungen mit der höchsten Nettolaufzeit Analyse komplexer Programme: Analyse des gesamten Programmes mit voller Aggregierung und ohne Analyse von Operationen auf interne Tabellen (DefaultVariante) – Ermitteln der Modularisierungseinheiten mit hoher Laufzeit – Detailanalyse mit aktiviertem Trace für Operationen auf interne Tabellen und ohne Aggregation ABAP-Debugger Der ABAP-Debugger setzt u.U. Commits ab, erzeugt also möglicherweise inkonsistente Datenbestände! Starten des Progamms mit SM50 | Debugging mehrfach in das Programm springen identifiziert Coding-Stellen mit hohem CPU-Bedarf. Springen | Weitere Bilder | Speicherverbrauch Aktueller Hauptspeicherbedarf (Richtwerte: Dialogprogramm <= 100 MB, Batchprogramm <= 1GB) Springen | System | Systembereiche ITAB Liste der internen Tabellen. FILL Anzahl der Einträge Hauptspeicherbedarf = FILL * Leng Prüfen: Werden nicht mehr benötigte interne Tabellen mit REFRESH bzw. FREE freigegeben? Werden interne Tabellen mit dem Zusatz BINARY SEARCH durchsucht? (READ TABLE … WITH KEY … BINARY SEARCH auf sortierte Tabellen) (4.0: verwenden von SORTED TABLE oder HASHED TABLE) Der ABAP-Trace ist performanceaufwendig. Alle ermittelten Zeiten werden daher „korrigiert“ und sind niedriger, als die Zeiten der parallel geschriebenen Statistiksätze. 4 - 13 - Michael Kauth SAP Certified Technical Consulting RFC RFC dient der Kommunikation zwischen verschiedenen Systemen oder – innerhalb eines Systems – der Kommunikation zwischen Instanzen bzw. zwischen der Applikationsebene und der Präsentationsebene sowie der Parallelisierung von Prozessen. RFC wird immer von DialogWorkprozessen ausgeführt. Zwei Systeme lassen sich auf „harte“ und „weiche“ Art koppeln. Hart: Ist der Partner nicht erreichbar, bricht die Funktion, die RFC verwendet, ab. Weich: Gegenseitige Verfügbarkeit wird nicht vorausgesetzt. (Beispiel: ALE) Man unterscheidet 4 Arten von RFC: - Synchroner RFC: Der Sender (Client) wartet, während der RFC beim Empfänger (Server) läuft Roll wait time. (CALL FUNCTION ... DESTINATION ...) - Asynchroner RFC: Der Sender setzt seine Arbeit nach Start des RFC fort. Parallelisierung möglich. (CALL FUNCTION ... STARTING NEW TASK ... DESTINATION ...) - Transaktionaler RFC: Asynchroner RFC. tRFCs werden nach COMMIT WORK als LUW ausgeführt. (CALL FUNCTION ... IN BACKGROUND TASK DESTINATION ...) - Queued RFC: tRFC, bei dem die Reihenfolge der Abarbeitung im Zielsystem der der Erstellung entspricht. Ablauf: - Der Sender stellt die Verbindung zum Empfänger her. SM50: hält CPIC CMINIT - Die erforderlichen Daten werden zum Empfänger übertragen. SM50: hält CPIC CMSEND - Der synchrone RFC wartet. (Roll Out, Roll wait, SM04: Terminal APPC-TM, SMGW: offene Kommunikationsverbindung) - Der Empfänger „weckt“ den Sender des synchronen RFCs und schickt Daten zurück. SM50: hält CPIC CMRECEIVE - Abbau der Verbindung SM59 Verbindungstest: TCP/IP-Timeout - Empfängersystem verfügbar? - TCP/IP: Gateway korrekt definiert? S. auch Hinweis 63930 und 44844. SM59 Verbindungstest: Partnerprogramm nicht registriert - Empfängerprozess starten SM59 Verbindungstest: > 100 ms - Netzwerkverbindung zu langsam/überlastet (Prüfen mit „ping“, Richtwert für gute Verbindung 10 – 30 ms) - Empfängersystem überlastet (Alle Workprozesse belegt?) - TCP/IP: Prüfen, wie viele parallele Empfangsprozesse für IDOCs gestartet sind Zur Begrenzung des Resourcenverbrauchs durch asynchronen RFC s. Hinweis 74141. Über das Programm RSARFCLD könne die Quotas dynamisch konfiguriert werden. SM58: Fehlerkontrolle für tRFCs Für Verbindungen mit mehr als 50 tRFCs täglich sollte die automatisch Einplanung des Batchjobs RSARFCSE bei Kommunikationsfehlern unterdrückt werden. Stattdessen das Programm RSARFCEX mit der Destination und dem aktuellen Tag in der Periode 30 Minuten einplanen. Bei hohem tRFC-Aufkommen müssen die Tabellen ARFCSSTATE und ARFCSDATA reorganisiert werden. (RSARFC01, s. auch Hinweis 375566) - 14 - Michael Kauth SAP Certified Technical Consulting GUI Ab R/3 4.6 wird für die Kommunikation zwischen Präsentations- und Applikationsebene die ControlTechnik genutzt. Controls sind Softwarekomponenten, die im GUI eigenständig laufen. Bei Listen z.B. wird nicht nur der aktuelle Screen, sondern eine größere Datenmenge übertragen. Operationen wie Blättern erfolgen dann auf dem Front-End und erfordern keine Kommunikation mit dem Application-Server mehr. Zum Aufbau eines Bildschirms sind u.U. mehrere Interaktionen (Roundtrips) zwischen Präsentations- und Applikations-Server erforderlich. Pro Roundtrip werden Daten per synchronem RFC von der Applikationsebene an den Gui übertragen. Die GUI-Zeit eines Transaktionsschritts umfasst die Roll wait time, die beim RFC anfällt. Analyse von Problemen mit der GUI-Kommunikation bei Controls mit STAD: - Select Fields: Roll wait time, No. of round-trips, GUI time, Terminal in-Message, Terminal outMessage (App. GUI, unkomprimiert) - Interessant sind hohe GUI-Zeit oder hohe Datenübertragungsmenge - Datenübertragung: Im Mittel 1 KB pro 100 ms; häufig über 1 sek Netzwerkproblem oder Hardwareengpass auf dem Präsentationsserver - Datenmenge: Im Mittel 5-8 KB/Transaktionsschritt; häufig über 50 KB Problem beim Programm(design). Transaktionsvariante nutzbar? (Hinweis 332210) Analyse von Problemen mit der GUI-Kommunikation bei Controls mit ST05: - SQL-, Enqueue- und RFC-Trace aktivieren - Suchen nach RFC-Bausteinen mit Ziel Präsentation-Server (Spalte: Objekt) - Anteil der Antwortzeit an der Gesamtantwortzeit relevant? - Bewerten (s.o) des Verhältnisses von Antwortzeit (duration) zur übertragenen Datenmenge (bytes sent nach Zeilenauswahl) Analyse des Netzwerks zwischen Application- und Presentation-Server mit „Lan Check by Ping“: - Zu analysierende Präsentation-Server markieren - 10 x Ping; Typische Antwortzeiten: - LAN < 20 ms - WAN < 50 ms - Modem < 250 ms - Keine „Losses“ Im WAN oder bei langsamen Netz sollte die Low Speed Connection genutzt werden. (Hinweis 164102) (Bei der Low Speed Connection steht die Vorschlags-Funktion für alte Eingaben nicht zur Verfügung.) Bei Hardwareengpässen auf dem Presentation-Server auf das Classic-Design umschalten. - 15 - Michael Kauth SAP Certified Technical Consulting Tabellenpufferung Tabellen können im Einzelsatzpuffer TABLP oder im generischen Tabellenpuffer TABL gepuffert werden. Zur Synchronisation der Tabellenpuffer verschiedener R/3-Instanzen wird in regelmäßigen Abständen (rdisp/bufreftime) die Tabelle DDLOG ausgelesen, wenn rdisp/bufrefmode auf ..,exeauto steht. Tabellenpufferinhalte werden in den Einheiten invalidiert, in denen sie gefüllt werden. Tabellen puffern, wenn - sie klein sind - häufig auf sie zugegriffen wird - ihre Änderungsrate klein ist - kurzzeitige Inkonsistenzen zwischen den Applikationsservern akzeptiert werden können - bei generisch n-gepufferten Tabellen der Zugriff mindestens über die ersten n Schlüsselfelder erfolgt. Prüfen: Sind die im Customizing generierten Konditionstabellen Annn, Bnnn, Cnnn, Dnnn, KOTEnnn, KOTFnnn, KOTGnnn und KOTHnnn, (nnn = 500 – 999 sind Kundentabellen) korrekt gepuffert? Tabellenpufferung überwachen ST02 freier Platz > 10%, freie Einträge > 20%. Symptome für Tabellenpufferprobleme: - Benutzer klagen über sporadisch auftretende lange Antwortzeiten in Transaktionen - In der Shared SQL Area oder bei SQL-Traces finden sich teure Anweisungen mit Bezug auf gepufferte Tabellen. - STAT: Häufig: Note: Table were saved in Table buffer. ST10 – Status: Valid - Tabelle gültig im Puffer Invalid - Tabelle invalidiert. Es läuft gerade eine Aktion die noch nicht mit Commit abgeschlossen wurde. Pending - Tabelle invalidiert. Karenz läuft gerade. Loadable - Tabelle invalidiert. Kann geladen werden. Absent, displaced - Tabelle noch nicht geladen oder verdrängt. Multiple - Einige generische Bereiche sind gültig, andere invalidiert. Error - Fehler beim Laden der Tabelle Analyse gepufferter Tabellen ST10 - sortieren nach DB activity: Rows affected sollte klein sein - sortieren nach Changes o. Invalidierungen Changes/Request (Änderungsrate) sollte klein sein. - sortieren nach Tabellengröße: < 1MB Änderungsrate < 1%, < 5MB ÄR < 0,1% (4.0B) Analyse nicht gepufferter Tabellen ST10 - sortieren nach Requests Total Hoch: Tabelle ist Pufferungskandidat, wenn sie die Kriterien oben erfüllt und gepuffert werden darf. DB05 - Die Anzahl Sätze, die nach einer Invalidierung neu gelesen werden müssen und andererseits die Anzahl der generischen Regionen dürfen nicht zu hoch sein. Z.B. 150000 Sätze ( volle Pufferung lohnt sich kaum, wenn die Änderungsrate nicht sehr gering ist): Bei Invalidierung maximal 10000 Sätze, 1500 gen. Regionen ist ok. - 16 - Michael Kauth SAP Certified Technical Consulting Die Pufferung von Tabellen soll die Zugriffe auf die Datenbank vermindern, also das Verhältnis von Requests zu Rows affected klein halten. Bewirkt eine Änderung der Tabellenpufferung dies nicht, so muss sie überdacht werden. Shared SQL Area bzw. SQL-Trace Nachdem ein System eine Weile läuft, sollten keine teuren SQL-Statements auftreten, die zu Pufferladevorgängen gehören. Solche SQL-Statements sehen folgendermaßen aus: - In der Where-Bedingung einer generisch-n-gepufferten Tabelle sind die ersten n Felder mit Gleichbedingungen angegeben. (Voll gepuffert = generisch-1: Mandt) - Die SQL-Anweisung enthält eine Order-by-Bedingung, die alle Felder des Schlüssels enthält. - 17 - Michael Kauth SAP Certified Technical Consulting Optimieren von SQL-Anweisungen durch Sekundärindizes Teure SQL-Statements, bei denen das Verhältnis von „Buffer Gets“ zu Treffern schlecht ist können möglicherweise durch neue oder modifizierte Sekundärindizes verbessert werden. - - - Bei SQL-Statements aus SAP-Standard-Programmen, nach einem passenden Hinweis suchen. Keine Sekundärindizes auf SAP-eigene Tabellen mit Bewegungsdaten Matchcodes usw. Bei kundeneigenen Programmen nach Möglichkeiten suchen, vorhandene Indizes zu nutzen. (Z.B. durch Ergänzung von Where-Bedingungen durch fehlende unselektive Felder oder durch alternative Zugriffspfade. Für die Logistikmodule s. Hinweise 185530, 187906 und 191492) Neue Indizes machen nur Sinn, wenn sie die Ergebnismenge einer Abfrage signifikant einschränken. (Treffermenge kleiner 5% der Tabelle.) Es müssen also selektive Felder verwendet werden. Je selektiver ein Feld, um so weiter muss es vorne im Index stehen. Ein Index sollte nur wenige Felder umfassen. Richtwert <= 4. Gelegentlich kann es erforderlich sein, auch nicht selektive Felder, wie den Mandanten aufzunehmen. Indizes sollten weitgehend disjunkt gehalten werden. Bei Tabellen, die häufig geändert werden, sind in der Regel mehr als 5 Indizes nicht empfehlenswert. Die Anlage von Indizes zu großen Tabellen kann lange dauern. Während der Anlage wird die gesamte Tabelle gesperrt. - 18 - Michael Kauth SAP Certified Technical Consulting Quellen Thomas Schneider SAP Performanceoptimierung Analyse und Tuning von SAP-Systemen SAP PRESS/ Galileo Press 2001 Kurt Bishop Fundamental Tools in Application Tuning in: www.intelligentERP.com , Volume 1, Number 4, 1999 SAP Online Dokumentation - 19 -
