Typische Fehler in Anwendungen, die zu Bloat in PostgreSQL führen. Andrey Salnikov

Ich lade Sie ein, sich mit der Transkription des Berichts von Andrej Salnikow aus dem Anfang des Jahres 2016 "Typische Fehler in Anwendungen, die zu Bloat in PostgreSQL führen" vertraut zu machen.

In diesem Bericht werde ich die häufigsten Fehler in Anwendungen behandeln, die in der Phase des Designs und des Schreibens des Anwendungscodes auftreten. Ich werde nur die Fehler betrachten, die zu Bloat in PostgreSQL führen. In der Regel ist dies der Anfang vom Ende der Leistungsfähigkeit Ihres Systems insgesamt, obwohl anfangs keine Anzeichen dafür zu erkennen waren.

Ich begrüße alle herzlich! Dieser Bericht ist nicht so technisch wie der vorherige von meinem Kollegen. Dieser Bericht richtet sich hauptsächlich an Entwickler von Backend-Systemen, da wir eine ziemlich große Anzahl von Kunden haben. Und alle machen die gleichen Fehler. Ich werde darüber sprechen. Ich erkläre, welche katastrophalen und negativen Folgen diese Fehler haben können.

Warum werden Fehler gemacht? Sie entstehen aus zwei Gründen: aus einer gewissen Unbekümmertheit – vielleicht klappt es ja so – 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 schlecht geworden ist. Ich werde kurz den Mechanismus erklären, der dort abläuft. Und wie man damit umgeht, wenn sie auftreten, und welche präventiven Methoden man anwenden kann, um Fehler zu verhindern. Ich werde über Hilfsmittel sprechen und nützliche Links bereitstellen.

Ich habe eine Testdatenbank verwendet, in der ich zwei Tabellen hatte. Eine Tabelle mit den Konten der Kunden, die andere mit den Transaktionen für diese Konten. Und in regelmäßigen Abständen aktualisieren wir die Salden dieser Konten.

Die Ausgangsdaten der Tabelle: sie ist recht klein, 2 MB. Die Antwortzeiten für die Datenbank und speziell für die Tabelle sind ebenfalls sehr gut. Und die Last ist ebenfalls gut – 2.000 Transaktionen pro Sekunde für die Tabelle.

Und durch diesen Bericht werde ich Ihnen Grafiken zeigen, um anschaulich zu demonstrieren, was passiert. Es wird immer zwei Folien mit Grafiken geben. Die erste Folie zeigt, was insgesamt auf dem Server passiert.

Und in dieser Situation sehen wir, dass unsere Tabelle tatsächlich klein ist. Der Index ist klein und beträgt 2 MB. Das ist das erste Diagramm von links.

Die durchschnittliche Antwortzeit des Servers ist ebenfalls stabil und gering. Das ist das obere rechte Diagramm.

Das linke untere Diagramm zeigt die längeren Transaktionen. Wir sehen, dass die Transaktionen schnell ausgeführt werden. Und der Auto-Vakuum funktioniert hier noch nicht, da es sich um einen Start-Test handelte. In Zukunft wird er funktionieren und uns nützlich sein.

Die zweite Folie ist immer der Testtabelle gewidmet. In dieser Situation aktualisieren wir kontinuierlich die Bestände auf den Konten des Kunden. Wir sehen, dass die durchschnittliche Antwortzeit für die Aktualisierungsoperationen ziemlich gut ist, weniger als eine Millisekunde. Wir sehen auch, dass die Ressourcen des Prozessors (das ist das rechte obere Diagramm) gleichmäßig und recht gering verbraucht werden.

Das rechte untere Diagramm zeigt, wie viel Arbeitsspeicher und Festplattenspeicher wir durchsuchen, um unsere benötigte Zeile zu finden, bevor wir sie aktualisieren. Und die Anzahl der Operationen auf der Tabelle – 2.000 pro Sekunde, wie ich zu Beginn gesagt habe.

Und jetzt passiert eine Tragödie. Aus irgendeinem Grund tritt eine lange vergessene Transaktion auf. Die Ursachen sind normalerweise banal:

• Eine der häufigsten Ursachen ist, dass wir im Anwendungscode begonnen haben, auf einen externen Dienst zuzugreifen. Und dieser Dienst antwortet uns nicht. Das heißt, wir haben eine Transaktion eröffnet, Änderungen in der Datenbank vorgenommen und sind aus der Anwendung gegangen, um die E-Mails zu lesen oder zu einem anderen Dienst in unserer Infrastruktur zu wechseln, und dieser antwortet aus irgendeinem Grund nicht. Und wir haben eine Sitzung, die im Status hängt – unklar, wann sie gelöst wird.
• Die zweite Situation ist, wenn im Code aus irgendeinem Grund eine Ausnahme aufgetreten ist. Und wir haben in der Ausnahme das Schließen der Transaktion nicht behandelt. Und wir haben eine hängende Sitzung mit einer offenen Transaktion.
• Und der letzte Fall – das ist auch ein häufiges Phänomen. Das ist minderwertiger Code. Einige Frameworks eröffnen eine Transaktion. Sie hängt, und Sie könnten nicht wissen, dass sie in Ihrer Anwendung hängt.

Was führen solche Dinge zur Folge?

Dazu, dass unsere Tabellen und Indizes stark anwachsen. Das ist genau der Effekt der Aufblähung. Für die Datenbank wird sich das in einer drastischen Erhöhung der Antwortzeit der Datenbank äußern, und die Belastung des Datenbankservers wird steigen. Als Ergebnis wird die Anwendung leiden. Denn wenn Sie im Code 10 Millisekunden für eine Anfrage an die Datenbank und 10 Millisekunden für Ihre Logik aufgewendet haben, dann arbeitete Ihre Funktion in 20 Millisekunden. Jetzt wird Ihre Situation jedoch ganz traurig sein.

Und lassen Sie uns sehen, was passiert. Das linke untere Diagramm zeigt, dass wir eine lange, ausgedehnte Transaktion haben. Und wenn wir uns das obere linke Diagramm ansehen, sehen wir, dass sich die Größe der Tabelle von zwei Megabyte plötzlich auf 300 Megabyte erhöht hat. Dabei hat sich die Datenmenge in der Tabelle nicht verändert, d. h. es gibt eine beträchtliche Menge an Müll.

