Beispiel einer Leistungsanalyse

Um der Videoanleitung zu folgen, öffnen Sie den Beispielbericht hier.

So interpretieren Sie den Leistungsbericht

Mit HQbird oder, als separatem Dienst, der IBSurgeon Performance Analysis von cc.ib-aid.com, können Sie einen Leistungsbericht aus Firebird-Trace-Protokollen erstellen.

Dieser Bericht ist ein leistungsstarkes Diagnosetool, das detaillierte Informationen über die Ausführung von SQL-Abfragen in Firebird-Datenbanken liefert. Dieser Leitfaden erklärt, wie Sie Trace-Berichte interpretieren und nutzen, um Leistungsengpässe systematisch zu identifizieren und zu beheben.

1. Struktur des Leistungsberichts

┌─────────────────────────────────────────┐
│         Leistungsbericht                │
├─────────────────────────────────────────┤
│ 1. Zusammenfassungsdiagramme            │
│    ┌────────────────────────┐           │
│    │  Top-Abfragen          │           │
│    │     Top-Zusammenfassung│           │
│    │     Top-Häufigkeit     │           │
│    │     Dauern             │           │
│    │     Fetches            │           │
│    │     Reads              │           │
│    │     Writes             │           │
│    │  Zeitreihendiagramm    │           │
│    │     Dauern             │           │
│    │     Anzahl Abfragen    │           │
│    │     Fetches            │           │
│    │     Reads/Writes       │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Top-Abfragen-Analyse                 │
│    ┌────────────────────────┐           │
│    │ Abfrage-Rangfolgen     │           │
│    │                        │           │
│    │  Nach Dauer────────┐   │           │
│    │                    │   │           │
│    │  Nach Zeit─────────┤   │           │
│    │  Zusammenfassung   │   │           │
│    │                    │   │           │
│    │  Nach Plan─────────┤   │           │
│    │  Zusammenfassung   │   │           │
│    │                    │   │           │
│    │  Nach Häufigkeit───┤   │           │
│    │                    │   │           │
│    │  Nach Plan─────────┤   │           │
│    │  Häufigkeit        │   │           │
│    │                    │   │           │
│    │  Nach Fetches──────┤   │           │
│    │                    │   │           │
│    │  Nach Reads────────┤   │           │
│    │                    │   │           │
│    │  Nach Writes───────┘   │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Prozesszusammenfassung               │
│    ┌────────────────────────┐           │
│    │ Statistiken pro Prozess│           │
│    │ - Ausführungsanzahl    │           │
│    │ - Fetches usw.         │           │
│    │ - Dauermetriken        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Adresszusammenfassung                │
│    ┌────────────────────────┐           │
│    │Statistiken pro Client  │           │
│    │- Verbindungsanzahl     │           │
│    │- Dauern                │           │
│    │- Fetches usw.          │           │
│    │- Prozessnamen          │           │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Struktur der Abfragedetails:
┌────────────────────┐
│ Abfrageinformation │
├────────────────────┤
│ - SQL-Text         │
│ - Transaktionsinfo │
│ - Ausführungsplan  │
│ - Dauerstatistiken │
│ - Ressourcenstatistiken│
│   * Fetches        │
│   * Reads          │
│   * Writes         │
│   * Marks          │
│ - Client-Info      │
└────────────────────┘

Der Leistungsbericht bietet eine hierarchische Ansicht der Datenbankaktivität:

1. Zusammenfassungsdiagramme

• Visuelle Darstellung wichtiger Metriken im Zeitverlauf - Sie können Aktivitäts-/Lastspitzen leicht erkennen. (Es gibt auch einen Bericht mit Minutenanalyse im Advanced Performance Monitoring in HQbird; die verkürzte Version davon ist im Portal-Tool verfügbar - siehe dieses Video für Details).

• Hilft, Muster und Anomalien zu identifizieren: Der Vergleich von Grafiken aus Zeiträumen mit guter Leistung (z. B. letzte Woche/Monat) mit Leistungsproblemen kann helfen, Probleme zu identifizieren.

