Philosophische Einführung
Wie bekannt ist, gibt es nur zwei Methoden zur Lösung von Aufgaben:
- Analytische Methode oder Deduktionsmethode, oder von Allgemein zu Speziell.
- Synthesemethode oder Induktionsmethode, oder von Speziell zu Allgemein.
Um das Problem „Datenbankleistung verbessern“ anzugehen, könnte das folgendermaßen aussehen.
Analyse — Wir zerlegen das Problem in einzelne Teile und versuchen, durch deren Lösung die Gesamtleistung der Datenbank zu verbessern.
In der Praxis sieht die Analyse etwa so aus:
- Ein Problem tritt auf (Leistungsereignis)
- Wir sammeln statistische Informationen über den Zustand der Datenbank
- Wir suchen nach Engpässen (bottlenecks)
- Wir beheben die Probleme an den Engpässen
Engpässe der Datenbank — Infrastruktur (CPU, Speicher, Festplatten, Netzwerk, Betriebssystem), Einstellungen (postgresql.conf), Abfragen:
Infrastruktur: Die Möglichkeiten für Ingenieure, Einfluss zu nehmen und Änderungen vorzunehmen, sind nahezu null.
Datenbankeinstellungen: Die Änderungsmöglichkeiten sind etwas größer als im vorherigen Fall, sind aber in der Regel dennoch ziemlich schwierig, insbesondere in der Cloud.
Abfragen zur Datenbank: der einzige Spielraum für Anpassungen.
Synthese — wir verbessern die Leistung einzelner Komponenten in der Erwartung, dass dadurch die Datenbankleistung verbessert wird.
Ein einführender Abschnitt oder warum das alles notwendig ist
Wie der Prozess der Behebung von Leistungsproblemen abläuft, wenn die Datenbankleistung nicht überwacht wird:
Kunde - "Bei uns läuft alles schlecht, es dauert lange, macht es gut für uns"
Ingenieur - "Was bedeutet schlecht?"
Kunde - "So läuft es jetzt (vor einer Stunde, gestern, bei der letzten Sache war es), langsam"
Ingenieur - "Wann lief es denn gut?"
Kunde - "Vor einer Woche (zwei Wochen) lief es ganz gut." (Das war Glück)
Kunde - "Ich erinnere mich nicht, wann es gut lief, aber jetzt ist es schlecht" (Übliche Antwort)
Am Ende entsteht ein klassisches Bild:
Wer ist schuld und was ist zu tun?
Die erste Frage lässt sich am einfachsten beantworten — immer ist der DBA-Ingenieur schuld.
Die zweite Frage lässt sich auch nicht allzu schwer beantworten — es muss ein System zur Überwachung der Datenbankleistung implementiert werden.
Die erste Frage lautet — was soll überwacht werden?
Weg 1. Wir werden ALLES überwachen
Der CPU-Load, die Anzahl der Lese-/Schreibvorgänge auf der Festplatte, die Größe des zugewiesenen Speichers und eine Vielzahl anderer Kennzahlen, die jedes halbwegs funktionierende Überwachungssystem bereitstellen kann.
Das Ergebnis ist eine Menge von Grafiken, Pivot-Tabellen und ständigen E-Mail-Benachrichtigungen sowie eine 100%ige Auslastung der Ingenieure, die eine Vielzahl ähnlicher Tickets bearbeiten, meistens mit dem Standardtext – „Temporäres Problem. Es sind keine Maßnahmen erforderlich“. So sind jedoch alle beschäftigt, und es gibt immer etwas, das man dem Kunden zeigen kann – die Arbeit läuft.
Weg 2. Nur das überwachen, was nötig ist, und das, was nicht nötig ist, nicht überwachen.
Man kann etwas anders überwachen – nur Entitäten und Ereignisse:
- Auf die der DBA-Ingenieur Einfluss nehmen kann.
- Für die es einen Aktionsalgorithmus gibt, wenn ein Ereignis oder eine Änderung der Entität auftritt.
Ausgehend von dieser Annahme und in Anlehnung an „Philosophische Einführung“ ist es sinnvoll, die Leistung einzelner Abfragen zu überwachen, um die Optimierung und Analyse zu unterstützen, was letztendlich zu einer Verbesserung der Gesamtgeschwindigkeit der Datenbank führen sollte.Ein einführender Abschnitt oder warum das alles notwendig ist» Es ist ratsam, die Leistung einzelner Anfragen zu überwachen, um Optimierungen und Analysen durchzuführen, was letztendlich zu einer besseren Performance der gesamten Datenbank führen sollte.
Um jedoch eine ressourcenintensive Anfrage zu optimieren, die die Gesamtleistung der Datenbank beeinträchtigt, muss man sie zunächst finden.
Daraus ergeben sich zwei miteinander verbundene Fragen:
- welche Anfrage als ressourcenintensiv gilt
- und wie man nach ressourcenintensiven Anfragen sucht.
Offensichtlich ist eine ressourcenintensive Anfrage eine, die viele Betriebssystemressourcen benötigt, um ein Ergebnis zu erhalten.
Kommen wir zur zweiten Frage — wie sucht und überwacht man ressourcenintensive Anfragen?
Welche Möglichkeiten zur Überwachung von Anfragen gibt es in PostgreSQL?
Im Vergleich zu Oracle sind die Möglichkeiten etwas begrenzt, aber man kann trotzdem einiges tun.
PG_STAT_STATEMENTS
Für das Finden und Überwachen ressourcenintensiver Anfragen in PostgreSQL dient das Standarderweiterung pg_stat_statements.
Nach der Installation der Erweiterung erscheint in der Ziel-Datenbank die gleichnamige Ansicht, die für Überwachungszwecke verwendet werden soll.
Relevante Spalten von pg_stat_statements zur Erstellung eines Überwachungssystems:
- queryid Interner Hash-Wert, der basierend auf dem Abfragebaum berechnet wird
- max_time Die maximale Zeit, die für die Anfrage in Millisekunden benötigt wurde
Durch das Sammeln und Verwenden der Statistiken zu diesen beiden Spalten kann ein Überwachungssystem aufgebaut werden.
Wie pg_stat_statements zur Überwachung der PostgreSQL-Leistungskennzahlen verwendet wird
Für die Überwachung der Leistungskennzahlen von Abfragen wird verwendet:
Auf der Seite der Ziel-Datenbank — die Ansicht pg_stat_statements
Von der Seite сервера und der Überwachungsdatenbank — eine Reihe von Bash-Skripten und Servicetabellen.
1. Schritt — Sammlung von Statistikdaten
Auf dem Überwachungs-Host wird regelmäßig ein Skript über Cron ausgeführt, das den Inhalt der Ansicht pg_stat_statements von der Ziel-Datenbank in die Tabelle pg_stat_history der Überwachungsdatenbank kopiert.
So entsteht eine Historie der Ausführung einzelner Abfragen, die zur Erstellung von Leistungsberichten und zur Anpassung von Kennzahlen verwendet werden kann.
2. Schritt — Anpassung von Leistungskennzahlen
Basierend auf den gesammelten Daten wählen wir die Abfragen aus, deren Ausführung für den Kunden (die Anwendung) am kritischsten/wichtigsten ist. Nach Absprache mit dem Auftraggeber legen wir die Werte der Leistungskennzahlen unter Verwendung der Felder queryid und max_time fest.
Das Ergebnis — Start der Leistungsüberwachung
- Das Überwachungsskript prüft beim Start die konfigurierten Leistungsmetriken, indem es den max_time-Wert der Metrik mit dem Wert aus der Ansicht pg_stat_statements in der Ziel-Datenbank vergleicht.
- Wenn der Wert in der Ziel-Datenbank den Metrikwert überschreitet, wird eine Warnung (ein Vorfall im Ticket-System) erstellt.
Zusätzliche Möglichkeit 1
Historie der Abfrageausführungspläne
Für die spätere Lösung von Leistungsvorfällen ist es sehr hilfreich, die Historie der Änderungen der Abfrageausführungspläne zu haben.
Zur Speicherung der Historie wird die Servicetabelle log_query verwendet. Die Tabelle wird während der Analyse der geladenen PostgreSQL-Logdatei gefüllt. Da in die Logdatei im Gegensatz zur Ansicht pg_stat_statements der vollständige Text mit den Ausführungsparametern und nicht der normalisierte Text gelangt, besteht die Möglichkeit, nicht nur die Zeiten und die Dauer der Abfragen zu protokollieren, sondern auch die Ausführungspläne zum aktuellen Zeitpunkt zu speichern.
Zusätzliche Möglichkeit 2
Prozess zur kontinuierlichen Leistungsverbesserung
Die Überwachung einzelner Anfragen ist im Allgemeinen nicht darauf ausgelegt, die kontinuierliche Verbesserung der Datenbankleistung insgesamt zu gewährleisten, da sie nur die Leistung einzelner Anfragen kontrolliert und löst. Es ist jedoch möglich, die Methode zu erweitern und die Überwachung von Anfragen für alle Datenbanken einzurichten.
Dafür müssen zusätzliche Leistungskennzahlen eingeführt werden:
- In den letzten Tagen
- Für den Basiszeitraum
Das Skript wählt Anfragen aus der Ansicht pg_stat_statements in der Ziel-Datenbank aus und vergleicht den Wert von max_time mit dem durchschnittlichen Wert von max_time, im ersten Fall für die letzten Tage oder den gewählten Zeitraum (Baseline), im zweiten Fall.
Somit wird im Fall einer Leistungsdegradierung für eine beliebige Anfrage automatisch eine Warnung erstellt, ohne dass eine manuelle Analyse der Berichte erforderlich ist.
Was hat Synthese damit zu tun?
In dem beschriebenen Ansatz, wie es die Synthesemethode vorschlägt – durch die Verbesserung einzelner Teile des Systems verbessern wir das System insgesamt.
- Die von der Datenbank ausgeführte Anfrage – These
- Die geänderte Anfrage – Antithese
- Änderung des Zustands des Systems – Synthese
Entwicklung des Systems
- Erweiterungen der gesammelten Statistiken durch Hinzufügen der Historie für die systemweite Ansicht pg_stat_activity
- Erweiterung der gesammelten Statistiken durch Hinzufügen der Historie für die Statistik einzelner Tabellen, die an Abfragen beteiligt sind
- Integration mit dem Überwachungssystem in der AWS-Cloud
- Und vielleicht kann man noch etwas anderes einfallen lassen…
Quelle: habr.com