Die allgemeine Situation hinsichtlich der durchschnittlichen Serverantwortzeit hat sich ebenfalls um mehrere Größenordnungen verändert. Das bedeutet, dass alle Anfragen an den Server erheblich langsamer geworden sind. Und dabei haben interne Prozesse von Postgres in Form des Autovacuum-Tools begonnen, etwas zu versuchen und Ressourcen zu verbrauchen.

Was passiert also mit unserer Tabelle? Dasselbe. Die durchschnittliche Antwortzeit für die Tabelle ist um mehrere Größenordnungen angestiegen. Konkrete Auswirkungen auf die verbrauchten Ressourcen zeigen, dass die Belastung der CPU stark gestiegen ist. Dies ist das obere rechte Diagramm. Es hat zugenommen, weil die CPU eine Menge nutzloser Zeilen durchforsten muss, um eine benötigte zu finden. Dies ist das untere rechte Diagramm. Und als Ergebnis hat die Anzahl der Aufrufe pro Sekunde stark abgenommen, da die Datenbank nicht in der Lage ist, die gleiche Anzahl von Anfragen zu bearbeiten.

Wir müssen wieder ins Leben zurückkehren. Wir gehen ins Internet und erfahren, dass lange Transaktionen zu Problemen führen. Wir finden und beenden diese Transaktion. Und alles wird wieder normal. Alles funktioniert wie gewünscht.

Wir beruhigen uns, doch nach einiger Zeit bemerken wir, dass die Anwendung nicht mehr so funktioniert wie vor dem Ausfall. Die Anfragen werden dennoch langsamer bearbeitet, und zwar erheblich langsamer. Im Beispiel meiner Situation um eineinhalb bis zweimal langsamer. Die Serverlast ist ebenfalls höher als vor dem Ausfall.

Und die Frage lautet: „Was passiert in diesem Moment mit der Datenbank?“. Mit der Datenbank passiert Folgendes. Im Diagramm der Transaktionen sehen Sie, dass sie gestoppt ist und es tatsächlich keine langen Transaktionen gibt. Aber die Größen der Tabelle sind während des Ausfalls katastrophal gestiegen. Und seitdem sind sie nicht mehr gesunken. Die durchschnittliche Zeit der Datenbank hat sich stabilisiert. Die Antworten scheinen in einem für uns akzeptablen Tempo zu kommen. Der Autovacuum-Prozess ist aktiver geworden und hat begonnen, etwas mit der Tabelle zu machen, weil er eine größere Menge an Daten verarbeiten muss.

Bezüglich der getesteten Tabelle mit den Abrechnungen, wo wir die Reste ändern: Die Antwortzeit auf die Anfrage scheint sich normalisiert zu haben. Aber in der Tat liegt sie anderthalb Mal höher.

Und bezüglich der CPU-Auslastung sehen wir, dass die CPU-Belastung bis zur Panne nicht wieder auf die erforderlichen Werte zurückgekehrt ist. Die Ursachen verstecken sich gerade im rechten unteren Diagramm. Man sieht, dass hier eine Überprüfung einer bestimmten Menge von Speicher stattfindet. Das heißt, um die benötigte Zeile zu finden, verbrauchen wir die Ressourcen des Servers, während wir durch nutzlose Daten durchforsten. Die Anzahl der Transaktionen pro Sekunde hat sich stabilisiert.

Insgesamt ist es gut, aber die Situation ist schlimmer als zuvor. Eine offensichtliche Degeneration der Datenbank als Folge unserer Anwendung, die mit dieser Datenbank arbeitet.

Um zu verstehen, was dort passiert, falls Sie nicht bei dem vorherigen Bericht waren, gibt es jetzt ein wenig Theorie. Die Theorie über den internen Prozess. Warum benötigen wir den Autovacuum und was macht er?

Kurz gesagt, um es zu verstehen. Zu einem bestimmten Zeitpunkt haben wir eine Tabelle. In der Tabelle befinden sich Zeilen. Diese Zeilen können aktiv, lebendig und jetzt für uns wichtig sein. Im Bild sind sie grün markiert. Es gibt auch tote Zeilen, die bereits verarbeitet wurden, aktualisiert wurden und für die neue Einträge erschienen sind. Und sie sind markiert, dass sie der Datenbank nicht mehr von Interesse sind. Aber sie liegen aufgrund der Besonderheit von Postgres in der Tabelle.

Warum benötigen wir den Autovacuum? Der Autovacuum fragt irgendwann die Datenbank und sagt: „Gib mir bitte die ID der ältesten Transaktion, die derzeit in der Datenbank geöffnet ist“. Die Datenbank gibt diese ID zurück. Und der Autovacuum greift darauf zurück und durchforstet die Zeilen in der Tabelle. Wenn er sieht, dass einige Zeilen von wesentlich älteren Transaktionen verändert wurden, hat er das Recht, sie als Zeilen zu kennzeichnen, die wir in Zukunft wiederverwenden können, indem wir dort neue Daten schreiben. Dies ist ein Hintergrundprozess.

In der Zwischenzeit arbeiten wir weiterhin mit der Datenbank, führen Änderungen in der Tabelle durch. Und in diese Zeilen, die wir wiederverwenden können, schreiben wir neue Daten. So entsteht ein Kreislauf, das heißt, es gibt ständig alte tote Zeilen, und an ihrer Stelle schreiben wir neue Zeilen, die wir benötigen. Und das ist ein normaler Zustand für die Arbeit von PostgreSQL.

Was ist während des Vorfalls passiert? Wie hat dieser Prozess stattgefunden?

Wir hatten eine Tabelle in einem bestimmten Zustand, einige lebende, einige tote Zeilen. Der Autovacuum kam. Er fragte die Datenbank nach der ältesten Transaktion, die wir haben, welcher ID sie hat. Er erhielt diese ID, die viele Stunden zurückliegen könnte, vielleicht nur zehn Minuten. Das hängt davon ab, wie stark die Last in Ihrer Datenbank ist. Und er ging auf die Suche nach Zeilen, die er als wiederverwendbar markieren kann. Und er fand keine solchen Zeilen in unserer Tabelle.