2. Top-Abfragen-Analyse

• Mehrere Rangfolge-Perspektiven für eine umfassende Analyse: die längsten Abfragen, die häufigsten Abfragen, die zeitaufwendigsten Abfragen (gruppiert nach Text oder Plan) und mehr.

• Jede Dimension zeigt unterschiedliche Optimierungsmöglichkeiten auf

• Detaillierte Statistiken für jede Abfrage, einschließlich:

• Dauermetriken (Min, Max, Durchschnitt, Median)

• Ressourcenverbrauch (Fetches, Reads, Writes)

• Ausführungsmuster - Anzahl der Ursprünge für die Top-Abfragen.

3. Prozesszusammenfassung

• Gruppiert Statistiken nach ausführendem Prozess

• Hilft, problematische Anwendungen zu identifizieren

• Zeigt Ressourcenverbrauch und Datenbankoperationen (Verbindungen, Abfragen usw.) und Metriken (Fetches, Reads usw.) pro Prozess

4. Adresszusammenfassung

• Gruppiert Statistiken nach Client-Verbindung

• Zeigt die Lastverteilung über Clients

• Hilft, verbindungsspezifische Probleme zu identifizieren

Jeder Abschnitt unterstützt die Leistungsanalyse auf verschiedenen Ebenen:

• Systemweite Muster (Diagramme) - sehen Sie, wann und wo Probleme allgemein auftreten.

• Am auffälligsten sind Auswirkungen von Abfragen (Top-Abfragen) - identifizieren Sie Abfragen, die zuerst optimiert werden sollten.

• Probleme auf Anwendungsebene (Prozesszusammenfassung) - identifizieren Sie Anwendungen, die Leistungsprobleme verursachen.

• Probleme auf Client-Ebene (Adresszusammenfassung) - identifizieren Sie IP-Adressen (Arbeitsstationen, Client-Computer) mit dem größten Abfrageaufkommen.

2. Zeit-Zusammenfassung und Plan-Zusammenfassungs-Analyse

Es wird empfohlen, die Analyse der Leistungssituation mit den Zusammenfassungsabschnitten zu beginnen. Klicken Sie hier, um den Plan-Zusammenfassungsabschnitt im Beispielbericht zu öffnen.

Die Zeit-Zusammenfassung aggregiert die gesamte Ausführungszeit für jedes eindeutige SQL-Anweisungsmuster.

Betrachten Sie es als einen „Kostenstellen“-Bericht, der zeigt, welche Abfragen im Laufe der Zeit die meisten Datenbankressourcen verbrauchen.

Wenn Abfragen nicht parametrisiert sind, d. h. die Parameterwerte explizit im SQL-Text enthalten sind statt Parameter-Platzhalter (:myparam1), muss der Abschnitt „Plan-Zusammenfassung“ verwendet werden, um Abfragen mit der höchsten Häufigkeit zu identifizieren.
Beispiel für eine nicht parametrisierte Abfrage: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Beispiel für eine parametrisierte Abfrage: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Jede Abfrage im Zusammenfassungsabschnitt hat einen Kopfbereich mit den folgenden Schlüsselbestandteilen:

• Zusammenfassung: Prozentsatz der Gesamtzeit, der angibt, welchen Anteil der gesamten Datenbankzeit eine Abfrage verbraucht.

• Häufigkeit: Wie oft das Abfragemuster vorkommt

• Fetch, Read, Write: Ressourcenmetriken

Wenn es zum Beispiel

Zusammenfassung: 19.08% (3920272 von 20541791 ms)

gibt, sagt uns das, dass dieses Abfragemuster fast 20 % der gesamten Datenbankzeit verbraucht - ein erheblicher Anteil, der sofortige Aufmerksamkeit erfordert.

Unterhalb des Kopfbereichs im Plan-Zusammenfassungsabschnitt sehen wir den SQL-Ausführungsplan, der zum Gruppieren der Abfragen verwendet wurde; in der Zeit-Zusammenfassung ist es der Text der Abfrage selbst.

