Ich lade Sie ein, die Entschlüsselung des Berichts von Anfang 2016 von Andrej Salnikow mit dem Titel "Typische Fehler in Anwendungen, die zu Bloat in PostgreSQL führen" kennenzulernen.
In diesem Bericht werde ich die Hauptfehler in Anwendungen behandelt, die in der Phase des Designs und der Codierung auftreten. Ich werde nur die Fehler betrachten, die zu Bloat in PostgreSQL führen. In der Regel ist dies der Anfang vom Ende der Leistung Ihres Systems insgesamt, obwohl anfangs keine Anzeichen dafür sichtbar waren.
Ich freue mich, alle willkommen zu heißen! Dieser Bericht ist nicht so technisch wie der vorherige von meinem Kollegen. Er richtet sich hauptsächlich an Entwickler von Backend-Systemen, da wir eine beträchtliche Anzahl von Kunden haben. Alle machen die gleichen Fehler. Ich werde Ihnen darüber berichten und erklären, zu welchen fatalen und negativen Konsequenzen diese Fehler führen.
Warum werden Fehler begangen? Es gibt zwei Gründe: aus einer gewissen Risikobereitschaft, vielleicht klappt es ja, und aus Unkenntnis über bestimmte Mechanismen, die auf der Ebene zwischen der Datenbank und der Anwendung sowie in der Datenbank selbst stattfinden.
Ich werde Ihnen drei Beispiele mit schrecklichen Bildern zeigen, wie alles schiefgelaufen ist. Kurz werde ich den Mechanismus erläutern, der dort wirkt. Außerdem werde ich erklären, wie man damit umgeht, wenn sie auftreten, und welche präventiven Methoden zur Vermeidung von Fehlern eingesetzt werden können. Ich werde von Hilfsmitteln berichten und nützliche Links bereitstellen.
Ich verwendete eine Testdatenbank, in der ich zwei Tabellen hatte. Eine Tabelle mit Kundendaten und die andere mit den Operationen auf diesen Konten. In bestimmten Abständen aktualisieren wir die Bestände auf diesen Konten.
Die Quell Daten der Tabelle: Sie ist recht klein, 2 MB. Die Antwortzeit für die Datenbank und insbesondere für die Tabelle ist ebenfalls sehr gut. Und eine ziemlich hohe Belastung – 2.000 Operationen pro Sekunde auf der Tabelle.
Durch diesen Vortrag werde ich Ihnen Grafiken zeigen, um anschaulich darzustellen, was passiert. Es wird immer zwei Folien mit Grafiken geben. Die erste Folie zeigt, was insgesamt auf dem Server passiert.
In dieser Situation sehen wir, dass unsere Tabelle in der Tat eine kleine Größe hat. Der Index hat eine geringe Größe von 2 MB. Das ist das erste Diagramm von links.
Die durchschnittliche Serverantwortzeit ist ebenfalls stabil und gering. Dies ist das Diagramm oben rechts.
Das Diagramm unten links zeigt die längsten Transaktionen. Wir sehen, dass die Transaktionen schnell abgeschlossen werden. Der Autovacuum funktioniert hier noch nicht, da es sich um einen Teststart handelte. In Zukunft wird er aktiviert und nützlich sein.
Die zweite Folie ist immer der testenden Tabelle gewidmet. In diesem Fall aktualisieren wir ständig die Bestände auf den Konten des Kunden. Wir sehen, dass die durchschnittliche Antwortzeit für die Aktualisierungsoperation ausreichend gut ist, unter einer Millisekunde. Auch die CPU-Ressourcen (oberes rechtes Diagramm) werden gleichmäßig und in einem angemessenen Maß verbraucht.
Das untere rechte Diagramm zeigt, wie viel operativen und Speicherspeicher wir durchgehen, um die benötigte Zeile vor dem Aktualisieren zu finden. Die Anzahl der Transaktionen pro Tabelle beträgt 2.000 pro Sekunde, wie ich ursprünglich sagte.
Und nun geschieht eine Tragödie. Aus irgendeinem Grund tritt eine lange vergessene Transaktion auf. Die Gründe sind meist banal:
- Eine der häufigsten Situationen ist, dass wir im Code der Anwendung begonnen haben, auf einen externen Dienst zuzugreifen. Und dieser Dienst antwortet uns nicht. Das bedeutet, dass wir eine Transaktion geöffnet, eine Änderung in der Datenbank vorgenommen haben und dann aus der Anwendung heraus E-Mails gelesen oder einen anderen Dienst in unserer Infrastruktur genutzt haben, und aus irgendeinem Grund erhalten wir keine Antwort. Und unsere Sitzung bleibt in einem Zustand hängen – ungewiss, wann sie gelöst wird.
- Die zweite Situation ist, wenn in unserem Code aus irgendeinem Grund eine Ausnahme aufgetreten ist. Und wir haben im Ausnahmefall das Schließen der Transaktion nicht verarbeitet. Das führt dazu, dass wir eine schwebende Sitzung mit einer offenen Transaktion haben.
- Und zuletzt – das ist auch ein ziemlich häufiges Szenario. Das ist minderwertiger Code. Einige Frameworks öffnen eine Transaktion. Sie bleibt offen, und Sie wissen möglicherweise nicht in der Anwendung, dass sie offen ist.
Worauf führen solche Dinge hin?
Wir sehen, dass unsere Tabellen und Indizes stark anwachsen. Das ist genau der Effekt des Bloat. Für die Datenbank bedeutet das, dass die Antwortzeiten sprunghaft ansteigen und die Last auf dem Datenbankserver zunimmt. Letztendlich leidet die Anwendung darunter. Wenn Sie im Code 10 Millisekunden für die Datenbankabfrage und weitere 10 Millisekunden für Ihre Logik benötigt haben, betrug die Gesamtzeit 20 Millisekunden. Jetzt wird die Situation jedoch ganz anders aussehen.
Schauen wir uns an, was passiert. Das Diagramm unten links zeigt, dass wir eine lange, langandauernde Transaktion haben. Und wenn wir uns das obere linke Diagramm ansehen, sehen wir, dass die Größe der Tabelle von zwei Megabyte plötzlich auf 300 Megabyte angestiegen ist. Dabei hat sich die Datenmenge in der Tabelle nicht geändert, d. h. dort bleibt eine erhebliche Menge an Müll zurück.
Die allgemeine Situation in Bezug auf die durchschnittliche Antwortzeit des Servers hat sich ebenfalls um mehrere Größenordnungen verschlechtert. Das bedeutet, dass alle Anfragen an den Server erheblich zurückgehen. Gleichzeitig laufen interne Postgres-Prozesse wie der Autovakuum, die versuchen, etwas zu tun und Ressourcen verbrauchen.
Was ist mit unserem Diagramm los? Genau das gleiche. Die durchschnittliche Antwortzeit unseres Diagramms ist sprunghaft angestiegen. Konkreter zu den verbrauchten Ressourcen sehen wir, dass die CPU-Auslastung stark gestiegen ist. Das ist das obere rechte Diagramm. Und das ist geschehen, weil die CPU eine Menge nutzloser Zeilen durchgehen muss, um eine sinnvolle zu finden. Das ist das untere rechte Diagramm. Das Ergebnis: Die Anzahl der Anfragen pro Sekunde hat stark abgenommen, weil die Datenbank nicht in der Lage ist, die gleiche Anzahl von Anfragen zu verarbeiten.
Wir müssen zurück ins Leben. Wir gehen ins Internet und erfahren, dass lange Transaktionen zu einem Problem führen. Wir finden und beenden diese Transaktion und alles wird wieder normal. Alles funktioniert wie gewünscht.
Wir haben uns beruhigt, aber nach einiger Zeit bemerken wir, dass die Anwendung nicht mehr so funktioniert wie vor der Notfallsituation. Die Anfragen werden dennoch langsamer bearbeitet, und zwar erheblich langsamer. In meinem Beispiel ist es anderthalb bis zwei Mal langsamer. Die Serverlast ist ebenfalls höher als vor dem Vorfall.
Die Frage stellt sich: „Was passiert mit der Datenbank in diesem Moment?“. Mit der Datenbank liegt folgende Situation vor. Im Transaktionsdiagramm sehen Sie, dass sie angehalten hat und es tatsächlich keine langwierigen Transaktionen gibt. Aber die Größe der Tabelle ist während des Ausfalls fatal angestiegen und hat sich seitdem nicht reduziert. Die durchschnittliche Zeit in der Datenbank hat sich stabilisiert. Die Antworten scheinen in einem angemessenen Tempo zu erfolgen, das für uns akzeptabel ist. Der Autovakuum ist aktiver geworden und hat begonnen, mit der Tabelle zu arbeiten, da er mehr Daten verarbeiten muss.
Konkret zu der getesteten Tabelle mit den Konten, in der wir die Restbestände ändern: Die Antwortzeit für die Abfrage scheint wieder normal zu sein. Tatsächlich liegt sie jedoch anderthalbmal höher.
Und hinsichtlich der CPU-Belastung sehen wir, dass die Belastung nicht wieder auf das erforderliche Niveau zurückgekehrt ist, das vor dem Ausfall vorhanden war. Die Gründe dafür sind im Diagramm unten rechts zu finden. Es ist zu erkennen, dass dort ein übermäßiger Speicherverbrauch stattfindet. Das heißt, um die benötigte Zeile zu finden, verschwenden wir Serverressourcen der Datenbank, um nutzlose Daten zu durchforsten. Die Anzahl der Transaktionen pro Sekunde hat sich stabilisiert.
Im Großen und Ganzen ist es gut, aber die Situation ist schlechter als zuvor. Eine offensichtliche Degeneration der Datenbank als Folge unserer Anwendung, die mit dieser Datenbank arbeitet.
Um zu verstehen, was dort passiert, wenn Sie bei der letzten Präsentation nicht anwesend waren, gibt es jetzt ein wenig Theorie. Theorie über den internen Prozess. Was ist die Autovacuum-Funktion und was macht sie?
Kurz gefasst zum Verständnis. Zu einem bestimmten Zeitpunkt haben wir eine Tabelle. In der Tabelle befinden sich Zeilen. Diese Zeilen können aktiv, lebendig und für uns jetzt notwendig sein. In der Abbildung sind sie grün markiert. Und es gibt auch Tote Zeilen, die bereits verarbeitet wurden, aktualisiert wurden und neue Einträge erhalten haben. Diese sind markiert, weil sie für die Datenbank nicht mehr von Interesse sind. Sie liegen jedoch in der Tabelle aufgrund der Besonderheit von Postgres.
Warum ist der Autovacuum notwendig? Der Autovacuum kommt irgendwann, greift auf die Datenbank zu und fragt: „Gib mir bitte die ID der ältesten Transaktion, die derzeit in der Datenbank geöffnet ist“. Die Datenbank gibt diese ID zurück. Basierend darauf durchkämmt der Autovacuum die Zeilen in der Tabelle. Wenn er sieht, dass einige Zeilen durch wesentlich ältere Transaktionen geändert wurden, hat er das Recht, diese als wiederverwendbar zu markieren, indem er dort neue Daten speichert. Das ist ein Hintergrundprozess.
In der Zwischenzeit arbeiten wir weiter mit der Datenbank und nehmen Änderungen an der Tabelle vor. Und auf diese wiederverwendbaren Zeilen schreiben wir neue Daten. So entsteht ein Kreislauf, d. h. es entstehen immer wieder einige tote alte Zeilen, die durch neue Zeilen ersetzt werden, die wir brauchen. Und das ist ein normales Zustand für PostgreSQL.
Was ist während des Vorfalls passiert? Wie ist dieser Prozess abgelaufen?
Wir hatten eine Tabelle in einem bestimmten Zustand, einige Zeilen waren aktiv, andere inaktiv. Dann kam der Auto-Vakuum. Er fragte die Datenbank nach der ältesten Transaktion, der damit verbundenen ID. Diese ID konnte mehrere Stunden oder nur zehn Minuten alt sein. Es hängt davon ab, wie hoch die Last in Ihrer Datenbank ist. Und dann begann er, nach Zeilen zu suchen, die er als wiederverwendbar kennzeichnen kann. Er fand jedoch keine solchen Zeilen in unserer Tabelle.
Währenddessen arbeiten wir weiterhin an der Tabelle. Wir führen Updates durch und ändern Daten. Was kann die Datenbank in dieser Zeit tun? Sie bleibt nichts anderes übrig, als neue Zeilen am Ende der bestehenden Tabelle hinzuzufügen. Dadurch beginnt die Größe der Tabelle zu wachsen.
Für unsere Arbeit benötigen wir tatsächlich die aktiven Zeilen. Aber während eines solchen Problems haben wir einen sehr niedrigen Prozentsatz aktiver Zeilen im gesamten Volumen der Tabelle.
Wenn wir eine Anfrage durchführen, muss die Datenbank durch alle Zeilen, sowohl die roten als auch die grünen, durchsuchen, um die benötigte Zeile zu finden. Der Effekt der Aufblähung der Tabelle mit nutzlosen Daten wird als „bloat“ bezeichnet, der zudem unseren Speicherplatz frisst. Erinnern Sie sich, es waren 2 MB, jetzt sind es 300 MB? Und ersetzen Sie Megabyte durch Gigabyte, und Sie werden so schnell all Ihre Speicherressourcen los sein.
Welche Konsequenzen kann das für uns haben?
- In meinem Beispiel sind die Tabelle und der Index um das 150-fache gewachsen. Einige unserer Kunden hatten noch gravierendere Fälle, in denen der Speicherplatz auf der Festplatte knapp wurde.
- Die Größe von Tabellen wird nie von selbst kleiner. Der Autovacuum kann in einigen Fällen das Ende der Tabelle abtrennen, wenn dort nur tote Zeilen vorhanden sind. Da jedoch eine ständige Rotation stattfindet, kann eine grüne Zeile am Ende hängen bleiben und nicht aktualisiert werden, während alle anderen zu Beginn der Tabelle aufgezeichnet werden. Aber das ist so unwahrscheinlich, dass Sie nicht darauf hoffen sollten, dass Ihre Tabelle von selbst kleiner wird.
- Die Datenbank muss sich durch einen Haufen nutzloser Zeilen wühlen. Das kostet Speicherressourcen, CPU-Leistung und Energie.
- Und das hat unmittelbare Auswirkungen auf unsere Anwendung, denn während wir anfangs 10 Millisekunden für eine Anfrage und weitere 10 Millisekunden für unseren Code benötigten, benötigten wir während des Ausfalls eine Sekunde für die Anfrage und 10 Millisekunden für den Code. Das bedeutet, dass die Leistung der Anwendung erheblich gesunken ist. Nachdem wir den Ausfall behoben hatten, benötigten wir 20 Millisekunden für die Anfrage und 10 Millisekunden für den Code. Das heißt, dass wir immer noch eine Leistungsverschlechterung von anderthalb Mal haben. Und das alles wegen einer Transaktion, die hängen geblieben ist, möglicherweise aufgrund unseres eigenen Verschuldens.
- Und die Frage ist: „Wie bekommen wir alles wieder zurück?“, damit alles wieder gut wird und die Anfragen so schnell laufen wie vor dem Ausfall.
Es gibt dafür einen bestimmten Arbeitszyklus, der durchgeführt wird.
Zunächst müssen wir die Problem tabellen finden, die aufgebläht sind. Wir verstehen, dass für bestimmte Tabellen die Datensätze aktiver sind, für andere weniger aktiv. Und dafür wird ein Erweiterungstool verwendet. . Mit dieser Erweiterung können Sie Abfragen erstellen, die Ihnen helfen, Tabellen zu finden, die stark anwachsen.
Nachdem Sie diese Tabellen gefunden haben, müssen sie komprimiert werden. Dafür gibt es bereits Werkzeuge. In unserem Unternehmen verwenden wir drei Werkzeuge. Das erste ist das integrierte VACUUM FULL. Es ist hart, streng und kompromisslos, aber manchmal sehr nützlich. und – das sind externe Dienstprogramme zur Komprimierung von Tabellen. Sie sind schonender zu der Datenbank.
Sie werden je nach Ihren Vorlieben eingesetzt. Aber ich werde am Ende mehr darüber erzählen. Wichtig ist, dass es drei Werkzeuge gibt. Man hat die Auswahl.
Nachdem wir alles behoben und sichergestellt haben, dass alles gut ist, sollten wir wissen, wie wir diese Situation in Zukunft vermeiden können:
- Sie kann ziemlich leicht vermieden werden. Man muss die Dauer der Sitzungen auf dem Master-Server im Auge behalten. Besonders gefährlich sind Sitzungen im Zustand idle in transaction.Das sind die, die eine Transaktion eröffnet haben, etwas gemacht haben und dann weg sind oder einfach hängen geblieben sind, sich im Code verloren haben.
- Und für Sie als Entwickler ist es wichtig, den Code in dem Moment zu testen, in dem diese Situationen auftreten. Es ist nicht schwer zu bewerkstelligen. Es wird eine nützliche Kontrolle sein. Sie werden eine große Anzahl an "Kinderproblemen" im Zusammenhang mit langen Transaktionen vermeiden.
Auf diesen Grafiken wollte ich Ihnen zeigen, wie sich die Tabelle und das Verhalten der Datenbank geändert haben, nachdem ich in diesem Fall ein VACUUM FULL auf die Tabelle angewendet habe. Das ist nicht in der Produktion.
Die Tabellengröße ist sofort wieder in einen normalen Arbeitszustand von ein paar Megabyte zurückgekehrt. Das hat die durchschnittliche Antwortzeit des Servers nicht wesentlich beeinflusst.
Aber spezifisch zu unserem Testtisch, wo wir die Bestände auf den Konten aktualisiert haben, sehen wir, dass die durchschnittliche Antwortzeit für die Anfrage zur Aktualisierung der Daten in der Tabelle auf einen unkritischen Wert gesenkt wurde. Auch die vom Prozessor beanspruchten Ressourcen für die Ausführung dieser Anfrage sind auf ein unkritisches Niveau gefallen. Und das Diagramm in der rechten unteren Ecke zeigt, dass wir jetzt genau die Zeile finden, die wir brauchen, ohne durch die Menge der inaktiven Zeilen zu gehen, die vor der Verdichtung der Tabelle vorhanden waren. Die durchschnittliche Anfragezeit blieb ungefähr auf dem gleichen Niveau. Aber hier habe ich eher eine Ungenauigkeit meiner Hardware.
Hier endet die erste Geschichte. Sie ist die häufigste und passiert jedem, unabhängig von der Erfahrung des Kunden und der Qualifikation der Programmierer. Früher oder später geschieht es.
Die zweite Geschichte, in der wir die Last verteilen und die Serverressourcen optimieren.
- Wir sind gewachsen und haben uns zu ernsthaften Spielern entwickelt. Wir verstehen, dass wir eine Replikate haben und es gut wäre, die Last auszugleichen: Schreiben auf dem Master und Lesen von der Replikate. Diese Situation tritt normalerweise auf, wenn wir Berichte oder ETL erstellen möchten. Das Unternehmen ist darüber sehr erfreut. Es möchte verschiedene Berichte mit komplexer Analyse.
- Die Berichte sind zeitaufwendig, da komplexe Analysen nicht in Millisekunden berechnet werden können. Wir, als fähige Leute, schreiben den Code. Wir machen in der Anwendung Einfügungen, dass wir die Aufzeichnungen auf dem Master führen und die Berichte auf der Replikate ausführen.
- Wir verteilen die Last.
- Alles funktioniert hervorragend. Wir sind großartig.
Wie sieht diese Situation aus? Konkret habe ich auf diesen Grafiken die Dauer der Transaktionen mit der Dauer der Transaktionen von der Replikate hinzugefügt. Alle anderen Grafiken beziehen sich nur auf den Master-Server.
Die Tabelle mit den Berichten ist inzwischen gewachsen. Es gibt mehr davon. Wir sehen, dass die durchschnittliche Serverantwortzeit stabil ist. Wir sehen, dass wir auf der Replikate eine lang laufende Transaktion haben, die 2 Stunden dauert. Wir beobachten die ruhige Arbeit des Autovacuum, das tote Zeilen verarbeitet. Und es geht uns gut.
Insbesondere bei der getesteten Tabelle aktualisieren wir weiterhin die Bestände auf den Konten. Auch haben wir eine stabile Antwortzeit auf Anfragen sowie einen stabilen Ressourcenverbrauch. Bei uns läuft alles gut.
Es läuft alles gut, bis diese Berichte aufgrund von Konflikten mit der Replikation herausgeschossen werden. Und sie werden mit konstanter Regelmäßigkeit herausgeschossen.
Wir gehen ins Internet und beginnen zu lesen, warum das passiert. Und finden eine Lösung.
Die erste Lösung besteht darin, die Replikationsverzögerung zu erhöhen. Wir wissen, dass unser Bericht 3 Stunden dauert. Wir setzen die Replikationsverzögerung auf 3 Stunden. Wir starten alles, aber trotzdem haben wir weiterhin Probleme, dass Berichte manchmal herausgeschossen werden.
Wir wollen, dass alles perfekt ist. Also suchen wir weiter. Und finden im Internet eine coole Einstellung – hot_standby_feedback. Wir aktivieren es. Hot_standby_feedback ermöglicht es uns, die Arbeit des Autovacuum auf dem Master zurückzuhalten. Damit beseitigen wir völlig die Replikationskonflikte. Und bei uns funktioniert alles gut mit den Berichten.
Was passiert in dieser Zeit mit unserem Master-Server? Mit dem Master-Server haben wir ein ernsthaftes Problem. Momentan beobachten wir die Grafiken, nachdem ich beide Einstellungen aktiviert habe. Und wir sehen, dass die Sitzung auf der Replica auf irgendeine Weise die Situation auf dem Master-Server beeinflusst. Es hat tatsächlich Auswirkungen, da es den Autovacuum-Prozess unterbrochen hat, der die toten Zeilen bereinigt. Die Größe der Tabelle ist wieder in die Höhe geschossen. Die durchschnittliche Ausführungszeit der Abfragen in der gesamten Datenbank ist ebenfalls stark gestiegen. Die Autovacuum-Prozesse sind wieder ein wenig angespannt.
Insbesondere bei unserer Tabelle sehen wir, dass die Aktualisierung der Daten ebenfalls extrem gestiegen ist. Der Ressourcenverbrauch der CPU hat sich ebenfalls stark erhöht. Wir durchlaufen wieder eine große Anzahl toter, nutzloser Zeilen. Und die Antwortzeit für diese Tabelle sowie die Anzahl der Transaktionen sind gesunken.
Wie wird das aussehen, wenn wir nicht wissen, worüber ich zuvor gesprochen habe?
- Wir beginnen mit der Fehlersuche. Wenn wir in der ersten Phase auf Probleme gestoßen sind, wissen wir, dass dies auf eine lange Transaktion zurückzuführen sein kann, und wir schauen uns den Master an. Das Problem liegt auf unserem Master. Er ist überlastet. Er wird heiß, und die Last ist fast auf Hundert.
- Die Anfragen dort sind langsam, aber wir sehen keine langen Transaktionen. Wir verstehen nicht, woran es liegt. Wir wissen nicht, wo wir suchen sollen.
- Wir prüfen die Serverhardware. Vielleicht ist unser RAID ausgefallen. Vielleicht ist ein RAM-Riegel kaputt. Es könnte alles Mögliche sein. Aber nein, die Server sind neu, alles funktioniert einwandfrei.
- Alle sind in Bewegung: Administratoren, Entwickler und der Direktor. Nichts hilft.
- Und irgendwann beginnt sich alles plötzlich von selbst zu verbessern.
In der Zwischenzeit wurde auf der Replik der Auftrag erfolgreich ausgeführt und gesendet. Wir haben einen Bericht erhalten. Das Geschäft ist weiterhin zufrieden. Wie wir sehen, ist unsere Tabelle wieder gewachsen und wird nicht kleiner. In dem Diagramm mit den Sitzungen habe ich einen Ausschnitt dieser langen Transaktion von der Replikation gelassen, damit Sie den Verlauf der Stabilisierung besser abschätzen können.
Die Sitzung ist abgelaufen. Und nur nach einiger Zeit kommt der Server einigermaßen wieder in Ordnung. Und die durchschnittliche Antwortzeit für Anfragen auf dem Master-Server normalisiert sich. Das liegt daran, dass der Autovacuum endlich die Möglichkeit erhalten hat, diese toten Zeilen zu bereinigen und zu kennzeichnen. Und er hat begonnen, seine Arbeit zu machen. Und so schnell, wie er das tut, werden wir in den Normalzustand zurückkehren.
An der getesteten Tabelle, in der wir die Bestände der Konten aktualisieren, sehen wir genau das gleiche Bild. Die durchschnittliche Aktualisierungszeit des Kontos normalisiert sich ebenfalls allmählich. Die vom Prozessor verbrauchten Ressourcen verringern sich ebenfalls. Und die Anzahl der Transaktionen pro Sekunde kehrt zur Normalität zurück. Aber wieder nicht in den Zustand, wie wir ihn vor dem Ausfall hatten.
Wir haben in jedem Fall einen Rückgang der Leistung wie im ersten Fall um das eineinhalb- bis zweifache, manchmal sogar mehr.
Wir haben vermeintlich alles richtig gemacht. Die Last verteilt. Die Hardware steht nicht still. Wir haben die Anfragen vernünftig aufgeteilt, aber trotzdem ist alles schlecht gelaufen.
- Hot_standby_feedback nicht aktivieren? Ja, es wird nicht empfohlen, es ohne triftigen Grund zu aktivieren. Denn diese Einstellung hat direkten Einfluss auf den Master-Server und stoppt dort die Funktionsweise des Autovakuums. Wenn Sie es auf einer Replikation aktivieren und vergessen, kann es den Master-Server gefährden und zu großen Problemen mit der Anwendung führen.
- Die max_standby_streaming_delay erhöhen? Ja, das ist für Berichte sinnvoll. Wenn Sie einen dreistündigen Bericht haben und möchten, dass er nicht aufgrund von Replikationskonflikten fehlschlägt, erhöhen Sie einfach die Verzögerung. Ein lang laufender Bericht benötigt nie die Daten, die gerade jetzt in die Datenbank kommen. Wenn er dreistündig ist, bedeutet das, dass Sie ihn für einen älteren Zeitraum anstoßen. Ob Sie drei oder sechs Stunden Verzögerung haben, spielt keine Rolle; aber Sie können stabil Berichte erhalten, ohne Probleme mit deren Abbruch zu haben.
- Natürlich müssen wir lange Sitzungen auf den Replikaten überwachen, insbesondere wenn Sie sich entschieden haben, hot_standby_feedback auf dem Replikat zu aktivieren. Denn es kann alles Mögliche passieren. Wir haben dieses Replikat einem Entwickler gegeben, damit er Anfragen testen kann. Er hat eine verrückte Anfrage geschrieben, sie gestartet und ging dann Tee trinken, während wir einen Master erhalten haben. Oder wir haben nicht die richtige Anwendung dort ausgeführt. Die Situationen sind vielfältig. Sitzungen auf den Replikaten müssen genauso sorgfältig überwacht werden wie auf dem Master.
- Und wenn Sie schnelle und langwierige Anfragen an die Replikate haben, ist es in diesem Fall besser, sie zur Lastenverteilung aufzuteilen. Hier ist der Link zu streaming_delay. Für schnelle Anfragen sollten Sie eine Replik mit einer geringen Replikationsverzögerung haben. Für langwierige Berichtsanfragen können Sie eine Replik haben, die bis zu 6 Stunden oder einen Tag hinterherhinkt. Das ist eine völlig normale Situation.
Wir beheben die Konsequenzen auf die gleiche Weise:
- Wir finden aufgeblähte Tabellen.
- Und komprimieren sie mit dem geeignetsten Werkzeug, das uns passt.
Die zweite Geschichte endete hier. Wir machen mit der dritten Geschichte weiter.
Das ist ebenfalls ziemlich gewöhnlich für uns, in der wir eine Migration durchführen.
- Jedes Softwareprodukt entwickelt sich weiter. Die Anforderungen ändern sich. Wir möchten uns in jedem Fall weiterentwickeln. Und manchmal ist es notwendig, die Daten in der Tabelle zu aktualisieren, insbesondere um ein Update im Rahmen unserer Migration für die neuen Funktionen, die wir im Rahmen unserer Weiterentwicklung einführen, durchzuführen.
- Das alte Datenformat entspricht nicht mehr unseren Bedürfnissen. Nehmen wir an, wir schauen uns die zweite Tabelle an, in der meine Transaktionen zu diesen Konten aufgeführt sind. Angenommen, sie waren in Rubel, und wir haben beschlossen, die Genauigkeit zu erhöhen und in Kopeken zu arbeiten. Dafür müssen wir ein Update durchführen: das Feld mit dem Transaktionsbetrag mal hundert multiplizieren.
- In der modernen Welt verwenden wir automatisierte Tools zur Versionskontrolle von Datenbanken. Angenommen, wir schreiben unsere Migration hinein. Testen sie auf unserer Testdatenbank. Alles läuft hervorragend. Das Update wird durchgeführt. Es blockiert die Arbeit für eine gewisse Zeit, aber wir erhalten aktualisierte Daten. Und wir können neue Funktionen darauf basieren. Alles wurde getestet, überprüft und genehmigt.
- Wir haben planmäßige Arbeiten durchgeführt und die Migration abgeschlossen.
Hier sehen Sie die Migration mit dem Update. Da es sich bei mir um Kontenoperationen handelt, hatte die Tabelle eine Größe von 15 GB. Und da wir jede Zeile aktualisieren, haben wir die Tabelle mit dem Update verdoppelt, weil wir jede Zeile neu geschrieben haben.
Während der Migration konnten wir nichts mit dieser Tabelle machen, da alle Anfragen in der Warteschlange standen und darauf warteten, dass dieses Update abgeschlossen wird. Aber ich möchte Ihre Aufmerksamkeit auf die Zahlen auf der vertikalen Achse lenken. Das heißt, wir haben eine durchschnittliche Anfragezeit vor der Migration von etwa 5 Millisekunden und die CPU-Belastung, die Anzahl der Blockoperationen zum Lesen des Disk-Speichers, ist geringer als 7,5.
Wir haben die Migration durchgeführt und hatten wieder Probleme.
Die Migration war erfolgreich, aber:
- Die alte Funktionalität benötigt nun mehr Zeit.
- Die Tabelle ist wieder gewachsen.
- Die Serverlast ist wieder höher als zuvor.
- Und natürlich beschäftigen wir uns immer noch mit der Funktionalität, die gut lief, und haben sie etwas verbessert.
Und das ist wieder Bloat, der uns erneut das Leben schwer macht.
Hier zeige ich, dass die Tabelle, wie in den vorherigen zwei Fällen, nicht zu ihren früheren Größen zurückkehren wird. Die durchschnittliche Serverlast scheint angemessen zu sein.
Wenn wir jedoch auf die Tabelle mit den Abfragen schauen, sehen wir, dass die durchschnittliche Abfragezeit sich verdoppelt hat. Die CPU-Auslastung und die Anzahl der abgerufenen Zeilen im Speicher sind auf über 7,5 gestiegen, zuvor lag sie darunter. Bei den Prozessoren hat sich die Last verdoppelt, bei blockbasierten Operationen um das 1,5-fache, was bedeutet, dass wir eine Leistungseinbuße des Servers erhalten haben. Und als Folge davon – eine Leistungseinbuße unserer Anwendung. Die Anzahl der Aufrufe blieb dabei ungefähr auf dem gleichen Niveau.
Hier ist es wichtig zu verstehen, wie man solche Migrationen richtig durchführt. Und das muss gemacht werden. Wir führen diese Migrationen ziemlich regelmäßig durch.
- Solch große Migrationen werden nicht automatisch durchgeführt. Sie müssen immer kontrolliert werden.
- Es ist notwendig, dass eine sachkundige Person die Kontrolle hat. Wenn Sie einen DBA im Team haben, sollte der das übernehmen. Das ist seine Aufgabe. Wenn nicht, sollte die erfahrenste Person die Migration durchführen, die weiß, wie man mit Datenbanken arbeitet.
- Das neue Datenbankschema sorgt dafür, dass wir auch dann, wenn wir eine Spalte aktualisieren, immer schrittweise arbeiten, also im Voraus, bevor die neue Version der Anwendung veröffentlicht wird.
- Es werden neue Felder hinzugefügt, in die wir die aktualisierten Daten schreiben werden.
- Wir transferieren die Daten aus dem alten Feld in das neue Feld in kleinen Mengen. Warum machen wir das? Erstens kontrollieren wir diesen Prozess ständig. Wir wissen, dass wir bereits eine bestimmte Anzahl von Chargen übertragen haben und noch eine bestimmte Anzahl übrig ist.
- Ein weiterer positiver Aspekt ist, dass wir zwischen jeder Charge eine Transaktion abschließen und eine neue öffnen, was dem Auto-Vakuum erlaubt, die Tabelle zu verarbeiten und tote Zeilen zur Wiederverwendung zu kennzeichnen.
- Für die Zeilen, die während des Betriebs der Anwendung erscheinen (da unsere alte Anwendung noch aktiv ist), fügen wir einen Trigger hinzu, der neue Werte in die neuen Felder schreibt. In unserem Fall ist das das alte Value multipliziert mit hundert.
- Wenn wir absolut hartnäckig sind und dasselbe Feld wollen, benennen wir einfach nach Abschluss aller Migrationen und vor dem Rollout der neuen Version der Anwendung die Felder um. Die alten in irgendeinen einfallenden Namen und die neuen Felder benennen wir in die alten um.
- Und erst nach diesem Schritt starten wir die neue Version der Anwendung.
Und dabei erhalten wir keinen Bloat und verlieren nicht an Leistung.
So endet die dritte Geschichte.
Jetzt etwas ausführlicher zu den Werkzeugen, die ich in der ersten Geschichte erwähnt habe.
Bevor Sie nach Bloat suchen, sollten Sie unbedingt die Erweiterung installieren. .
Um Ihnen das Erstellen der Abfragen zu ersparen, haben wir in unserer Arbeit diese Abfragen bereits erstellt. Sie können sie verwenden. Hier sind zwei Abfragen dargestellt.
- Die erste Abfrage läuft zwar länger, aber sie zeigt Ihnen die genauen Werte des Bloat in der Tabelle.
- Die zweite Abfrage läuft schneller und ist sehr effektiv, wenn es darum geht, schnell zu beurteilen, ob es Bloat in der Tabelle gibt oder nicht. Sie müssen auch verstehen, dass Bloat in der Postgres-Tabelle immer vorhanden ist. Das ist eine Eigenheit seines MVCC-Modells.
- Und 20 % Bloat sind in den meisten Fällen für Tabellen normal. Das heißt, Sie müssen sich keine Sorgen machen und diese Tabelle nicht komprimieren.
Wie man Tabellen erkennt, die bei uns aufgebläht sind, haben wir verstanden, insbesondere wann sie mit nutzlosen Daten aufgebläht wurden.
Nun, wie man Bloat behebt:
- Wenn wir eine kleine Tabelle und gute Festplatten haben, d. h. bei einer Tabelle bis zu einem Gigabyte, kann man gut VACUUM FULL verwenden. Es wird für einige Sekunden eine exklusive Sperre auf die Tabelle erfordern und gut ist, dafür erledigt es alles schnell und gründlich. Was macht VACUUM FULL? Es nimmt eine exklusive Sperre auf die Tabelle und schreibt die lebenden Zeilen aus alten Tabellen in die neue Tabelle. Und am Ende tauscht es sie aus. Die alten Dateien werden gelöscht und die neuen ersetzen die alten. Aber während seiner Arbeit nimmt es eine exklusive Sperre auf die Tabelle. Das bedeutet, dass Sie mit dieser Tabelle nichts tun können: Sie können nicht in sie schreiben, nicht in sie lesen und sie nicht modifizieren. VACUUM FULL benötigt außerdem zusätzlichen Speicherplatz auf der Festplatte, um die Daten zu speichern.
- Das nächste Werkzeug . Es funktioniert im Prinzip ähnlich wie VACUUM FULL, da es ebenfalls Daten aus alten Dateien in neue schreibt und sie in der Tabelle ersetzt. Allerdings wird dabei nicht von Anfang an ein exklusives Lock auf die Tabelle gesetzt, sondern nur zu dem Zeitpunkt, wenn die neuen Daten bereit sind, um die Dateien zu ersetzen. Die Anforderungen an den Speicherplatz sind die gleichen wie bei VACUUM FULL. Sie benötigen zusätzlichen Speicherplatz, was kritisch werden kann, wenn Sie Terabyte große Tabellen haben. Außerdem ist er ziemlich ressourcenintensiv, da er aktiv mit Ein- und Ausgabeoperationen arbeitet.
- Das dritte Dienstprogramm ist . Es geht sparsamer mit den Ressourcen um, da es nach etwas anderen Prinzipien arbeitet. Der Hauptzweck von pgcompacttable besteht darin, dass es die aktiven Zeilen in der Tabelle nach vorne verschiebt. Anschließend führt es ein VACUUM auf dieser Tabelle durch, da wir wissen, dass am Anfang die aktiven und am Ende die inaktiven Zeilen stehen. Das VACUUM schneidet dann den unnötigen Rest ab, was bedeutet, dass es nicht viel zusätzlichen Speicherplatz benötigt. Zudem kann es hinsichtlich der Ressourcen noch weiter optimiert werden.
Das sind die Werkzeuge.
Wenn Ihnen das Thema Bloat interessant erscheint und Sie tiefer eintauchen möchten, hier sind einige nützliche Links:
- – das ist ein Vortrag meines Kollegen. Er gibt einen Überblick darüber, wo der Speicherplatz in Postgres während seiner Arbeit und Lebensdauer hingeht. Und es gibt einen sehr großen und detaillierten technischen Teil für Datenbankadministratoren über Bloat.
- – das ist der Link zu unserem Repository, wo wir viele nützliche Skripte zur Überprüfung des Datenbankstatus aufbewahren. Dort finden Sie Skripte zur Suche nach Bloat.
- und Links zu Werkzeugen, die Ihnen helfen, Tabellen zu komprimieren.
- – das ist ein Beitrag meines Kollegen. Darin wird Bloat auf einem niveauvollen und detaillierten technischen Level behandelt, das besonders für Administratoren relevant ist.
Ich habe versucht, den Entwicklern ein Schreckensszenario darzustellen, da sie unsere direkten Kunden der Datenbanken sind und verstehen müssen, welche Auswirkungen ihre Handlungen haben. Ich hoffe, mir ist das gelungen. Vielen Dank für Ihre Aufmerksamkeit!
Fragen
Vielen Dank für den Vortrag! Sie sprachen darüber, wie Probleme identifiziert werden können. Aber wie kann man sie vorhersehen? Ich hatte eine Situation, in der die Anfragen nicht nur deshalb hängen blieben, weil sie auf bestimmte externe Dienste zugriffen. Es waren einfach einige komplizierte Joins. Es gab einige harmlose, winzige Anfragen, die über einen Tag hinweg hängen blieben und dann anfingen, merkwürdige Dinge zu tun. Das klingt sehr nach dem, was Sie beschreiben. Wie kann man das verfolgen? Soll ich ständig kontrollieren, welche Anfrage hängt? Wie kann man das verhindern?
In diesem Fall ist es die Aufgabe der Administratoren Ihres Unternehmens, nicht unbedingt der DBA.
Ich bin Administrator.
In PostgreSQL gibt es eine Ansicht namens pg_stat_activity, die die hängenden Abfragen anzeigt. Dort können Sie sehen, wie lange sie dort hängen.
Muss ich alle 5 Minuten nachsehen?
Richten Sie einen Cron-Job ein und überprüfen Sie es regelmäßig. Wenn Sie eine lang laufende Anfrage haben, senden Sie eine E-Mail und das war's. Sie müssen nicht ständig nachsehen; das kann automatisiert werden. Sie erhalten eine E-Mail, auf die Sie reagieren können. Alternativ können Sie auch automatische Benachrichtigungen einrichten.
Gibt es klare Gründe, warum das passiert?
Ich habe einige aufgelistet. Es gibt auch kompliziertere Beispiele. Und das Gespräch könnte lange dauern.
Danke für den Vortrag! Ich wollte noch etwas zur pg_repack-Nutzung klären. Wenn es keine exklusive Sperre macht, dann…
Es macht eine exklusive Sperre.
… könnte ich potenziell Daten verlieren. Mein Programm sollte in dieser Zeit nichts schreiben?
Nein, es arbeitet ruhig mit der Tabelle, d. h. pg_repack überträgt zuerst alle aktiven Zeilen. Natürlich gibt es dabei einige Schreibvorgänge in der Tabelle. Es fügt einfach diesen kleinen Rest hinzu.
Das heißt, er macht es am Ende tatsächlich?
Am Ende nimmt er die exklusive Sperre, um diese Dateien zu tauschen.
Wird das schneller sein als VACUUM FULL?
VACUUM FULL, sobald es gestartet wurde, nimmt sofort eine exklusive Sperre. Und solange es nicht alles erledigt hat, gibt es sie nicht frei. pg_repack nimmt eine exklusive Sperre nur während des Austausches der Dateien. In diesem Moment können Sie dort nicht schreiben, aber die Daten gehen nicht verloren, alles wird in Ordnung sein.
Hallo! Sie haben von der Funktionsweise des Autovacuum gesprochen. Dort gab es ein Diagramm mit roten, gelben und grünen Zellen. Das heißt, die gelben wurden als gelöscht markiert. Kann man in diese alten Zellen etwas Neues eintragen?
Ja. Postgres löscht die Zeilen nicht. Das ist eine Besonderheit von ihm. Wenn wir eine Zeile aktualisieren, wird die alte als gelöscht markiert. Dort wird die ID der Transaktion, die diese Zeile geändert hat, eingetragen und eine neue Zeile wird geschrieben. Und wir haben Sessions, die potenziell darauf zugreifen können. Irgendwann werden sie ganz alt. Der Autovacuum läuft über diese Zeilen und markiert sie als nicht mehr benötigt. In diese können dann neue Daten zurückgeschrieben werden.
Ich verstehe. Aber die Frage zielt etwas anders ab. Ich habe noch nicht abgeschlossen. Angenommen, wir haben eine Tabelle. Darin gibt es Felder variabler Größe. Und wenn ich versuche, etwas Neues einzufügen, passt es möglicherweise einfach nicht in die alte Zelle.
Nein, in jedem Fall wird die gesamte Zeile aktualisiert. In Postgres gibt es zwei Modelle zur Speicherung von Daten. Er wählt basierend auf dem Datentyp. Es gibt Daten, die direkt in der Tabelle gespeichert werden, und es gibt auch tos-Daten. Das sind große Datenmengen: Text, JSON. Diese werden in separaten Tabellen gespeichert. Und dasselbe Problem mit Bloat tritt auch bei diesen Tabellen auf, d. h. alles bleibt gleich. Sie sind nur separat ausgelagert.
Vielen Dank für den Vortrag! Wie akzeptabel ist es, um die Dauer von Anfragen den Statement Timeout zu verwenden?
Sehr akzeptabel. Wir verwenden das überall. Da wir keine eigenen Dienste haben und Fernsupport leisten, haben wir ziemlich unterschiedliche Kunden. Alle sind damit vollkommen zufrieden. Das heißt, wir haben Aufgaben in cron, die dies überprüfen. Mit dem Kunden wird einfach die Dauer der Sitzungen besprochen, bevor wir sie beenden. Das kann eine Minute sein, das kann 10 Minuten sein. Das hängt von der Last auf der Datenbank und ihrem Ziel ab. Aber bei allen nutzen wir pg_stat_activity.
Vielen Dank für die Präsentation! Ich versuche, Ihre Präsentation auf meine Anwendungen anzuwenden. Und anscheinend starten wir überall die Transaktion, beenden sie überall ausdrücklich. Wenn eine Ausnahme auftritt, findet trotzdem ein Rollback statt. Und da habe ich nachgedacht. Denn die Transaktion kann möglicherweise nicht ausdrücklich starten. Das ist vermutlich ein Hinweis für die Dame. Wenn ich einfach einen Datensatz aktualisiere, wird in PostgreSQL die Transaktion gestartet und sie wird erst beendet, wenn die Verbindung unterbrochen wird?
Wenn Sie jetzt vom Anwendungstransaktionsniveau sprechen, hängt das von dem Treiber ab, den Sie verwenden, von dem ORM, das eingesetzt wird. Es gibt dort sehr viele Einstellungen. Wenn bei Ihnen auto commit aktiviert ist, wird die Transaktion gestartet und sofort geschlossen.
D. h. wird sie sofort nach dem Update geschlossen?
Das hängt von den Einstellungen ab. Eine Einstellung habe ich genannt: auto commit. Sie ist ziemlich verbreitet. Wenn sie aktiv ist, wird die Transaktion gestartet und sofort geschlossen. Wenn Sie nicht ausdrücklich «start transaction» und «end transaction» gesagt haben, sondern einfach eine Abfrage in der Sitzung gestartet haben.
Hallo! Danke für den Bericht! Stellen wir uns vor, wir haben eine Datenbank, die immer größer wird und auf dem Server geht der Speicher aus. Gibt es irgendwelche Werkzeuge, um diese Situation zu beheben?
Den Speicherplatz auf dem Server sollte man regelmäßig überwachen.
Zum Beispiel, der DBA ist gerade beim Tee trinken, war im Urlaub usw.
Wenn ein Dateisystem erstellt wird, dann wird dort zumindest ein gewisser Freiraum reserviert, wo keine Daten geschrieben werden.
Was ist, wenn der Speicher ganz voll ist?
Das nennt sich reservierter Speicher, das heißt, man kann ihn freimachen und je nach Größe, die ihm zugewiesen wurde, erhält man freien Platz. Standardmäßig weiß ich nicht, wie viel da ist. Ansonsten muss man Festplatten hinzufügen, damit man Speicherplatz für die Wiederherstellungsoperation hat. Man kann eine Tabelle löschen, die garantiert nicht benötigt wird.
Gibt es keine anderen Werkzeuge?
Das ist immer Handarbeit. Und je nach Platz wird entschieden, was dort am besten gemacht werden kann, denn es gibt kritische und nicht kritische Daten. Und für jede Datenbank und Anwendung, die damit arbeitet, hängt es vom Geschäft ab. Man entscheidet immer je nach Platz.
Vielen Dank für den Vortrag! Ich habe zwei Fragen. Erstens, Sie haben Folien präsentiert, auf denen gezeigt wird, dass bei hängenden Transaktionen sowohl der Umfang des Tabellenraums als auch die Größe des Indexes ansteigt. Danach gab es viele Tools, die die Tabelle verpacken. Was ist mit dem Index?
Die verpacken sie auch.
Aber der Vakuum betrifft den Index nicht?
Einige arbeiten mit dem Index. Zum Beispiel pg_rapack, pgcompacttable. VACUUM rekonstruiert die Indizes, wirkt sich auf sie aus. Bei VACUUM FULL geht es darum, alles neu zu schreiben, d.h. es wirkt auf alle.
Und die zweite Frage. Ich habe nicht verstanden, warum die Berichte auf Replikaten so stark von der Replikation selbst abhängen. Ich dachte, Berichte sind Lesevorgänge und Replikation ist ein Schreibvorgang.
Worin besteht der Konflikt bei der Replikation? Wir haben einen Master, auf dem Prozesse laufen. Dort findet ein Autovacuum statt. Was macht das Autovacuum? Es entfernt alte Zeilen. Wenn zu diesem Zeitpunkt ein Abfrage auf der Replik läuft, die diese alten Zeilen liest, und der Master festgestellt hat, dass das Autovacuum diese Zeilen als potenziell überschreibbar markiert hat, dann werden wir sie überschreiben. Und es kam ein Datenpaket, als wir die Zeilen überschreiben sollten, die für die Abfrage auf der Replik erforderlich sind; der Replikationsprozess wartet dann auf das Timeout, das Sie eingestellt haben. Danach wird PostgreSQL entscheiden, was für ihn wichtiger ist. Und die Replikation ist ihm wichtiger als die Abfrage, also wird er die Abfrage zurückweisen, um diese Änderungen auf der Replik auszuführen.
Andrey, ich habe eine Frage. Sind diese wunderbaren Diagramme, die Sie während der Präsentation gezeigt haben, das Ergebnis Ihrer Arbeit mit einem Ihrer Tools? Was wurde verwendet, um die Diagramme zu erstellen?
Es ist ein Dienst. .
Ist es ein kommerzielles Produkt?
Ja. Es ist ein kommerzielles Produkt.
Quelle: habr.com