Aber wir arbeiten in der Zwischenzeit weiter an der Tabelle. Wir tun etwas darin, aktualisieren, ändern Daten. Und was kann die Datenbank in dieser Zeit tun? Sie kann nichts anderes tun, als neue Zeilen am Ende der bestehenden Tabelle hinzuzufügen. Dadurch beginnt die Größe der Tabelle zu wachsen.

In Wirklichkeit benötigen wir für die Arbeit grüne Zeilen. Aber während eines solchen Problems haben wir, dass der Anteil grüner Zeilen im gesamten Volumen der Tabelle extrem niedrig ist.

Wenn wir jedoch eine Abfrage durchführen, muss die Datenbank durch alle Zeilen gehen: sowohl rote als auch grüne, um die benötigte Zeile zu finden. Und der Effekt der Aufblähung der Tabelle mit nutzlosen Daten heißt 'Bloat', das auch unseren Speicherplatz frisst. Erinnern Sie sich, es waren 2 MB, es wurden 300 MB? Und jetzt tauschen Sie Megabyte gegen Gigabyte aus und Sie werden recht schnell all Ihre Speicherkapazitäten verlieren.

Welche Folgen kann das für uns haben?

• In meinem Beispiel ist die Tabelle und der Index um das 150-fache gewachsen. Einige unserer Kunden hatten noch fatalere Fälle, als der Speicherplatz auf der Festplatte zu Ende ging.
• Die Größe der Tabellen wird sich nie von selbst verringern. Der Autovacuum kann in einigen Fällen das Ende der Tabelle abschneiden, wenn dort nur tote Zeilen sind. Aber da eine ständige Rotation stattfindet, könnte eine grüne Zeile am Ende hängen bleiben und nicht aktualisiert werden, während alle anderen irgendwo am Anfang der Tabelle geschrieben werden. Aber das ist ein so unwahrscheinliches Ereignis, dass man nicht darauf hoffen sollte, dass sich die Tabelle von selbst verkleinert.
• Die Datenbank muss durch einen Haufen nutzloser Zeilen gehen. Und wir verschwenden Speicherressourcen, CPU-Ressourcen und Elektrizität.
• Und das hat direkte Auswirkungen auf unsere Anwendung, denn wenn wir am Anfang 10 Millisekunden für die Anfrage und 10 Millisekunden für unseren Code benötigten, verbrauchten wir während des Ausfalls eine Sekunde für die Anfrage und 10 Millisekunden für den Code, d. h. die Leistung der Anwendung hat sich um den Faktor 10 verschlechtert. Und als der Ausfall behoben wurde, benötigten wir 20 Millisekunden für die Anfrage und 10 Millisekunden für den Code. Das bedeutet, dass wir immer noch um das 1,5-fache in der Leistung gefallen sind. Und das alles wegen einer Transaktion, die festhing, möglicherweise aufgrund unseres Verschuldens.
• Und die Frage ist: „Wie können wir alles zurückbringen?“, damit alles gut wird und die Anfragen so schnell laufen wie vor dem Ausfall.

Dafür gibt es einen bestimmten Arbeitszyklus, der durchgeführt werden muss.

Zunächst müssen wir die problematischen Tabellen finden, die aufgebläht sind. Wir verstehen, dass einige Tabellen aktiver beschreiben, andere weniger aktiv. Dafür wird die Erweiterung pgstattupleverwendet. Mit dieser Erweiterung können Sie Abfragen schreiben, die Ihnen helfen, die Tabellen zu finden, die sich stark aufgebläht haben.

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 brutal, hart und schonungslos, aber manchmal ist es sehr nützlich. Pg_repack und pgcompacttable sind Drittanbieter-Utilities zur Komprimierung von Tabellen. Und sie gehen behutsamer mit der Datenbank um.

Sie werden je nach Ihrer Bequemlichkeit verwendet. Aber dazu werde ich am Ende mehr sagen. Wichtig ist, dass es drei Werkzeuge gibt. Es gibt genug Auswahl.

Nachdem wir alles korrigiert haben und sichergestellt haben, dass alles gut geworden ist, müssen wir wissen, wie wir diese Situation in Zukunft vermeiden können:

• Das kann relativ einfach verhindert werden. Man muss die Dauer der Sitzungen auf dem Master-Server überwachen. Besonders gefährlich sind Sitzungen im Status idle in transaction.Das sind die, die gerade eine Transaktion geöffnet haben, etwas gemacht haben und dann weggegangen sind oder einfach hängen geblieben sind, verloren im Code.
• Und für Sie, als Entwickler, ist es wichtig, den Code in dem Moment zu testen, in dem solche Situationen entstehen. Das ist nicht schwer zu machen. Es wird eine nützliche Überprüfung sein. Sie vermeiden eine große Anzahl von „Anfangs“-Problemen, die mit langen Transaktionen verbunden sind.

Auf diesen Grafiken wollte ich Ihnen zeigen, wie sich die Tabelle und das Verhalten der Datenbank verändert haben, nachdem ich in diesem Fall mit VACUUM FULL auf die Tabelle zugegriffen habe. Das ist nicht in der Produktion.

Die Größe der Tabelle hat sofort wieder einen normalen Arbeitszustand von ein paar Megabyte erreicht. Dies hatte keinen signifikanten Einfluss auf die durchschnittliche Antwortzeit des Servers.

Insbesondere bei unserer getesteten Tabelle, in der wir die Bestände auf den Konten aktualisiert haben, sehen wir, dass die durchschnittliche Antwortzeit für das Datenaktualisierungsanfrage auf ein sicheres Niveau gesenkt wurde. Auch die vom Prozessor verbrauchten Ressourcen zur Ausführung dieser Anfrage sind auf ein sicheres Niveau gefallen. Und das rechte untere Diagramm zeigt, dass wir jetzt genau die Zeile finden, die wir benötigen, ohne durch die Sammlung toter Zeilen zu gehen, die vor der Kompression der Tabelle existierte. Die durchschnittliche Anfragenzeit blieb ungefähr auf demselben Niveau. Aber hier ist wohl eher eine Ungenauigkeit meiner Hardware.