Da ein Abfragemuster mehr als eine spezifische Abfrage repräsentiert, werden die verbindungsspezifischen Informationen aus der ersten Abfrage übernommen, die dem Muster entspricht:

Im obigen Screenshot sehen Sie den Kopfbereich der Beispielanweisung für das Muster; er besteht aus dem Anwendungsnamen, der diese SQL gestartet hat, der Verbindungs-ID und der Transaktions-ID sowie der IP-Adresse und den Transaktionsdetails.

Darunter folgen der Plan (für die Zeit-Zusammenfassung; für die Plan-Zusammenfassung wird er übersprungen, da er bereits am Anfang gezeigt wird), die Parameterwerte (in der Reihenfolge ihres Auftretens) und die Statistiken pro Tabelle:

Bitte beachten Sie: In der Plan-Zusammenfassung gruppieren wir SQLs anhand des Ausführungsplans, was bedeutet, dass nur der Plan für das Muster konstant ist; in der Zeit-Zusammenfassung gruppieren wir anhand des SQL-Anweisungstexts, und andere Dinge (Parameterwerte, Ausführungszeiten usw.) können unterschiedlich sein. Verwenden Sie diese Informationen als Beispiel für das Ausführungsmuster (in 99 % der Fälle reicht dies aus, um das Problem zu reproduzieren).

Darunter haben wir ein individuelles Diagramm mit den Ausführungen dieser spezifischen Abfrage. Wie Sie sehen können, wurde diese Abfrage in der Phase hoher Last gestartet, die wir im Übersichtsdiagramm bemerkt haben.

Und am Ende haben wir eine sehr wichtige Sammlung von Statistiken für ALLE Abfragen, die dem Muster entsprechen, sowie eine Liste der Ursprungsadressen:

In diesen Statistiken sehen wir Minimum, Maximum, Durchschnitt und Median der Ausführungszeiten sowie dieselben Statistiken für Fetches, Reads, Writes und Marks (Cache-Flush-Operationen).

2.1. So verwenden Sie die Zeit-Zusammenfassung:

