Philosophische Einführung
Wie bekannt, gibt es nur zwei Methoden zur Lösung von Aufgaben:
- Analyse- oder Deduktionsmethode, oder vom Allgemeinen zum Besonderen.
- Synthese- oder Induktionsmethode, oder vom Besonderen zum Allgemeinen.
Um das Problem "die Leistung der Datenbank zu verbessern" zu lösen, könnte dies folgendermaßen aussehen.
Analyse — wir zerlegen das Problem in einzelne Teile und versuchen, die Leistung der Datenbank insgesamt zu verbessern.
In der Praxis sieht die Analyse etwa so aus:
- Ein Problem tritt auf (Leistungsvorfall)
- Wir sammeln statistische Informationen über den Zustand der Datenbank
- Wir suchen Engpässe
- Wir lösen 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 den Ingenieur — nahezu null.
Datenbankeinstellungen: die Möglichkeiten zur Veränderung sind etwas größer als im vorherigen Fall, aber in der Regel dennoch ziemlich schwierig, insbesondere in der Cloud.
Anfragen zur Datenbank: die einzige Spielraum für Manöver.
Synthese — wir verbessern die Leistung einzelner Teile in der Erwartung, dass die Leistung der Datenbank insgesamt besser wird.
Lyrische Einführung oder warum das alles notwendig ist
Wie der Prozess der Lösung von Leistungsvorfällen abläuft, wenn die Leistung der Datenbank nicht überwacht wird:
Kunde - "bei uns läuft alles schlecht, alles dauert lange, machen Sie es gut für uns"
Ingenieur - "schlecht, was bedeutet das?"
Kunde – "so wie jetzt (vor einer Stunde, gestern, beim letzten Mal war es so), langsam"
Ingenieur – "wann war es gut?"
Kunde – "vor einer Woche (zwei Wochen) war es ganz gut." (Das ist Glück)
Kunde – "aber ich erinnere mich nicht, wann es gut war, jetzt ist es schlecht" (Übliche Antwort)
Am Ende ergibt sich das klassische Bild:
Wer ist schuld und was ist zu tun?
Auf den ersten Teil der Frage lässt sich am leichtesten antworten — immer ist der DBA-Ingenieur schuld.
Auf den zweiten Teil ist die Antwort ebenso nicht allzu schwierig — es muss ein System zur Überwachung der Leistung der Datenbank implementiert werden.
Es stellt sich die erste Frage — was soll überwacht werden?
Weg 1. Wir überwachen ALLES
CPU-Auslastung, Anzahl der Lese-/Schreiboperationen auf der Festplatte, Größe des zugewiesenen Speichers und eine Megatonne verschiedener Zähler, die jedes einigermaßen funktionierende Überwachungssystem bereitstellen kann.
In der Folge entsteht eine Menge von Diagrammen, Pivot-Tabellen und ständigen Benachrichtigungen per E-Mail sowie eine 100%ige Auslastung der Ingenieure mit der Lösung einer Vielzahl ähnlicher Tickets, die in der Regel eine Standardformulierung beinhalten – „Temporary issue. No action needed“. So sind alle beschäftigt, und es gibt immer etwas, das dem Kunden gezeigt werden kann – die Arbeit floriert.
Weg 2. Überwachen Sie nur, was notwendig ist, und das, was nicht notwendig ist, muss nicht überwacht werden.
Es kann etwas anders überwacht werden – nur Entitäten und Ereignisse:
- auf die der DBA-Ingenieur Einfluss nehmen kann.
- Für die es einen Aktionsalgorithmus bei Auftreten eines Ereignisses oder einer Änderung der Entität gibt.
Aus dieser Annahme heraus und in Erinnerung an „Philosophische Einführung“ wird es sinnvoll sein, die Leistung einzelner Abfragen zu überwachen, um zu optimieren und zu analysieren, was letztendlich zu einer Verbesserung der Gesamtperformance der Datenbank führen sollte.Lyrische Einführung oder warum das alles notwendig istAber um eine schwere Abfrage, die die Gesamtleistung der Datenbank beeinträchtigt, zu verbessern, muss man sie zuerst finden.
So ergeben sich zwei miteinander verbundene Fragen:
Welche Abfrage gilt als schwerfällig?
- Wie sucht man nach schweren Abfragen?
- Offensichtlich ist eine schwere Abfrage eine, die viele OS-Ressourcen benötigt, um ein Ergebnis zu erhalten.
Kommen wir zur zweiten Frage – wie sucht und überwacht man dann schwere Abfragen?
Welche Möglichkeiten zur Überwachung von Abfragen gibt es in PostgreSQL?
Im Vergleich zu Oracle gibt es einige Möglichkeiten, aber man kann dennoch einiges tun.
PG_STAT_STATEMENTS
Für die Suche und Überwachung schwerer Abfragen in PostgreSQL ist das Standard-Erweiterung pg_stat_statements vorgesehen.
Nach der Installation der Erweiterung steht in der Ziel-Datenbank die gleichnamige Sicht zur Verfügung, die für Überwachungszwecke verwendet werden soll.
Zielspalten von pg_stat_statements für den Aufbau eines Überwachungssystems:
Interner Hash-Code, der aus dem Abstraktionsbaum des Operators berechnet wurde.
- queryid max_time
- Maximale Zeit, die für den Operator in Millisekunden aufgewendet wurde. Durch das Sammeln und Verwenden von Statistiken über diese beiden Spalten kann ein Überwachungssystem aufgebaut werden.
Wie pg_stat_statements zur Überwachung der Leistung von PostgreSQL verwendet wird.
Für die Überwachung der Abfrageleistung wird verwendet:
Auf der Seite der Ziel-Datenbank – die Sicht pg_stat_statements.
Von der Seite
und der Überwachungsdatenbank – eine Reihe von Bash-Skripten und Servicetabellen. Server und der Überwachungsdatenbank – eine Sammlung von Bash-Skripten und Diensttabellen.
1. Schritt — Sammlung statistischer Daten
Auf dem Überwachungs-Host wird regelmäßig durch einen Cron-Job ein Skript ausgeführt, das den Inhalt der Ansicht pg_stat_statements von der Ziel-Datenbank in die Tabelle pg_stat_history der Überwachungs-Datenbank kopiert.
Auf diese Weise wird eine Historie der Ausführung individueller Anfragen erstellt, die zur Erstellung von Leistungsberichten und zur Anpassung von Kennzahlen verwendet werden kann.
2. Schritt — Anpassung der Leistungskennzahlen
Basierend auf den gesammelten Daten wählen wir die Anfragen aus, deren Ausführung für den Kunden (Anwendung) am kritischsten/wichtigsten ist. In Abstimmung mit dem Auftraggeber setzen wir die Werte für die Leistungskennzahlen unter Verwendung der Felder queryid und max_time fest.
Ergebnis — Start der Leistungsüberwachung
- Das Überwachungsskript prüft beim Start die konfigurierten Leistungskennzahlen, indem es den Wert von max_time der Kennzahl mit dem Wert aus der Ansicht pg_stat_statements der Ziel-Datenbank vergleicht.
- Wenn der Wert in der Ziel-Datenbank den Kennzahlenwert überschreitet, wird eine Warnung (Vorfall im Ticket-System) generiert.
Zusätzliche Möglichkeit 1
Historie der Ausführungspläne von Anfragen
Für die spätere Behebung von Leistungsvorfällen ist es sehr nützlich, eine Historie der Änderungen der Ausführungspläne von Anfragen zu haben.
Zur Speicherung der Historie wird eine Servicetabelle log_query verwendet. Diese Tabelle wird beim Analysieren der hochgeladenen Logdatei von PostgreSQL gefüllt. Da im Logfile im Gegensatz zur Ansicht pg_stat_statements der vollständige Text mit den Werten der Ausführungsparameter und nicht der normalisierte Text enthalten ist, besteht die Möglichkeit, nicht nur die Zeiten und die Dauer der Anfragen, sondern auch die Ausführungspläne zum aktuellen Zeitpunkt zu protokollieren.
Zusätzliche Möglichkeit 2
Prozess der kontinuierlichen Leistungsverbesserung
Die Überwachung einzelner Anfragen ist im Allgemeinen nicht für die Aufgabe der kontinuierlichen Verbesserung der Gesamtleistung der Datenbank gedacht, da sie die Leistungsprobleme nur für einzelne Anfragen überwacht und löst. Das Verfahren kann jedoch erweitert werden, um die Überwachung von Anfragen für alle Datenbanken anzupassen.
Dazu müssen zusätzliche Leistungskennzahlen eingeführt werden:
- In den letzten Tagen
- Für den Basiszeitraum
Das Skript wählt Abfragen 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 über die letzten Tage oder über einen gewählten Zeitraum (Baseline), im zweiten Fall.
So wird im Falle einer Leistungsdegradation für jede Abfrage eine Warnung automatisch generiert, ohne manuelle Analyse der Berichte.
Was hat Synthese damit zu tun?
Bei dem beschriebenen Ansatz, wie es die Methode der Synthese vorschlägt – durch Verbesserung einzelner Teile des Systems verbessern wir das System insgesamt.
- Die von der Datenbank ausgeführte Abfrage – These
- Die geänderte Abfrage – Antithese
- Änderung des Systemzustands – Synthese
Entwicklung des Systems
- Erweiterung der gesammelten Statistiken durch Hinzufügen einer Historie für die systemweite Ansicht pg_stat_activity
- Erweiterung der gesammelten Statistiken durch Hinzufügen einer Historie für die Statistiken der einzelnen Tabellen, die an den Abfragen beteiligt sind
- Integration mit dem Monitoring-System in der AWS-Cloud
- Und außerdem, etwas könnte man sich einfallen lassen…
Quelle: habr.com