Damit endet die erste Geschichte. Sie ist die häufigste und passiert jedem, unabhängig von der Erfahrung des Kunden oder der Qualifikation der Programmierer. Früher oder später geschieht das.

Die zweite Geschichte, in der wir die Last verteilen und die Serverressourcen optimieren.

• Wir sind bereits gewachsen und zu ernsthaften Akteuren geworden. Und wir verstehen, dass wir eine Replikation haben und es gut wäre, die Last zu balancieren: Schreiben auf den Master und Lesen von der Replikation. Diese Situation entsteht normalerweise, wenn wir Berichte oder ETL-Operationen erstellen möchten. Das erfreut das Geschäft sehr. Es möchte viele unterschiedliche Berichte mit einer Menge komplexer Analysen.
• Die Berichte dauern viele Stunden, denn komplexe Analysen lassen sich nicht in Millisekunden berechnen. Wir, als mutige Typen, schreiben den Code. Wir machen in der Anwendung Einfügungen, damit wir auf den Master schreiben und die Berichte auf der Replikation ausführen.
• Wir verteilen die Last.
• Alles funktioniert hervorragend. Wir sind gut.

Wie sieht diese Situation aus? Insbesondere in diesen Grafiken habe ich auch die Dauer der Transaktionen von der Replikation hinzugefügt. Alle anderen Grafiken beziehen sich nur auf den Master-Server.

Das Berichtstableau hat sich bis zu diesem Zeitpunkt vergrößert. Es sind mehr Berichte geworden. Wir sehen, dass die durchschnittliche Serverantwortzeit stabil ist. Wir sehen, dass es auf der Replik eine langwierige Transaktion gibt, die seit 2 Stunden läuft. Wir beobachten eine ruhige Arbeit des Autovacuum, das tote Zeilen verarbeitet. Und insgesamt läuft es gut.

Konkret in Bezug auf das getestete Tableau aktualisieren wir weiterhin die Bestände auf den Konten. Auch hier haben wir eine stabile Antwortzeit auf die Anfrage und einen stabilen Ressourcenverbrauch. Alles läuft gut.

Alles ist gut, bis diese Berichte aufgrund von Konflikten mit der Replikation abgeworfen werden. Und sie werden mit konstanter Regelmäßigkeit abgeworfen.

Wir gehen ins Internet und beginnen zu lesen, warum das passiert. Und wir finden eine Lösung.

Die erste Lösung besteht darin, die Replikationsverzögerung zu erhöhen. Wir wissen, dass unser Bericht 3 Stunden läuft. Wir setzen die Replikationsverzögerung auf 3 Stunden. Wir starten alles, aber trotzdem haben wir weiterhin Probleme damit, dass Berichte manchmal abgeworfen werden.

Wir möchten, dass alles perfekt ist. Daher suchen wir weiter. Und wir finden eine großartige Einstellung im Internet - hot_standby_feedback. Wir aktivieren sie. Hot_standby_feedback ermöglicht es uns, die Arbeit des Autovacuum auf dem Master zu halten. Dadurch vermeiden wir vollständig die Replikationskonflikte. Und alles funktioniert gut mit den Berichten.

Was geschieht zu diesem Zeitpunkt mit dem Master-Server? Mit dem Master-Server geschieht ein totales Desaster. Jetzt beobachten wir die Grafiken, seit ich beide Einstellungen aktiviert habe. Und wir sehen, dass die Sitzung auf der Replikelle irgendwie die Situation auf dem Master-Server beeinflusst hat. Sie hat tatsächlich einen Einfluss, da sie das Autovacuum, das tote Zeilen aufräumt, angehalten hat. Die Tabellen Größe ist wieder in die Höhe geschossen. Die durchschnittliche Abfragezeit in der gesamten Datenbank ist ebenfalls in die Höhe geschossen. Die Autovacuum-Prozesse haben sich ein wenig angestrengt.

Konkret für unser Tableau sehen wir, dass die Aktualisierungen der Daten auch eine enorme Steigerung erfahren haben. Der Ressourcenverbrauch der CPU hat sich ebenfalls stark erhöht. Wir durchforsten wieder eine große Anzahl toter, nutzloser Zeilen. Und die Antwortzeit für dieses Tableau, die Anzahl der Transaktionen ist gesunken.

Wie würde das aussehen, wenn wir nicht wüssten, worüber ich bis jetzt gesprochen habe?

• Wir beginnen, Probleme zu suchen. Wenn wir in der ersten Phase auf Probleme gestoßen sind, wissen wir, dass dies an einer langen Transaktion liegen kann und wir uns am Master herumschlagen. Das Problem liegt bei uns am Master. Es schwankt. Er wird heiß, seine Lastdurchschnitt liegt unter hundert.
• Die Anfragen dort sind langsam, aber wir sehen keine langen Transaktionen. Und wir verstehen nicht, worum es geht. Wir wissen nicht, wo wir suchen sollen.
• Wir überprüfen die Serverhardware. Vielleicht ist unser RAID ausgefallen. Vielleicht ist ein RAM-Riegel defekt. Es kann alles Mögliche sein. Aber nein, die Server sind neu, alles funktioniert einwandfrei.
• Alle sind unterwegs: Administratoren, Entwickler und der Direktor. Nichts hilft.
• Und irgendwann beginnt sich alles plötzlich von selbst zu stabilisieren.

An der Replica hat in der Zwischenzeit eine Anfrage bearbeitet und ist verschwunden. Wir haben den Bericht erhalten. Das Geschäft ist immer noch zufrieden. Wie wir sehen, ist die Tabelle wieder gewachsen und zeigt keine Anzeichen, kleiner zu werden. In dem Diagramm mit den Sitzungen habe ich einen Ausschnitt von dieser langen Transaktion von der Replica gelassen, damit Sie einschätzen können, wie lange es dauert, bis die Situation stabilisiert ist.