• Identifizieren Sie zuerst Abfragen, die unverhältnismäßig viel Zeit verbrauchen (sie sind die Top 3 dieses Abschnitts - #1, 2, 3)

• Vergleichen Sie den Zeitverbrauch mit der Häufigkeit

• Sehen Sie die durchschnittliche Ausführungszeit (Gesamtzeit / Häufigkeit) am Ende des Abfrageabschnitts (siehe unten)

• Suchen Sie nach Mustern, bei denen:

• Hohe Zeit + Niedrige Häufigkeit = Ineffiziente einzelne Abfragen

• Hohe Zeit + Hohe Häufigkeit = Potenziell ineffiziente, aber stark genutzte Abfragen

3. Häufigkeitsanalyse: Häufigkeit und Plan-Häufigkeit

Verwenden Sie die Häufigkeitsanalyse, um zu verstehen, wie oft Abfragen ausgeführt werden. Stellen Sie es sich wie das Zählen vor, wie oft eine bestimmte Straße während der Stoßzeit genutzt wird.

Wenn Abfragen nicht parametrisiert sind, d. h. die Parameterwerte explizit im SQL-Text enthalten sind statt Parameter-Platzhalter (:myparam1), muss der Abschnitt „Plan-Zusammenfassung“ verwendet werden, um Abfragen mit der höchsten Häufigkeit zu identifizieren.
Beispiel für eine nicht parametrisierte Abfrage: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Beispiel für eine parametrisierte Abfrage: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Auswirkungen der Häufigkeit verstehen

Die Darstellung des Häufigkeits-Abfragemusters ist der Plan-/Zeit-Zusammenfassung sehr ähnlich:

Hochfrequente Abfragen sind wie stark frequentierte Kreuzungen - selbst wenn jedes Auto (Abfrage) schnell fährt, kann die schiere Menge Staus verursachen. Dies betrifft:

• Datenbankverbindungen (wie Parkplätze - in der Anzahl begrenzt)

• Netzwerkbandbreite (wie Straßenkapazität)

• CPU-Auslastung (wie überlastete Verkehrslotsen)

• Cache-Effizienz (wie wiederholter Zugriff auf dieselben Informationen)

Um die Auswirkungen von Hochfrequenzabfragen abzuschätzen, sammeln Sie einen Trace mit Parameterschwellwert = 0.

3.2. Häufigkeits-Auswirkungskategorien

3.3. Beispielanalyse

Betrachten wir einen realen Fall aus unserem Trace-Bericht:

Häufigkeit: 4.428 Ausführungen (24,43 % der Gesamtzahl)
Auswirkung: Kritisch - hohes Volumen an SALES-Tabellenabfragen
Grundursache: Wiederholte Kundensaldoprüfungen
Optimierungspriorität: Hoch

Erklärung: Diese Abfrage wird tausende Male ausgeführt, ähnlich wie eine
befahrene Kreuzung. Auch wenn jede einzelne Ausführung schnell sein mag,
ist die kumulative Auswirkung erheblich. Die Anwendung könnte Salden
häufiger als nötig prüfen.

4. Analyse der Statistiken der Top-Abfragen in den Abschnitten xx-Zusammenfassung und Häufigkeit

Bei der Analyse von Firebird-Trace-Berichten enthält jede Abfragegruppe detaillierte aggregierte Statistiken, die entscheidende Einblicke in Leistungsmuster bieten. Lassen Sie uns jede Metrik aufschlüsseln und ihre Bedeutung für die Datenbankoptimierung verstehen.

4.1. Analyse aggregierter Statistiken

Betrachten wir dieses Beispiel für einen Statistikdatensatz:

Gesamt: 4428 Elemente:
Dauern: min: 351; max: 3919; avg: 457,70; median: 455,00; summe: 2026710 (20,29 %);
Fetches: min: 7135; max: 7168; avg: 7146,86; median: 7147,00; summe: 31646289 (0,75 %);
Schreibvorgänge: min: 0; max: 0; avg: 0,00; median: 0,00; summe: 0 (0,00 %);
Lesevorgänge: min: 0; max: 6995; avg: 3,13; median: 0,00; summe: 13856 (8,22 %);
Markierungen: min: 0; max: 0; avg: 0,00; median: 0,00; summe: 0 (0,00 %);
Von 1 eindeutigen Adressen: TCPv6:::1 (4428)

4.2. Analyse der Ausführungsanzahl

4.2.1. Gesamtelemente

Gesamt: 4428 Elemente

Dies stellt die Anzahl dar, wie oft dieses bestimmte Abfragemuster während des Trace-Zeitraums ausgeführt wurde.

Das Verständnis dieser Zahl hilft Ihnen:

• Ressourcennutzung pro Ausführung zu berechnen

• Zu bestimmen, ob Abfrage-Caching vorteilhaft sein könnte (oder die Abfrage einfach seltener ausgeführt werden sollte)

Hohe Ausführungszahlen könnten auf Möglichkeiten hinweisen für:

• Implementierung vorbereiteter Anweisungen (und parametrisierter) - dieselbe Abfrage mit derselben Häufigkeit, wenn parametrisiert und für wiederholte Ausführung vorbereitet, benötigt weniger Ressourcen

• Hinzufügen von Ergebnis-Caching - das Caching des Ergebniswerts für die Verwendung während des langen Vorgangs oder sogar länger, für die Benutzersitzung, kann die Notwendigkeit häufiger Abfrageausführungen reduzieren

• Stapelverarbeitung - erwägen Sie, die Abfrage auszuführen, um viele Datensätze auf einmal zurückzugeben oder zu verarbeiten; dies eliminiert den Overhead für die Abfrageausführung (Vorbereitung, Netzwerkübertragung usw.).

4.3. Dauer-Metriken

4.3.1. Beispiel für Dauer-Komponenten

Dauern: min: 351; max: 3919; avg: 457,70; median: 455,00; summe: 2026710 (20,29 %);

4.3.2. Daueranalyse

• Nahe beieinanderliegender Median und Durchschnitt (457,70 vs. 455,00 ms) deutet auf konsistente Leistung hin

• Max/Min-Verhältnis (~11x) weist auf eine gewisse Variabilität hin

• 20,29 % der Gesamtzeit sind erheblich - ist diese Abfrage in den Top 3 im Abschnitt Häufigkeit oder Plan-Häufigkeit? (Ja, ist sie.)

4.4. Ressourcennutzungs-Metriken

4.4.1. Fetch-Operationen

Fetches: min: 7135; max: 7168; avg: 7146,86; median: 7147,00; summe: 31646289 (0,75 %);

Fetches stellen Zeilenabrufe dar:

• Konsistente Fetch-Anzahlen (min/max-Differenz von nur 33) deuten auf stabile Ergebnismengen hin

• Relativ hohe Fetch-Anzahlen (>7000 pro Ausführung) könnten auf Folgendes hindeuten:

• Notwendigkeit der Begrenzung der Ergebnismenge und/oder Paginierung, wenn viele Datensätze zurückgegeben werden.

• Potenzial für Abfrageoptimierung - besonders sinnvoll, wenn die Abfrage in den Top 3 von Häufigkeit/Plan-Häufigkeit ist.

4.5. Leseoperationen

Lesevorgänge: min: 0; max: 6995; avg: 3,13; median: 0,00; summe: 13856 (8,22 %);

Physische Lesevorgänge zeigen Festplattenzugriff an:

• Null-Median mit Nicht-Null-Maximum deutet auf gelegentliche Cache-Fehltreffer hin

• 8,22 % der gesamten Lesevorgänge weisen auf eine moderate I/O-Auswirkung hin

• Große Lücke zwischen min (0) und max (6995) deutet auf variable Cache-Effektivität hin.

4.6. Schreiboperationen

Schreibvorgänge: min: 0; max: 0; avg: 0,00; median: 0,00; summe: 0 (0,00 %);

Wenn die Abfrage keine Schreibvorgänge durchführt, handelt es sich normalerweise um eine Nur-Lese-Operation.

4.7. Markierungsoperationen

Markierungen: min: 0; max: 0; avg: 0,00; median: 0,00; summe: 0 (0,00 %);

Markierungsoperationen beziehen sich auf die Cache-Verwaltung von Datenseiten:

• Null-Markierungen zeigen an, dass keine Datenseite zum Leeren markiert wurde, üblich für einfache SELECT-Abfragen

• Nicht-Null-Markierungen Operation mit Cache

4.8. Analyse der Client-Verbindung

Von 1 eindeutigen Adressen: TCPv6:::1 (4428)

Dies zeigt die Verteilung der Abfragequellen:

• Einzelne Client-Adresse deutet auf eine anwendungsspezifische Abfrage hin

• Lokale Verbindung (::1 ist IPv6-Localhost)

• Alle 4428 Ausführungen von derselben Quelle

4.9. Verwendung dieser Metriken zur Optimierung

4.9.1. Analyse des Leistungsmusters

Ausführungskonsistenz

• Min/Max-Dauern vergleichen

• Nach Ausreißern in der Ressourcennutzung suchen

• Median vs. Durchschnitt auf Variabilität prüfen

Ressourcennutzungsmuster

• Hohe Fetches → Ergebnismengengröße überprüfen

• Hohe Lesevorgänge → Indexabdeckung prüfen

• Hohe Markierungen → Sperrkonflikte untersuchen

Analyse der Client-Auswirkung

• Mehrere Clients → Größe des Verbindungspools

• Einzelner Client → Anwendungsoptimierung

4.9.2. Optimierungsprioritäten

Basierend auf diesen Metriken priorisieren Sie:

• Ergebnismengengröße

• 7000 Fetches pro Ausführung

• Hinzufügen von LIMIT/OFFSET erwägen

• SELECT-Spaltenliste überprüfen

Caching-Strategie

• Häufige Ausführung (4428 Mal)

• Konsistente Ergebnisgröße

• Keine Schreibvorgänge beteiligt

Wahrscheinlich kann diese Abfrage seltener ausgeführt werden.

Indexnutzung

• Variable Leseanzahlen

• Null-Median-Lesevorgänge, aber hohes Maximum

• Indexabdeckung überprüfen

5. Praktische Anwendung

Für dieses spezifische Beispiel:

Kurzfristige Verbesserungen:

• Ergebnis-Caching implementieren (hohe Ausführungsanzahl, konsistente Fetches)

• Ergebnismengengröße überprüfen (>7000 Fetches pro Ausführung)

Mittelfristige Optimierung:

• Indexnutzungsmuster analysieren

• Verwendung vorbereiteter Anweisungen erwägen

• Anwendungslogik für Ausführungshäufigkeit überprüfen

Langfristige Überlegungen:

• Ausführungsmuster im Laufe der Zeit überwachen

• Wartungsstrategie für Indizes planen

• Änderungen der Datenzugriffsmuster erwägen

6. Daueranalyse

Die Daueranalyse untersucht, wie lange einzelne Abfragen für die Ausführung benötigen. Stellen Sie sich die Dauer wie eine Stoppuhr vor, die jede Abfrage zeitlich misst - je länger eine Abfrage dauert, desto wahrscheinlicher ist es, dass sie Leistungsprobleme verursacht.

6.1. Verständnis der Dauer-Metriken

Dauer-Metriken sind entscheidend, da sie die Benutzererfahrung direkt beeinflussen, d. h. Benutzer behaupten, “das System ist langsam”. So wie Kunden frustriert sind, wenn sie in einer langen Schlange warten, sind Benutzer frustriert, wenn Abfragen zu lange dauern. Langlaufende Abfragen verursachen:

• Schlechte Benutzererfahrung, wenn Bildschirme zu lange zum Laden benötigen

• Systemressourcen, die über längere Zeiträume gebunden sind

• Andere Abfragen, die hinter langsamen in der Warteschlange warten

• Potenzielle Timeout-Probleme in Anwendungen

6.2. Auswirkungskategorien

6.3. Beispielanalyse

Dauer: 77.793 ms
Auswirkung: Kritisch - einzelne Abfrage verbraucht 77,7 Sekunden
Grundursache: Komplexe Aggregation in PRC_COLLECT_RANKCATEGORY
Optimierungspriorität: Sofort

Erklärung: Diese Abfrage benötigt über eine Minute zur Ausführung, was wie
ein vollständiger Verkehrsstopp ist. Die gespeicherte Prozedur verarbeitet
wahrscheinlich zu viele Daten oder verwendet ineffiziente Algorithmen.

7. Implementierungsstrategie

Denken Sie an Optimierung wie an die Verbesserung eines Transportsystems - Sie müssen Probleme identifizieren, Lösungen planen und Änderungen sorgfältig implementieren.

7.1. Priorisierungsmatrix

Diese Matrix hilft Ihnen zu entscheiden, was zuerst Aufmerksamkeit benötigt, wie das Triage von Verkehrsproblemen in einer Stadt:

7.2. Schritt-für-Schritt-Optimierungsprozess

1. Kritische Abfragen identifizieren

• Nach den größten Verkehrsstaus suchen (langsame Abfragen)

• Die belebtesten Kreuzungen finden (Hochfrequenzabfragen)

• Ineffiziente Routen erkennen (hohe Ressourcennutzung)

2. Ausführungspläne analysieren

• Aktuelle Routen untersuchen (Indexnutzung)

• Verkehrsmuster prüfen (Join-Methoden)

• Engpässe identifizieren (Sortiervorgänge)

3. Optimierungen implementieren

• Neue Straßen bauen (Indizes)

• Routen neu gestalten (Abfragen umstrukturieren)

• Abkürzungen hinzufügen (Caching)

4. Verbesserungen verifizieren

• Neuen Verkehrsfluss messen (neuer Trace-Bericht)

• Vorher/Nachher-Metriken vergleichen

• Dokumentieren, was funktioniert hat

Kontaktieren Sie IBSurgeon bei Fragen

Zögern Sie nicht, uns bei Fragen zu kontaktieren: [email protected].