Die Sitzung ist abgebrochen. Und erst nach einer Weile kommt der Server einigermaßen in Ordnung. Und die durchschnittliche Antwortzeit der Anfragen am Master-Server normalisiert sich. Denn endlich hat der Autovacuum die Möglichkeit bekommen, diese toten Zeilen zu bereinigen und zu markieren. Und er hat begonnen, seine Arbeit zu verrichten. Und so schnell er das tut, desto schneller kommen wir wieder in Ordnung.

An der getesteten Tabelle, in der wir die Kontostände aktualisieren, sehen wir genau dasselbe Bild. Die durchschnittliche Zeit für die Aktualisierung des Kontos normalisiert sich ebenfalls allmählich. Der Ressourcenverbrauch durch die CPU nimmt ebenfalls ab. Und die Anzahl der Transaktionen pro Sekunde kehrt zur Normalität zurück. Aber erneut nicht zu dem Niveau, das wir vor dem Vorfall hatten.

Wir stellen in jedem Fall eine Leistungseinbuße von anderthalb bis zwei Mal fest, manchmal sogar mehr.

Wir haben scheinbar alles richtig gemacht. Die Last verteilt. Die Hardware steht nicht still. Wir haben die Anfragen sinnvoll aufgeteilt, aber dennoch ist alles schlecht gelaufen.

• Hot_standby_feedback nicht aktivieren? Ja, es wird nicht empfohlen, dies ohne besonders starke Gründe zu aktivieren. Denn dieses Feature hat direkten Einfluss auf den Master-Server und unterbricht die Arbeit des Auto-Vakuums dort. Wenn Sie es auf einer bestimmten Replik aktivieren und vergessen, können Sie den Master gefährden und ernsthafte Probleme mit der Anwendung bekommen.
• Max_standby_streaming_delay erhöhen? Ja, das ist korrekt bei Berichten. Wenn Sie einen dreistündigen Bericht haben und nicht wollen, dass er aufgrund von Replikationskonflikten fehlschlägt, erhöhen Sie einfach die Verzögerung. Ein langwieriger Bericht benötigt niemals Daten, die gerade jetzt in der Datenbank angekommen sind. Wenn es sich um einen dreistündigen Bericht handelt, bedeutet das, dass Sie ihn für einen älteren Datenzeitraum starten. Und ob es drei oder sechs Stunden Verzögerung sind, spielt keine Rolle, aber so erhalten Sie Ihre Berichte stabil und haben keine Probleme mit deren Ausfall.
• Natürlich müssen lange Sessions auf den Replikaten überwacht werden, insbesondere wenn Sie beschlossen haben, hot_standby_feedback auf dem Replikat zu aktivieren. Denn es kann passieren, was auch immer. Sie haben dieses Replikat einem Entwickler zur Verfügung gestellt, damit er Abfragen testen kann. Er hat eine verrückte Abfrage geschrieben, sie gestartet und ist zum Tee gegangen, während wir einen überlasteten Master bekommen haben. Oder wir haben dort eine falsche Anwendung laufen lassen. Die Situationen sind vielfältig. Sessions auf den Replikaten müssen ebenso sorgfältig kontrolliert werden wie auf dem Master.
• Wenn Sie also schnelle und langwierige Abfragen auf den Replikaten haben, dann ist es in diesem Fall besser, diese zur Lastverteilung zu splitten. Dies hängt mit dem streaming_delay zusammen. Für schnelle Abfragen haben Sie ein Replikat mit kurzer Replikationsverzögerung. Für langwierige Berichtsabfragen haben Sie ein Replikat, das bis zu 6 Stunden oder einen Tag im Rückstand sein kann. Das ist eine ganz normale Situation.

Die Folgen beseitigen wir auf die gleiche Weise:

• Wir finden aufgeblähte Tabellen.
• Und wir komprimieren sie mit dem für uns passendsten Werkzeug.

Die zweite Geschichte endet hier. Wir kommen zur dritten Geschichte.

Ebenfalls ziemlich gewöhnlich für uns, in der wir eine Migration durchführen.

• Jedes Softwareprodukt wächst. Die Anforderungen daran ändern sich. Wir wollen uns in jedem Fall weiterentwickeln. Und manchmal ist es notwendig, die Daten in der Tabelle zu aktualisieren, das heißt, ein Update im Rahmen unserer Migration für neue Funktionen, die wir im Rahmen unserer Weiterentwicklung einführen.
• Das alte Datenformat ist nicht zufriedenstellend. Angenommen, wir wenden uns jetzt der zweiten Tabelle zu, in der ich die Operationen zu diesen Konten habe. Und nehmen wir an, sie waren in Rubel, und wir haben beschlossen, die Genauigkeit zu erhöhen und sie in Kopeken zu führen. Dafür müssen wir ein Update durchführen: das Feld mit dem Betrag der Operation mit hundert multiplizieren.
• In der modernen Welt nutzen wir automatisierte Mittel zur Versionskontrolle von Datenbanken. Angenommen, Liquibase. Wir schreiben dort unsere Migration. Testen sie auf unserer Testdatenbank. Alles funktioniert hervorragend. Das Update verläuft erfolgreich. Es blockiert die Arbeit für eine gewisse Zeit, aber dafür erhalten wir aktualisierte Daten. Und wir können die neue Funktionalität darauf aufbauen. Alles getestet, überprüft. Alles bestätigt.
• Wir haben planmäßige Arbeiten durchgeführt und die Migration abgeschlossen.

Hier ist die Migration mit dem Update, die Ihnen präsentiert wird. Da es sich um meine Operationen zu den Konten handelt, war die Tabelle 15 GB groß. Und da wir jede Zeile aktualisieren, haben wir die Tabelle durch das Update verdoppelt, weil wir jede Zeile überschrieben haben.

Während der Migration konnten wir mit dieser Tabelle nichts tun, da alle Abfragen an sie in die Warteschlange gestellt wurden und darauf warteten, dass dieses Update abgeschlossen ist. Aber ich möchte Ihre Aufmerksamkeit auf die Zahlen auf der vertikalen Achse lenken. Das heißt, wir haben eine durchschnittliche Abfragezeit vor der Migration von etwa 5 Millisekunden und die CPU-Belastung, die Anzahl der blockierenden Lesevorgänge im Festplattenspeicher, liegt unter 7,5.

Die Migration wurde durchgeführt und wir haben erneut Probleme erhalten.

Die Migration war erfolgreich, aber:

• Die alte Funktionalität benötigt jetzt länger.
• Die Tabelle ist erneut gewachsen.
• Die Last auf dem Server ist erneut höher geworden als zuvor.
• Und natürlich beschäftigen wir uns noch mit der Funktionalität, die gut funktionierte; wir haben sie ein wenig verbessert.

Und das ist erneut Bloat, der uns wieder das Leben schwer macht.

Hier demonstriere ich, dass die Tabelle, wie in den vorherigen beiden Fällen, nicht plant, zu den vorherigen Größen zurückzukehren. Die durchschnittliche Serverlast scheint jedoch angemessen zu sein.

Wenn wir uns die Tabelle mit den Rechnungen ansehen, stellen wir fest, dass die durchschnittliche Abfragezeit zu dieser Tabelle sich verdoppelt hat. Die Auslastung des Prozessors und die Anzahl der im Speicher durchsuchten Zeilen sind auf über 7,5 gestiegen, während sie zuvor darunter lag. Bei den Prozessoren hat sich dieser Wert verdoppelt, bei den blockweisen Operationen um das 1,5-fache, das heißt, wir haben eine Leistungsdegradation des Servers erlebt. Folglich führte dies zu einer Verschlechterung der Leistung unserer Anwendung. Die Anzahl der Aufrufe blieb etwa auf demselben Niveau.

Dabei ist es wichtig zu verstehen, wie man solche Migrationen richtig durchführt. Und es ist notwendig, sie durchzuführen. Wir führen diese Migrationen ziemlich regelmäßig durch.

• Solche großen Migrationen erfolgen nicht automatisch. Sie sollten immer kontrolliert werden.
• Es ist notwendig, dass eine sachkundige Person die Kontrolle hat. Wenn Sie einen DBA im Team haben, sollte dieser die Migration durchführen. Das ist seine Aufgabe. Wenn nicht, sollte die erfahrenste Person im Team dies tun, die weiß, wie man mit Datenbanken arbeitet.
• Das neue Datenbankschema, selbst wenn wir nur eine Spalte aktualisieren, wird immer schrittweise vorbereitet, d. h. vor der Veröffentlichung der neuen Version der Anwendung:
• Neue Felder werden hinzugefügt, in die wir die aktualisierten Daten schreiben werden.
• Wir übertragen die Daten aus dem alten Feld in das neue Feld in kleinen Teilen. Warum tun wir das? Erstens kontrollieren wir immer den Prozess dieser Übertragung. Wir wissen, dass wir bereits so und so viele Batch-Übertragungen durchgeführt haben und noch so viel übrig ist.
• Der zweite positive Effekt besteht darin, dass wir zwischen jedem Batch die Transaktion schließen, eine neue eröffnen und dies dem Auto-Vakuum ermöglicht, an der Tabelle zu arbeiten und die toten Zeilen zur Wiederverwendung zu markieren.
• Für die Zeilen, die während der Arbeit der Anwendung entstehen (unsere alte Anwendung läuft noch), fügen wir einen Trigger hinzu, der neue Werte in die neuen Felder schreibt. In unserem Fall ist das das alte Wertes multipliziert mit hundert.
• Wenn wir ganz stur sind und das gleiche Feld wollen, benennen wir nach Abschluss aller Migrationen und vor der Einführung der neuen Version der Anwendung einfach die Felder um. Die alten in einen beliebigen erfundenen Namen und die neuen Felder in die alten.
• Und erst danach starten wir die neue Version der Anwendung.

Dabei werden wir kein Bloat erhalten und nicht an Leistung verlieren.

Damit endete die dritte Geschichte.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

Und jetzt ein bisschen detaillierter über die Werkzeuge, die ich in der allerersten Geschichte erwähnt habe.

Bevor Sie nach Bloat suchen, sollten Sie unbedingt die Erweiterung installieren. pgstattuple.

Damit Sie keine Anfragen erfinden müssen, haben wir in unserer Arbeit bereits diese Anfragen geschrieben. Sie können sie verwenden. Hier werden zwei Anfragen präsentiert.

• Die erste arbeitet recht lange, aber dafür zeigt sie Ihnen die genauen Werte des Bloats in der Tabelle.
• Die zweite funktioniert schneller und ist sehr effektiv, wenn Sie schnell einschätzen müssen – gibt es Bloat oder nicht in der Tabelle. Und Sie sollten auch verstehen, dass Bloat in einer Postgres-Tabelle immer vorhanden ist. Das ist eine Besonderheit 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 komprimieren.

Wie wir Tabellen identifizieren, die angeschwollen sind, haben wir verstanden, insbesondere wenn sie mit nutzlosen Daten angeschwollen sind.

Jetzt zu dem, wie man Bloat behebt:

• Wenn wir eine kleine Tabelle haben und gute Festplatten, d. h. bei einer Tabelle bis zu einem Gigabyte, kann man VACUUM FULL durchaus verwenden. Es wird für einige Sekunden eine exklusive Sperre auf die Tabelle nehmen und das ist in Ordnung, denn es erledigt alles schnell und gründlich. Was macht VACUUM FULL? Es nimmt eine exklusive Sperre auf die Tabelle und schreibt aktive Zeilen aus alten Tabellen in die neue Tabelle. Am Ende tauscht es sie aus. Alte Dateien werden gelöscht, neue werden an deren Stelle gesetzt. Aber während seiner Arbeit nimmt es eine exklusive Sperre auf die Tabelle. Das bedeutet, dass Sie mit dieser Tabelle nichts machen können: Sie können nicht in sie schreiben, nicht von ihr lesen und sie nicht modifizieren. Außerdem benötigt VACUUM FULL zusätzlichen Speicherplatz auf der Festplatte, um die Daten zu speichern.
• Das nächste Tool pg_repack: Nach seinem Prinzip ist es VACUUM FULL sehr ähnlich, da es ebenfalls Daten von alten Dateien in neue neu schreibt und sie in der Tabelle ersetzt. Dabei nimmt es jedoch zu Beginn seiner Arbeit keine exklusive Sperre auf die Tabelle, sondern nur im Moment, wenn es bereits fertige Daten hat, um die Dateien auszutauschen. Die Anforderungen an die Festplattenspeicher sind ähnlich wie bei VACUUM FULL. Sie benötigen zusätzlichen Speicherplatz auf der Festplatte, und das kann manchmal kritisch sein, wenn Sie Terabyte-Tabellen haben. Und es ist ziemlich rechenintensiv, da es aktiv mit Ein-/Ausgabe arbeitet.
• Das dritte Tool ist pgcompacttable. Sie geht sorgsamer mit den Ressourcen um, weil sie nach etwas anderen Prinzipien arbeitet. Das Hauptziel von pgcompacttable ist es, durch Updates alle lebenden Zeilen an den Anfang der Tabelle zu verschieben. Danach wird der Vacuum-Prozess für diese Tabelle gestartet, da wir wissen, dass am Anfang die lebenden und am Ende die toten Zeilen sind. Und der Vacuum-Prozess schneidet diesen „Schwanz“ ab, das heißt, er benötigt nicht viel zusätzlichen Speicherplatz. Gleichzeitig kann er auch ressourcenschonend sein.

Mit den Werkzeugen ist alles.

Wenn Ihnen das Thema Bloat interessant erscheint, um weiter einzutauchen, hier einige nützliche Links:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres – das ist der Vortrag meines Kollegen. Er gibt einen allgemeinen Überblick darüber, wo der Speicherplatz bei Postgres im Laufe seiner Nutzung bleibt. Und dort findet sich ein großer und detaillierter technischer Abschnitt für Datenbankadministratoren über Bloat.
• https://github.com/dataegret/pg-utils – das ist ein Link zu unserem Repository, in dem wir eine Menge nützlicher Skripte zur Überprüfung des Datenbankzustands speichern. Dort finden Sie Skripte zur Suche nach Bloat.
• Dritte und vierte Links zu Werkzeugen, die Ihnen helfen, Tabellen zu verkleinern.
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html – das ist ein Beitrag meines Kollegen. Dort wird Bloat recht umfangreich und detailliert behandelt, insbesondere auf einer Ebene, die für Administratoren relevant ist.

Hier habe ich versucht, eine Warnung für die Entwickler darzustellen, da sie unsere direkten Kunden im Datenbankbereich sind und verstehen müssen, welche Handlungen welche Folgen haben. Ich hoffe, das ist mir gelungen. Vielen Dank für Ihre Aufmerksamkeit!

Fragen

Danke für den Vortrag! Sie haben darüber gesprochen, wie man Probleme identifizieren kann. Wie können sie präventiv vermieden werden? Ich hatte eine Situation, in der Anfragen nicht nur wegen der Anbindung an externe Dienste hingen. Es waren einfach einige wilde Joins. Es gab harmlose, winzige Anfragen, die einen Tag lang hingen und dann anfingen, seltsame Dinge zu verursachen. Das sieht sehr ähnlich aus wie das, was Sie beschrieben haben. Wie verfolgt man das? Soll man ständig beobachten, 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 die Ansicht pg_stat_activity, in der die hängenden Anfragen angezeigt werden. Dort können Sie sehen, wie lange sie dort hängen.

Muss ich alle 5 Minuten nachschauen?

Stellen Sie den Cron ein und überprüfen Sie. Wenn Sie eine langwierige Anfrage haben, schreiben Sie eine E-Mail und das war's. Das heißt, Sie müssen nicht selbst nachsehen, das kann automatisiert werden. Sie erhalten eine E-Mail, auf die Sie reagieren. Sie können auch automatisch antworten.

Gibt es offensichtliche Gründe, warum das passiert?

Ich habe einige aufgezählt. Andere komplexere Beispiele. Und das Gespräch kann lange dauern.

Danke für den Bericht! Ich wollte zur pg_repack-Utility nachfragen. Wenn sie keine exklusive Sperre vornimmt, dann…

Sie nimmt eine exklusive Sperre vor.

… dann kann ich potenziell Daten verlieren. Mein Programm sollte zu diesem Zeitpunkt nichts aufschreiben?

Nein, es arbeitet ruhig mit der Tabelle, das heißt, pg_repack verschiebt zuerst alle aktiven Zeilen, die vorhanden sind. Natürlich erfolgt dort irgendein Schreibvorgang in die Tabelle. Er fügt einfach diesen kleinen Rest hinzu.

Das heißt, tut er am Ende doch?

Am Ende nimmt er die exklusive Sperre, um diese Dateien auszutauschen.

Wird das schneller sein als VACUUM FULL?

VACUUM FULL, sobald es gestartet wird, nimmt sofort eine exklusive Sperre. Und solange es nicht fertig ist, lässt es sie nicht los. pg_repack hingegen nimmt eine exklusive Sperre nur für den Moment des Date tauschs. In diesem Moment können Sie dort nichts aufzeichnen, aber die Daten gehen nicht verloren, alles wird in Ordnung sein.

Hallo! Sie haben über die Arbeit des Autovacuum gesprochen. Es gab ein Diagramm mit roten, gelben und grünen Aufnahmezellen. Das heißt, die gelben wurden als gelöscht markiert. Und daher können wir neue Daten dort einfügen?

Ja. Postgres löscht keine Zeilen. Es hat diese Spezifik. Wenn wir eine Zeile aktualisieren, markieren wir die alte als gelöscht. Es wird die ID der Transaktion eingefügt, die diese Zeile geändert hat, und wir schreiben die neue Zeile. Und wir haben Sitzungen, die sie potenziell lesen können. Irgendwann werden sie ganz alt. Und die Idee des Autovacuum ist, dass es über diese Zeilen läuft und sie als nicht mehr benötigt markiert. Und an dieser Stelle können wir die Daten überschreiben.

Ich verstehe. Aber die Frage ist ein bisschen anders. Ich habe noch nicht fertig gesprochen. Angenommen, wir haben eine Tabelle. Diese enthält Felder variabler Größe. Und wenn ich versuche, etwas Neues einzufügen, könnte es einfach nicht in die alte Zelle passen.

Nein, dort wird in jedem Fall die gesamte Zeile aktualisiert. In Postgres gibt es zwei Modelle zur Datenspeicherung. Es hängt vom Datentyp ab. Es gibt Daten, die direkt in der Tabelle gespeichert werden, und es gibt auch tos-Daten. Das sind große Datenvolumen: Text, JSON. Sie werden in separaten Tabellen gespeichert. Und in diesen Tabellen passiert die gleiche Geschichte mit Bloat, d.h. alles ist gleich. Nur sind sie separat ausgegliedert.

Danke für den Vortrag! Wie akzeptabel ist es, um die Dauer von Abfragen den Statement Timeout zu verwenden?

Sehr akzeptabel. Wir verwenden das überall. Da wir keine eigenen Services haben und Unterstützung aus der Ferne leisten, gibt es recht unterschiedliche Kunden. Und alle sind damit recht zufrieden. D.h. wir haben cron-Jobs, die überprüfen. Einfach wird mit dem Kunden die Dauer der Sitzungen vereinbart, vor der wir nicht abbrechen. Das kann eine Minute oder auch 10 Minuten sein. Das hängt von der Belastung der Datenbank und ihrem Ziel ab. Aber überall verwenden wir pg_stat_activity.

Danke für den Vortrag! Ich versuche, Ihren Vortrag auf meine Anwendungen anzuwenden. Und anscheinend starten wir überall eine Transaktion und beenden sie überall explizit. Bei einer Ausnahme findet trotzdem ein Rollback statt. Und da bin ich ins Grübeln gekommen. Denn es kann sein, dass eine Transaktion nicht explizit startet. Das ist wahrscheinlich ein Hinweis für die Dame. Wenn ich einfach einen Datensatz aktualisiere, wird die Transaktion in PostgreSQL gestartet und endet erst, wenn die Verbindung getrennt wird?

Wenn Sie jetzt über die Ebene der Anwendung sprechen, hängt das von dem Treiber ab, den Sie verwenden, und von dem ORM, das verwendet wird. Es gibt viele Einstellungen. Wenn bei Ihnen das Auto-Commit aktiviert ist, wird die Transaktion gestartet und sofort geschlossen.

D.h. sie wird sofort nach dem Update geschlossen?

Das hängt von den Einstellungen ab. Eine Einstellung habe ich genannt. Das ist Auto-Commit. Sie ist recht verbreitet. Wenn sie aktiviert ist, wird die Transaktion geöffnet und geschlossen. Wenn Sie nicht ausdrücklich "start transaction" und "end transaction" gesagt haben, sondern einfach die Abfrage in der Sitzung gestartet haben.

Hallo! Danke für den Vortrag! Angenommen, wir haben eine Datenbank, die immer größer wird und auf dem Server der Platz ausgeht. Gibt es irgendwelche Werkzeuge, um diese Situation zu beheben?

Den Platz auf dem Server sollte man idealerweise überwachen.

Zum Beispiel, der DBA geht Tee trinken, war im Urlaub usw.

Wenn ein Dateisystem erstellt wird, wird mindestens ein gewisser Reservierungsplatz geschaffen, in den keine Daten geschrieben werden.

Und wenn es ganz auf null geht?

Es wird als reservierter Raum bezeichnet, das heißt, er kann freigegeben werden, und je nachdem, wie groß er erstellt wurde, haben Sie freien Speicherplatz erhalten. Ich weiß nicht, wie viel es standardmäßig ist. In einem anderen Fall müssen Sie Disks beschaffen, damit Sie genügend Platz für den Wiederherstellungsvorgang haben. Sie können eine Tabelle löschen, die Sie garantiert nicht benötigen.

Gibt es keine anderen Werkzeuge?

Es ist immer Handarbeit. Vor Ort wird festgestellt, was dort am besten zu tun ist, weil es kritische und nicht kritische Daten gibt. Und für jede Datenbank und Anwendung, die damit arbeitet, hängt das vom Geschäft ab. Es wird immer vor Ort entschieden.

Danke für den Vortrag! Ich habe zwei Fragen. Erstens, Sie haben Folien gezeigt, auf denen zu sehen war, dass bei hängenden Transaktionen sowohl das Volumen des Tabellenraums als auch die Größe des Indexes steigen. Im weiteren Verlauf des Vortrags gab es eine Menge Dienstprogramme, die die Tabelle packen. Und was ist mit dem Index?

Diese packen sie ebenfalls.

Aber der Vacuum-Prozess berührt den Index nicht?

Einige arbeiten mit dem Index. Zum Beispiel pg_rapack, pgcompacttable. Der Vacuum-Prozess erstellt Indizes neu und betrifft sie. Das Prinzip von VACUUM FULL besteht darin, alles neu zu schreiben, das heißt, er arbeitet mit allen.

Und die zweite Frage. Ich habe nicht verstanden, warum die Berichte auf den 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 die Prozesse laufen. Es läuft ein Auto-Vacuum. Was macht das Auto-Vacuum? Es entfernt einige alte Zeilen. Wenn in dieser Zeit auf dem Replikat eine Anfrage besteht, die diese alten Zeilen liest, und auf dem Master hat das Auto-Vacuum diese Zeilen als potenziell überschreibbar markiert, dann haben wir sie überschrieben. Und wir haben ein Datenpaket erhalten, wenn wir die Zeilen, die für die Anfrage auf dem Replikat benötigt werden, überschreiben müssen, dann wartet der Replikationsprozess auf die Timeout-Zeit, die Sie eingestellt haben. Und dann entscheidet PostgreSQL, was für ihn wichtiger ist. Die Replikation ist wichtiger für ihn als die Anfrage, und er wird die Anfrage abbrechen, um diese Änderungen auf dem Replikat durchzuführen.

Andrej, ich habe eine Frage. Sind diese wunderbaren Grafiken, die Sie während der Präsentation gezeigt haben, das Ergebnis Ihrer Arbeiten, eines Ihrer Tools? Womit wurden die Grafiken erstellt?

Das ist ein Dienst Okmeter.

Ist das ein kommerzielles Produkt?

Ja. Das ist ein kommerzielles Produkt.

Quelle: habr.com