Ich schlage vor, das Transkript des Berichts von Andrey Salnikov vom Anfang 2016 „Typische Fehler in Anwendungen, die zu Aufblähungen in Postgresql führen“ zu lesen.
In diesem Bericht werde ich die Hauptfehler in Anwendungen analysieren, die in der Phase des Entwerfens und Schreibens von Anwendungscode auftreten. Und ich werde nur die Fehler berücksichtigen, die zu einer Aufblähung in Postgresql führen. In der Regel ist dies der Anfang vom Ende der Leistungsfähigkeit Ihres Gesamtsystems, obwohl zunächst keine Voraussetzungen dafür gesehen wurden.
Ich freue mich, alle begrüßen zu dürfen! Dieser Bericht ist nicht so technisch wie der vorherige von meinem Kollegen. Dieser Vortrag richtet sich hauptsächlich an Back-End-Systementwickler, da wir eine relativ große Anzahl von Kunden haben. Und sie alle machen die gleichen Fehler. Ich werde Ihnen davon erzählen. Ich werde erklären, wozu diese Fehler fatal und schlimm sind.
Warum werden Fehler gemacht? Sie werden aus zwei Gründen durchgeführt: zufällig, vielleicht auch aus Unkenntnis einiger Mechanismen, die auf der Ebene zwischen der Basis und der Anwendung sowie in der Basis selbst ablaufen.
Ich werde Ihnen drei Beispiele mit schrecklichen Bildern geben, wie es schlimm wurde. Ich werde kurz den Mechanismus beschreiben, der dort abläuft. Und wie man damit umgeht, wann sie passiert sind und welche präventiven Methoden man anwenden kann, um Fehlern vorzubeugen. Ich erzähle Ihnen von Hilfstools und gebe nützliche Links.
Ich habe eine Testdatenbank verwendet, in der ich zwei Tabellen hatte. Eine Platte mit Kundenkonten, die andere mit Vorgängen auf diesen Konten. Und in gewissen Abständen aktualisieren wir die Salden auf diesen Konten.
Die ursprünglichen Daten der Platte: Sie ist recht klein, 2 MB. Auch die Reaktionszeit der Datenbank und speziell der Platte ist sehr gut. Und eine ziemlich gute Auslastung – 2 Operationen pro Sekunde auf der Platte.
Und in diesem Bericht werde ich Ihnen Diagramme zeigen, damit klar ist, was passiert. Es gibt immer 2 Folien mit Grafiken. Die erste Folie zeigt, was im Allgemeinen auf dem Server passiert.
Und in dieser Situation sehen wir, dass wir wirklich einen kleinen Teller haben. Der Index ist mit 2 MB klein. Dies ist das erste Diagramm auf der linken Seite.
Die durchschnittliche Antwortzeit auf dem gesamten Server ist ebenfalls stabil und gering. Dies ist die Grafik oben rechts.
Das Diagramm unten links zeigt die längsten Transaktionen. Wir können sehen, dass die Transaktionen schnell abgeschlossen werden. Und das Autovakuum funktioniert hier noch nicht, weil - es war ein Starttest. Dann wird es funktionieren und für uns nützlich sein.
Die zweite Folie ist immer der Testplatte gewidmet. In dieser Situation aktualisieren wir ständig die Kontostände des Kunden. Und wir sehen, dass die durchschnittliche Reaktionszeit für den Aktualisierungsvorgang recht gut ist und weniger als eine Millisekunde beträgt. Wir sehen, dass die Prozessorressourcen (dies ist die Grafik oben rechts) ebenfalls gleichmäßig und recht gering verbraucht werden.
Die Grafik unten rechts zeigt, wie viel Betriebs- und Festplattenspeicher wir auf der Suche nach unserer gewünschten Zeile benötigen, bevor wir sie aktualisieren. Und die Anzahl der Operationen auf der Platte beträgt 2 pro Sekunde, wie ich eingangs sagte.
Und jetzt haben wir eine Tragödie. Aus irgendeinem Grund kommt es zu einer längst vergessenen Transaktion. Die Gründe sind meist allesamt banal:
- Einer der häufigsten Fälle ist, dass wir begonnen haben, im Anwendungscode auf einen externen Dienst zuzugreifen. Und dieser Dienst antwortet uns nicht. Das heißt, wir haben eine Transaktion geöffnet, eine Änderung in der Datenbank vorgenommen und sind von der Anwendung zum Lesen von E-Mails oder zu einem anderen Dienst innerhalb unserer Infrastruktur gewechselt, und aus irgendeinem Grund antwortet sie uns nicht. Und unsere Sitzung hängt in einem Zustand – es ist nicht bekannt, wann das Problem gelöst wird.
- Die zweite Situation liegt vor, wenn in unserem Code aus irgendeinem Grund eine Ausnahme aufgetreten ist. Und wir haben den Abschluss der Transaktion im Ausnahmefall nicht verarbeitet. Und wir bekamen eine hängende Sitzung mit einer offenen Transaktion.
- Und letzteres kommt auch recht häufig vor. Dies ist Code von schlechter Qualität. Einige Frameworks öffnen eine Transaktion. Es hängt, und Sie wissen in der Anwendung möglicherweise nicht, dass es hängt.
Wohin führen solche Dinge?
Dazu, dass unsere Tabellen und Indizes dramatisch anschwellen. Das ist genau der gleiche Blähungseffekt. Für die Datenbank wird sich dies darin äußern, dass die Antwortzeit der Datenbank sehr stark ansteigt und die Belastung des Datenbankservers steigt. Und dadurch wird unsere Anwendung leiden. Denn wenn Sie in Ihrem Code 10 Millisekunden für eine Anfrage an die Datenbank und 10 Millisekunden für Ihre Logik aufgewendet haben, dann hat Ihre Funktion 20 Millisekunden lang funktioniert. Und jetzt wird Ihre Situation sehr traurig sein.
Und mal sehen, was passiert. Die Grafik unten links zeigt, dass es sich um eine Long-Long-Transaktion handelt. Und wenn wir uns die Grafik oben links ansehen, sehen wir, dass die Größe der Tabelle von zwei Megabyte auf 300 Megabyte gestiegen ist. Gleichzeitig hat sich die Datenmenge in der Tabelle nicht geändert, das heißt, es gibt ziemlich viel Müll.
Auch die Gesamtsituation hinsichtlich der durchschnittlichen Serverantwortzeit hat sich um mehrere Größenordnungen verändert. Das heißt, alle Anfragen auf dem Server begannen vollständig einzubrechen. Und gleichzeitig wurden die internen Postgres-Prozesse angesichts des Autovakuums gestartet, die versuchen, etwas zu tun und Ressourcen zu verbrauchen.
Was passiert mit unserem Teller? Das selbe. Die durchschnittliche Reaktionszeit auf dem Tablet stieg um mehrere Größenordnungen. Wenn wir speziell die verbrauchten Ressourcen betrachten, sehen wir, dass die Belastung des Prozessors stark zugenommen hat. Dies ist die Grafik oben rechts. Und es hat zugenommen, weil der Prozessor auf der Suche nach der benötigten Zeile eine Reihe nutzloser Zeilen durchlaufen muss. Dies ist die Grafik unten rechts. Infolgedessen begann die Anzahl der Anrufe pro Sekunde stark zu sinken, da die Datenbank nicht mehr Zeit hatte, die gleiche Anzahl von Anfragen zu verarbeiten.
Wir müssen zurück ins Leben. Wir klettern ins Internet und stellen fest, dass lange Transaktionen zu einem Problem führen. Wir finden und beenden diese Transaktion. Und bei uns läuft alles gut. Alles funktioniert wie es soll.
Wir haben uns beruhigt, aber nach einer Weile bemerken wir, dass die Anwendung nicht mehr so funktioniert wie vor dem Notfall. Anfragen werden trotzdem langsamer, und zwar viel langsamer, bearbeitet. Speziell in meinem Beispiel eineinhalb bis zwei Mal langsamer. Auch die Belastung des Servers ist höher als vor dem Unfall.
Und die Frage: „Was passiert in diesem Moment mit der Basis?“ Und mit Basis gibt es folgende Situation. Auf dem Transaktionsdiagramm können Sie sehen, dass es gestoppt wurde und es wirklich keine langfristigen Transaktionen gibt. Doch die Ausmaße der Platte wuchsen während des Unfalls fatal. Und es ist seitdem nicht weniger geworden. Die durchschnittliche Zeit auf der Basis hat sich stabilisiert. Und die Antworten scheinen für uns angemessen und mit einer akzeptablen Geschwindigkeit zu erfolgen. Autovacuum wurde aktiver und fing an, etwas mit dem Tablet zu machen, weil es mehr Daten schaufeln muss.
Insbesondere auf dem Test-Scoreboard, wo wir die Bilanzen ändern: Die Antwortzeit für die Anfrage scheint sich wieder normalisiert zu haben. Tatsächlich ist es jedoch eineinhalb Mal höher.
Und an der Belastung des Prozessors erkennen wir, dass die Belastung des Prozessors vor dem Absturz nicht wieder den gewünschten Wert erreicht hat. Und die Gründe dafür liegen direkt in der unteren rechten Grafik. Es ist ersichtlich, dass eine gewisse Speichermenge durchsucht wird. Das heißt, um nach der gewünschten Zeile zu suchen, verbrauchen wir die Ressourcen des Datenbankservers beim Sortieren nutzloser Daten. Die Anzahl der Transaktionen pro Sekunde hat sich stabilisiert.
Im Allgemeinen gut, aber die Situation ist schlimmer als sie war. Explizite Verschlechterung der Datenbank als Folge unserer Anwendung, die mit dieser Datenbank arbeitet.
Und um zu verstehen, was dort passiert, wenn Sie den vorherigen Bericht nicht gesehen haben, dann jetzt ein wenig Theorie. Theorie über den internen Prozess. Warum Autovakuum und was bewirkt es?
Im wahrsten Sinne des Wortes kurz und bündig zum Verständnis. Irgendwann haben wir einen Tisch. Wir haben Zeilen in der Tabelle. Diese Leitungen können aktiv und lebendig sein, wir brauchen sie jetzt. Sie sind im Bild grün markiert. Und es gibt Fristen, die bereits ausgearbeitet wurden, aktualisiert wurden und auf denen neue Einträge erschienen sind. Und sie werden markiert, dass sie für die Datenbank nicht mehr interessant sind. Aufgrund der Besonderheiten von Postgres liegen sie jedoch in der Tabelle.
Warum brauchen Sie ein Autovakuum? Irgendwann kommt Autovacuum, ruft die Datenbank auf und fragt sie: „Bitte geben Sie mir die Id der ältesten Transaktion, die derzeit in der Datenbank geöffnet ist.“ Die Datenbank gibt diese ID zurück. Und das darauf basierende Autovakuum durchläuft die Zeilen in der Tabelle. Und wenn er sieht, dass einige Zeilen durch viel ältere Transaktionen geändert wurden, dann hat er das Recht, sie als Zeilen zu markieren, die wir in Zukunft wiederverwenden können, indem wir dort neue Daten schreiben. Dies ist ein Hintergrundprozess.
Zu diesem Zeitpunkt arbeiten wir weiterhin mit der Datenbank und nehmen weiterhin einige Änderungen an der Tabelle vor. Und auf diese Zeilen, die wir wiederverwenden können, schreiben wir neue Daten. Und auf diese Weise erhalten wir einen Kreislauf, das heißt, es tauchen ständig einige tote alte Zeilen auf, stattdessen schreiben wir neue Zeilen auf, die wir brauchen. Und das ist der normale Zustand, in dem PostgreSQL funktioniert.
Was ist bei dem Unfall passiert? Wie kam es zu diesem Prozess?
Wir hatten einen Teller in irgendeinem Zustand, einige lebende, einige tote Linien. Das Autovakuum ist angekommen. Er fragte die Datenbank nach unserer ältesten Transaktion und ihrer ID. Ich habe diese ID erhalten, die viele Stunden, vielleicht zehn Minuten alt sein kann. Es hängt davon ab, wie hoch die Belastung Ihrer Datenbank ist. Und er machte sich auf die Suche nach Zeilen, die er als wiederverwendet markieren konnte. Und ich habe solche Zeilen in unserer Tabelle nicht gefunden.
Aber zu diesem Zeitpunkt arbeiten wir weiter mit der Tabelle. Wir machen etwas darin, aktualisieren es, ändern die Daten. Was soll die Datenbank zu diesem Zeitpunkt tun? Ihr bleibt nichts anderes übrig, als am Ende der bestehenden Tabelle neue Zeilen hinzuzufügen. Und so beginnt sich bei uns die Größe des Tisches aufzublähen.
Wir brauchen wirklich grüne Linien, um zu funktionieren. Bei einem solchen Problem stellt sich jedoch heraus, dass der Anteil der grünen Linien am Gesamtvolumen der Tabelle äußerst gering ist.
Und wenn wir eine Abfrage ausführen, muss die Datenbank alle roten und grünen Zeilen durchgehen, um die richtige Zeile zu finden. Und der Effekt des Aufblähens der Tabelle mit nutzlosen Daten wird als „Aufblähen“ bezeichnet, was auch unseren Speicherplatz verschlingt. Denken Sie daran, es waren 2 MB, jetzt sind es 300 MB? Ändern Sie jetzt Megabyte in Gigabyte, und Sie verlieren ziemlich schnell alle Ihre Festplattenressourcen.
Was sind die Auswirkungen für uns?
- In meinem Beispiel sind Tabelle und Index um das 150-fache gewachsen. Bei einigen unserer Kunden gab es schwerwiegendere Fälle, in denen einfach der Speicherplatz knapp wurde.
- Tische werden nie von alleine schrumpfen. Autovakuum kann in manchen Fällen das Ende der Tabelle abschneiden, wenn nur tote Leitungen vorhanden sind. Da jedoch eine ständige Rotation stattfindet, hängt möglicherweise eine grüne Linie am Ende und wird nicht aktualisiert, während der Rest irgendwo am Anfang der Platte aufgezeichnet wird. Dies ist jedoch ein so unwahrscheinliches Ereignis, dass Ihr Tisch selbst kleiner wird. Sie sollten also nicht darauf hoffen.
- Die Datenbank muss den ganzen Stapel nutzloser Zeilen sortieren. Und wir verschwenden Festplattenressourcen, Prozessorressourcen und Strom.
- Und das wirkt sich direkt auf unsere Anwendung aus, denn wenn wir zu Beginn 10 Millisekunden für eine Anfrage und 10 Millisekunden für unseren Code aufgewendet haben, haben wir während des Absturzes begonnen, eine Sekunde für eine Anfrage und 10 Millisekunden für Code aufzuwenden, also eine Größenordnung von Ausmaß der Anwendungsleistung verringert. Und als der Unfall behoben war, begannen wir, 20 Millisekunden pro Anfrage und 10 Millisekunden pro Code aufzuwenden. Damit sind wir leistungstechnisch immer noch um das Eineinhalbfache gesunken. Und das alles wegen einer einzigen Transaktion, die hängengeblieben ist, und vielleicht auch durch unsere Schuld.
- Und die Frage: „Wie bekomme ich alles zurück?“ Damit bei uns alles in Ordnung ist und Anfragen genauso schnell ablaufen wie vor dem Unfall.
Dafür gibt es einen bestimmten Arbeitszyklus, der durchgeführt wird.
Zuerst müssen wir die problematischen Tabellen finden, die aufgebläht sind. Wir verstehen, dass einige Tabellen aktiver aufzeichnen, andere weniger aktiv. Und dafür verwenden wir die Erweiterung . Durch die Installation dieser Erweiterung können Sie Abfragen schreiben, um Tabellen zu finden, die ausreichend aufgebläht sind.
Sobald Sie diese Tabellen gefunden haben, müssen sie komprimiert werden. Dafür gibt es bereits Tools. In unserem Unternehmen nutzen wir drei Tools. Der erste ist der eingebaute VACUUM FULL. Er ist grausam, hart und gnadenlos, aber manchmal ist er sehr nützlich. и sind Dienstprogramme von Drittanbietern zum Komprimieren von Tabellen. Und sie gehen vorsichtiger mit der Datenbank um.
Sie werden je nachdem verwendet, was für Sie bequemer ist. Aber darüber werde ich ganz zum Schluss sprechen. Die Hauptsache ist, dass es drei Werkzeuge gibt. Es gibt eine große Auswahl.
Nachdem wir alles korrigiert und sichergestellt haben, dass alles in Ordnung ist, sollten wir wissen, wie wir diese Situation in Zukunft verhindern können:
- Es ist ziemlich einfach zu verhindern. Sie müssen die Dauer der Sitzungen auf dem Master-Server überwachen. Besonders gefährlich sind Sitzungen im Leerlauf im Transaktionszustand. Dies sind diejenigen, die gerade eine Transaktion eröffnet, etwas getan und gegangen sind oder einfach hängengeblieben sind und sich im Code verloren haben.
- Und für Sie als Entwickler ist es wichtig, den Code zu testen, wenn diese Situationen auftreten. Das ist nicht schwer. Dies wird eine nützliche Überprüfung sein. Sie vermeiden viele „kindische“ Probleme, die mit langen Transaktionen verbunden sind.
Anhand dieser Diagramme wollte ich Ihnen zeigen, wie sich die Tabelle und das Verhalten der Datenbank änderten, nachdem ich in diesem Fall VACUUM FULL für die Tabelle übergeben habe. Das ist nicht meine Produktion.
Die Größe der Tabelle kehrte sofort zu ihrem normalen Arbeitszustand von einigen Megabyte zurück. Dies hatte keinen großen Einfluss auf die durchschnittliche Antwortzeit auf dem gesamten Server.
Aber speziell in unserer Testtabelle, in der wir die Kontostände aktualisiert haben, sehen wir, dass die durchschnittliche Reaktionszeit auf eine Anfrage zur Aktualisierung der Daten im Tablet auf das Niveau vor dem Unfall reduziert wurde. Auch die vom Prozessor zur Ausführung dieser Anfrage verbrauchten Ressourcen sanken auf das Niveau vor dem Absturz. Und die Grafik unten rechts zeigt, dass wir jetzt genau die Zeile finden, die wir sofort benötigen, ohne den Stapel toter Zeilen durchzugehen, der vor der Komprimierung der Tabelle vorhanden war. Und die durchschnittliche Abfragezeit blieb ungefähr auf dem gleichen Niveau. Aber hier liegt es eher am Fehler meiner Hardware.
Hier endet die erste Geschichte. Sie ist die häufigste. Und es passiert jedem, unabhängig von der Erfahrung des Kunden, wie qualifizierte Programmierer es gibt. Früher oder später passiert es.
Die zweite Geschichte, in der wir die Last verteilen und die Serverressourcen optimieren
- Wir sind erwachsen geworden und ernsthafte Typen geworden. Und wir verstehen, dass wir eine Replik haben und es gut für uns wäre, die Last auszugleichen: auf den Master schreiben und von der Replik lesen. Und normalerweise entsteht diese Situation, wenn wir Berichte oder ETL erstellen möchten. Und die Wirtschaft freut sich sehr darüber. Er möchte unbedingt eine Vielzahl von Berichten mit einer Reihe komplexer Analysen.
- Berichte dauern viele Stunden, da komplexe Analysen nicht in Millisekunden berechnet werden können. Wir schreiben wie mutige Jungs Code. Wir führen in der Einfügungsanwendung, die wir auf dem Master aufzeichnen, Berichte über das Replikat durch.
- Wir verteilen die Last.
- Alles funktioniert perfekt. Wir sind großartig.
Und wie sieht diese Situation aus? Insbesondere habe ich in diesen Diagrammen auch die Dauer der Transaktionen aus dem Replikat für die Dauer der Transaktion hinzugefügt. Alle anderen Diagramme beziehen sich nur auf den Master-Server.
Zu diesem Zeitpunkt war mein Berichtsbrett gewachsen. Es gibt noch mehr davon. Wir können sehen, dass die durchschnittliche Serverantwortzeit stabil ist. Wir können sehen, dass wir auf dem Replikat eine lang laufende Transaktion haben, die 2 Stunden lang läuft. Wir sehen die leise Arbeit des Autovakuums, das tote Leitungen verarbeitet. Und uns geht es allen gut.
Konkret aktualisieren wir laut Test-Tablet weiterhin die Salden auf den dortigen Konten. Und wir haben auch eine stabile Reaktionszeit auf Anfrage und einen stabilen Ressourcenverbrauch. Bei uns ist alles in Ordnung.
Alles ist in Ordnung, bis zu dem Moment, in dem diese Berichte auf einen Konflikt mit der Replikation zurückkommen. Und sie schießen in regelmäßigen Abständen zurück.
Wir gehen online und beginnen zu lesen, warum das passiert. Und wir finden eine Lösung.
Die erste Lösung besteht darin, die Replikationslatenz zu erhöhen. Wir wissen, dass unser Bericht 3 Stunden dauert. Legen Sie die Replikationsverzögerung auf 3 Stunden fest. Wir fangen alles an, aber wir haben immer noch Probleme damit, dass Meldungen manchmal zurückgeschossen werden.
Wir wollen, dass alles perfekt ist. Gehen wir weiter. Und im Internet finden wir eine coole Einstellung – hot_standby_feedback. Wir schalten es ein. Hot_standby_feedback ermöglicht es uns, das Autovakuum auf dem Master laufen zu lassen. Dadurch werden Replikationskonflikte vollständig beseitigt. Und wir alle arbeiten gut mit Berichten.
Und was passiert derzeit mit dem Master-Server? Und mit dem Master-Server haben wir eine totale Katastrophe. Wir sehen jetzt Diagramme, in denen beide Einstellungen aktiviert sind. Und wir sehen, dass die Sitzung auf dem Replikat irgendwie begann, die Situation auf dem Master-Server zu beeinflussen. Es hat tatsächlich eine Wirkung, weil es das Autovakuum, das die toten Leitungen reinigt, außer Kraft gesetzt hat. Unsere Tischgröße ist erneut in die Höhe geschossen. Auch die durchschnittliche Abfrageausführungszeit in der gesamten Datenbank stieg sprunghaft an. Die Autovakuums wurden etwas stärker.
Konkret sehen wir auf unserem Teller, dass auch das darauf befindliche Datenupdate in die Höhe gesprungen ist. Der Verbrauch an Prozessorressourcen ist ebenfalls stark gestiegen. Wir durchlaufen erneut eine große Anzahl toter, nutzloser Zeilen. Und die Reaktionszeit auf diesem Tablet, die Anzahl der Transaktionen ist gesunken.
Wie wird es aussehen, wenn wir nicht wissen, wovon ich vorher gesprochen habe?
- Wir fangen an, nach Problemen zu suchen. Wenn wir im ersten Teil auf Probleme gestoßen sind, wissen wir, dass dies der Grund für eine lange Transaktion sein kann und steigen auf den Master um. Das Problem liegt beim Meister. Würstet ihn. Er wärmt sich auf, er hat einen Lastdurchschnitt von unter hundert.
- Dort verlangsamen sich die Anfragen, aber wir sehen dort keine langfristigen Transaktionen. Und wir verstehen nicht, was los ist. Wir wissen nicht, wo wir suchen sollen.
- Überprüfung der Serverhardware. Vielleicht ist unser Überfall gescheitert. Vielleicht ist die Speicherleiste durchgebrannt. Ja, alles kann sein. Aber nein, die Server sind neu, alles funktioniert gut.
- Alle laufen: Administratoren, Entwickler und der Direktor. Nichts hilft.
- Und irgendwann fängt plötzlich alles an, sich zu korrigieren.
Auf dem Replikat funktionierte die Anfrage zu diesem Zeitpunkt und ging. Wir haben eine Meldung erhalten. Das Geschäft ist immer noch glücklich. Wie Sie sehen, ist unser Tisch wieder gewachsen und wird nicht kleiner. Auf dem Diagramm mit den Sitzungen habe ich einen Teil dieser langen Transaktion aus der Replik gelassen, damit Sie abschätzen können, wie lange es dauert, bis sich die Situation stabilisiert.
Die Sitzung ist vorbei. Und erst nach einiger Zeit kommt der Server einigermaßen in Ordnung. Und die durchschnittliche Antwortzeit für Anfragen auf dem Master-Server normalisiert sich wieder. Weil das Autovakuum endlich die Möglichkeit hatte, sich zu reinigen, markieren Sie diese Deadlines. Und er begann, seinen Job zu machen. Und wie schnell er es macht, so schnell werden wir in Ordnung sein.
Auf der Testtabelle, in der wir die Kontostände aktualisieren, sehen wir genau das gleiche Bild. Auch die durchschnittliche Kontoaktualisierungszeit normalisiert sich allmählich. Auch der Ressourcenverbrauch des Prozessors wird reduziert. Und die Anzahl der Transaktionen pro Sekunde hat sich wieder normalisiert. Aber wieder normal, nicht mehr so wie vor dem Unfall.
In jedem Fall kommt es zu einem Leistungsabfall, wie im ersten Fall, eineinhalb bis zwei Mal, manchmal sogar noch mehr.
Wir scheinen alles richtig gemacht zu haben. Verteilen Sie die Last. Das Gerät steht nicht still. Der Meinung nach haben sie die Forderungen gebrochen, aber trotzdem ist alles schief gelaufen.
- Hot_standby_feedback nicht aktivieren? Ja, es wird nicht empfohlen, es ohne besonders triftige Gründe einzuschalten. Denn diese Wendung wirkt sich direkt auf den Master-Server aus und unterbricht dort die Arbeit des Autovakuums. Indem Sie es auf einer Replik einschalten und es dann vergessen, können Sie den Master töten und große Probleme mit der Anwendung bekommen.
- max_standby_streaming_delay erhöhen? Ja, das gilt für Berichte. Wenn Sie über einen dreistündigen Bericht verfügen und nicht möchten, dass dieser aufgrund von Replikationskonflikten abstürzt, erhöhen Sie einfach die Verzögerung. Für einen längeren Bericht sind niemals Daten erforderlich, die gerade in die Datenbank eingegeben wurden. Wenn Sie es drei Stunden lang haben, dann betreiben Sie es für einen Zeitraum mit alten Daten. Und Sie, diese drei Stunden Verspätung, diese sechs Stunden Verspätung – werden keine Rolle spielen, aber Sie werden regelmäßig Berichte erhalten und die Probleme mit ihrem Rückgang nicht kennen.
- Natürlich müssen Sie lange Sitzungen auf Replikaten kontrollieren, insbesondere wenn Sie hot_standby_feedback auf einem Replikat aktivieren möchten. Denn es könnte alles sein. Diesen Hinweis haben wir dem Entwickler mitgeteilt, damit er die Anfragen testen kann. Er hat eine verrückte Anfrage geschrieben. Er fing an und ging Tee trinken, und wir bekamen den etablierten Meister. Oder wir haben dort die falsche Anwendung gestartet. Die Situationen sind vielfältig. Sitzungen auf Replikaten müssen genauso sorgfältig kontrolliert werden wie auf dem Master.
- Und wenn Sie schnelle und lange Abfragen auf Replikate haben, ist es in diesem Fall besser, diese aufzuteilen, um die Last zu verteilen. Dies ist ein Link zu „streaming_delay“. Für schnelles Erstellen einer Replik mit geringer Replikationsverzögerung. Für Berichtsanfragen mit langer Laufzeit sollten Sie über ein Replikat verfügen, das bis zu 6 Stunden pro Tag zurückbleiben kann. Dies ist eine völlig normale Situation.
Wir beseitigen die Folgen auf die gleiche Weise:
- Wir finden aufgeblähte Tische.
- Und wir komprimieren mit dem bequemsten Werkzeug, das zu uns passt.
Die zweite Geschichte endet hier. Kommen wir zur dritten Geschichte.
Auch bei uns durchaus üblich, in dem wir die Migration durchführen.
- Jedes Softwareprodukt wächst. Anforderungen ändern sich. Auf jeden Fall wollen wir uns weiterentwickeln. Und es kommt vor, dass wir die Daten in der Tabelle aktualisieren müssen, nämlich um das Update im Hinblick auf unsere Migration auf die neue Funktionalität durchzuführen, die wir im Rahmen unserer Entwicklung implementieren.
- Das alte Datenformat passt nicht. Nehmen wir an, wir wenden uns nun der zweiten Tabelle zu, in der ich Operationen auf diesen Konten habe. Nehmen wir an, sie waren in Rubel angegeben, und wir haben beschlossen, die Genauigkeit zu erhöhen und dies in Kopeken zu tun. Und dafür müssen wir eine Aktualisierung vornehmen: Multiplizieren Sie das Feld mit dem Betrag der Operation mit einhundert.
- In der heutigen Welt verwenden wir automatisierte Tools zur Datenbankversionierung. Sagen wir . Dort registrieren wir unsere Migration. Wir testen es auf unserer Testbasis. Alles in Ordnung ist. Das Update läuft. Die Blöcke funktionieren eine Weile, aber wir erhalten aktualisierte Daten. Und wir können hier neue Funktionen einführen. Alles getestet und geprüft. Alles bestätigt.
- Geplante Arbeiten durchgeführt, Migration durchgeführt.
Hier ist die Migration mit dem vor Ihnen präsentierten Update. Da ich Operationen auf Konten habe, betrug die Platte 15 GB. Und da wir jede Zeile aktualisieren, haben wir die Größe der Tabelle verdoppelt, weil wir jede Zeile überschrieben haben.
Während der Migration konnten wir mit diesem Label nichts anfangen, da alle Anfragen dafür in der Warteschlange standen und auf den Abschluss dieses Updates warteten. Aber hier möchte ich Ihre Aufmerksamkeit auf die Zahlen lenken, die auf der vertikalen Achse stehen. Das heißt, wir haben eine durchschnittliche Anforderungszeit vor der Migration im Bereich von 5 Millisekunden und eine Belastung des Prozessors, die Anzahl der Blockoperationen zum Lesen des Festplattenspeichers beträgt weniger als 7,5.
Wir sind umgezogen und hatten wieder Probleme.
Die Migration war erfolgreich, aber:
- Die alte Funktionalität begann länger zu laufen.
- Der Tisch ist noch einmal größer geworden.
- Die Belastung des Servers ist erneut größer geworden als zuvor.
- Und natürlich tüfteln wir immer noch an der Funktionalität, die gut funktioniert hat, wir haben sie ein wenig verbessert.
Und das ist wieder eine Aufblähung, die uns wieder das Leben verdirbt.
Hier zeige ich, dass die Tabelle, wie in den beiden vorherigen Fällen, nicht zu den vorherigen Größen zurückkehren wird. Die durchschnittliche Auslastung des Servers scheint ausreichend zu sein.
Und wenn wir uns der Tabelle mit Konten zuwenden, werden wir feststellen, dass sich die durchschnittliche Anforderungszeit für diese Tabelle verdoppelt hat. Die Belastung des Prozessors und die Anzahl der auszusortierenden Zeilen im Speicher stiegen sprunghaft auf über 7,5, waren aber geringer. Und stieg bei Prozessoren um das Zweifache, bei Blockoperationen um das 2-fache, d. h. wir bekamen eine Verschlechterung der Serverleistung. Und als Folge davon kommt es zu einer Verschlechterung der Leistung unserer Anwendung. Gleichzeitig blieb die Anzahl der Anrufe in etwa auf dem gleichen Niveau.
Und hier geht es vor allem darum, zu verstehen, wie man solche Migrationen richtig durchführt. Und sie müssen getan 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.
- Benötigt die Aufsicht einer sachkundigen Person. Wenn Sie einen DBA im Team haben, überlassen Sie es dem DBA. Es ist sein Job. Wenn nicht, dann überlassen Sie es der erfahrensten Person, die sich mit Datenbanken auskennt.
- Das neue Datenbankschema bereiten wir, auch wenn wir eine Spalte aktualisieren, immer schrittweise vor, d. h. im Voraus, bevor die neue Version der Anwendung eingeführt wird:
- Es werden neue Felder hinzugefügt, in die wir nur die aktualisierten Daten schreiben.
- Wir übertragen Daten in kleinen Teilen vom alten Feld auf das neue Feld. Warum machen wir das? Erstens kontrollieren wir immer den Ablauf dieses Prozesses. Wir wissen, dass wir bereits so viele Chargen übertragen haben und noch so viele übrig haben.
- Und der zweite positive Effekt besteht darin, dass wir zwischen jeder dieser Chargen eine Transaktion abschließen und eine neue eröffnen. Dies ermöglicht es dem Autovakuum, entsprechend der Platte zu arbeiten und Fristen für die Wiederverwendung zu markieren.
- Für die Zeilen, die während des Betriebs der Anwendung erscheinen (wir haben noch die alte Anwendung), fügen wir einen Trigger hinzu, der neue Werte in neue Felder schreibt. In unserem Fall handelt es sich um eine Multiplikation des alten Wertes mit dem Hundert.
- Wenn wir völlig stur sind und das gleiche Feld wollen, benennen wir die Felder nach Abschluss aller Migrationen und vor dem Rollieren der neuen Version der Anwendung einfach um. Die alten in einen erfundenen Namen umwandeln und die neuen Felder in die alten umbenennen.
- Und erst danach starten wir eine neue Version der Anwendung.
Und gleichzeitig werden wir uns nicht aufblähen und in der Leistung nicht nachlassen.
Dies ist das Ende der dritten Geschichte.
Und nun noch etwas mehr zu den Tools, die ich in der allerersten Geschichte erwähnt habe.
Bevor Sie nach Bloat suchen, müssen Sie die Erweiterung installieren .
Damit Sie keine Anfragen erfinden, haben wir diese Anfragen bereits in unserer Arbeit geschrieben. Sie können sie verwenden. Hier gibt es zwei Anliegen.
- Der erste dauert ziemlich lange, zeigt Ihnen aber laut Tabelle die genauen Blähungswerte an.
- Die zweite Methode arbeitet schneller und ist sehr effektiv, wenn Sie schnell beurteilen müssen, ob die Tabelle aufgebläht ist oder nicht. Und Sie sollten auch verstehen, dass es in einer Postgres-Tabelle immer zu Aufblähungen kommt. Dies ist ein Merkmal seines MVCC-Modells.
- Und 20 % Aufblähung sind für Tabellen in den meisten Fällen in Ordnung. Das heißt, Sie sollten sich keine Sorgen machen und diese Tabelle komprimieren.
Wir haben herausgefunden, wie wir Tabellen erkennen können, die mit uns überfüllt sind, und darüber hinaus, wenn sie mit nutzlosen Daten überfüllt sind.
Nun zur Lösung von Blähungen:
- Wenn wir eine kleine Platte und gute Platten haben, also auf einer Platte bis zu einem Gigabyte, ist es durchaus möglich, VACUUM FULL zu verwenden. Er wird dir für ein paar Sekunden eine exklusive Sperre nehmen, und okay, aber er wird alles schnell und hart machen. Was bewirkt VAKUUM VOLL? Es nimmt eine exklusive Sperre für die Tabelle vor und schreibt die Live-Zeilen aus den alten Tabellen in die neue Tabelle um. Und am Ende ersetzt er sie. Löscht alte Dateien und ersetzt alte durch neue. Für die Dauer seiner Arbeit benötigt es jedoch eine exklusive Sperre auf dem Tisch. Das bedeutet, dass Sie mit dieser Tabelle nichts anfangen können: weder in sie schreiben, noch hineinlesen, noch sie verändern. Und VACUUM FULL erfordert zusätzlichen Speicherplatz zum Schreiben von Daten.
- Nächstes Werkzeug . Vom Prinzip her ist es VACUUM FULL sehr ähnlich, da es ebenfalls Daten aus alten Dateien in neue überschreibt und diese in der Tabelle ersetzt. Gleichzeitig nimmt es aber nicht gleich zu Beginn seiner Arbeit eine exklusive Sperre für die Tabelle, sondern erst in dem Moment, in dem es über vorgefertigte Daten verfügt, um die Dateien zu ersetzen. Es gelten die gleichen Anforderungen an die Festplattenressourcen wie bei VACUUM FULL. Sie benötigen zusätzlichen Speicherplatz, und das ist manchmal entscheidend, wenn Sie Terabyte-Tabellen haben. Und was den Prozessor angeht, ist er ziemlich gefräßig, da er aktiv mit I/O arbeitet.
- Das dritte Dienstprogramm ist . Es geht schonender mit den Ressourcen um, da es nach etwas anderen Prinzipien funktioniert. Der Kern von pgcompacttable besteht darin, dass alle aktiven Zeilen bei Aktualisierungen in der Tabelle an den Anfang der Tabelle verschoben werden. Und dann entsteht in dieser Tabelle ein Vakuum, weil wir wissen, dass wir am Anfang aktive Zeilen und am Ende tote Zeilen haben. Und das Vakuum selbst schneidet diesen Schwanz ab, das heißt, es benötigt nicht viel zusätzlichen Speicherplatz. Und gleichzeitig kann es immer noch zu Engpässen bei den Ressourcen kommen.
Alles mit Werkzeug.
Wenn Sie das aufgeblähte Thema im Hinblick auf eine tiefere Vertiefung interessant finden, dann sind hier einige nützliche Links für Sie:
- ist der Bericht meines Kollegen. Es geht allgemein darum, welchen Platz Postgres im Laufe seiner Arbeit und seines Lebens einnimmt. Und es gibt einen sehr umfangreichen und detaillierten technischen Artikel für Datenbankadministratoren zum Thema Blähungen.
- ist ein Link zu unserem Repository, in dem wir eine Reihe nützlicher Skripte zur Überprüfung des Datenbankstatus speichern. Dort finden Sie aufgeblähte Suchskripte.
- и Links zu Werkzeugen, die Ihnen beim Komprimieren der Platten helfen.
- Dies ist ein Beitrag meines Kollegen. Dort analysiert er Blähungen sehr ernsthaft und technisch im Detail, bereits auf einer Ebene, die den Administratoren nahe steht.
Hier habe ich versucht, den Entwicklern eine Horrorgeschichte zu zeigen, denn sie sind unsere direkten Datenbankkunden und müssen verstehen, wozu und zu welchen Aktionen sie führen. Ich hoffe, es ist mir gelungen. Vielen Dank für Ihre Aufmerksamkeit!
Fragen
Danke für den Bericht! Sie haben darüber gesprochen, wie Probleme identifiziert werden können. Wie können sie gewarnt werden? Das heißt, ich hatte eine Situation, in der Anfragen nicht nur deshalb hängen blieben, weil sie sich an einige externe Dienste wandten. Es waren nur ein paar wilde Verbindungen. Es gab ein paar kleine, harmlose Anfragen, die einen Tag lang herumhingen und dann anfingen, irgendeinen Unsinn zu machen. Das heißt, es ist dem, was Sie beschreiben, sehr ähnlich. Wie kann man es verfolgen? Setzen Sie sich hin und schauen Sie ständig zu, welche Anfrage steckt fest? Wie kann dies verhindert werden?
In diesem Fall ist dies eine Aufgabe für die Administratoren Ihres Unternehmens, nicht unbedingt für den DBA.
Ich bin Administrator.
PostgreSQL verfügt über eine Ansicht namens pg_stat_activity, die ausstehende Abfragen anzeigt. Und man sieht, wie lange es dort hängt.
Ich muss alle 5 Minuten vorbeikommen und schauen?
Cron einrichten und prüfen. Wenn Sie eine längere Anfrage haben, schreiben Sie einen Brief und das war’s. Das heißt, Sie müssen nicht mit den Augen schauen, dies kann automatisiert werden. Sie erhalten einen Brief, Sie antworten darauf. Oder Sie können automatisch schießen.
Gibt es klare Gründe, warum dies geschieht?
Ich habe einige aufgelistet. Andere komplexere Beispiele. Und es kann ein langes Gespräch geben.
Danke für den Bericht! Ich wollte das Dienstprogramm pg_repack klären. Wenn keine exklusive Sperre erforderlich ist, dann ...
Sie macht ein exklusives Schloss.
... dann könnte ich möglicherweise Daten verlieren. Sollte meine App zu diesem Zeitpunkt nichts aufzeichnen?
Nein, es funktioniert im Stillen mit der Tabelle, d.h. pg_repack überträgt zunächst alle dort vorhandenen Live-Zeilen. Natürlich gibt es in der Tabelle eine Art Rekord. Er wirft einfach diesen Pferdeschwanz.
Das heißt, macht er es am Ende immer noch?
Am Ende wird eine exklusive Sperre für den Austausch dieser Dateien benötigt.
Wird es schneller sein als VAKUUM VOLL?
VACUUM FULL nahm beim Start sofort eine exklusive Sperre an. Und bis er alles tut, wird er sie nicht gehen lassen. Und pg_repack nimmt nur zum Zeitpunkt des Ersetzens von Dateien eine exklusive Sperre an. Zu diesem Zeitpunkt schreiben Sie nicht dorthin, aber die Daten gehen nicht verloren, alles wird in Ordnung sein.
Guten Tag! Sie haben über die Funktion des Autovakuums gesprochen. Es gab ein Diagramm mit roten, gelben und grünen Zellen des Datensatzes. Das heißt, gelbe – er hat sie als gelöscht markiert. Und dadurch kann man darin etwas Neues schreiben?
Ja. Postgres entfernt keine Zeilen. Er hat eine solche Besonderheit. Wenn wir die Zeile aktualisiert haben, haben wir die alte als gelöscht markiert. Dort erscheint die Transaktions-ID, die diese Zeile geändert hat, und wir schreiben eine neue Zeile. Und wir haben Sitzungen, die sie potenziell lesen können. Irgendwann werden sie ziemlich alt. Und die Essenz des Autovakuums besteht darin, dass es durch diese Leitungen läuft und sie als unnötig markiert. Und dort können Sie die Daten überschreiben.
Ich habe verstanden. Aber darum geht es bei der Frage nicht. Ich war nicht einverstanden. Nehmen wir an, wir haben einen Tisch. Es verfügt über Felder variabler Größe. Und wenn ich versuche, etwas Neues einzufügen, passt es möglicherweise einfach nicht in die alte Zelle.
Nein, da wird auf jeden Fall die gesamte Zeile aktualisiert. Postgres verfügt über zwei Speichermodelle. Es wählt aus dem Datentyp aus. Es gibt Daten, die direkt in der Tabelle gespeichert werden, und es gibt auch Tos-Daten. Das sind große Datenmengen: Text, JSON. Sie werden in separaten Tabletten aufbewahrt. Und laut diesen Tablets passiert die gleiche Geschichte mit Blähungen, das heißt, alles ist beim Alten. Sie werden lediglich separat aufgeführt.
Danke für den Bericht! Wie akzeptabel ist es, Anweisungs-Timeout-Anfragen zu verwenden, um die Dauer zu begrenzen?
Sehr akzeptabel. Wir verwenden es überall. Und da wir keine eigenen Dienste haben, bieten wir Fernunterstützung an, es gibt eine ganze Reihe von Kunden. Und damit sind alle sehr zufrieden. Das heißt, wir haben Jobs in Cron, die prüfen. Es ist nur so, dass die Dauer der Sitzungen mit dem Kunden ausgehandelt wird, bevor wir nicht festlegen. Es könnte eine Minute sein, es könnten 10 Minuten sein. Dies hängt von der Belastung der Basis und ihrem Zweck ab. Aber wir alle verwenden pg_stat_activity.
Danke für den Bericht! Ich versuche, Ihren Bericht für meine Bewerbungen auszuprobieren. Und es scheint, dass wir überall eine Transaktion starten und sie überall explizit abschließen. Wenn eine Ausnahme auftritt, erfolgt das gleiche Rollback. Und dann dachte ich. Schließlich kann die Transaktion nicht explizit gestartet werden. Das ist wohl ein Hinweis für das Mädchen. Wenn ich nur eine Datensatzaktualisierung durchführe, startet die Transaktion dann in PostgreSQL und endet erst, wenn die Verbindung getrennt wird?
Wenn Sie jetzt über die Anwendungsebene sprechen, dann hängt es vom verwendeten Treiber und vom verwendeten ORM ab. Da gibt es viele Einstellungen. Wenn Sie die automatische Festschreibung aktiviert haben, wird dort eine Transaktion gestartet und sofort geschlossen.
Das heißt, es wird sofort nach dem Update geschlossen?
Das hängt von den Einstellungen ab. Ich habe eine Einstellung benannt. Hier ist die automatische Festschreibung aktiviert. Sie kommt ziemlich häufig vor. Wenn es aktiviert ist, wurde die Transaktion geöffnet und geschlossen. Es sei denn, Sie haben ausdrücklich „Transaktion starten“ und „Transaktion beenden“ gesagt, sondern einfach eine Anfrage in die Sitzung gestartet.
Guten Tag! Danke für den Bericht! Stellen Sie sich vor, wir haben eine Datenbank, die immer größer wird, und dann geht auf dem Server der Speicherplatz aus. Gibt es Tools, um diese Situation zu beheben?
Der Platz auf dem Server muss unbedingt überwacht werden.
Zum Beispiel ging DBA Tee trinken, war in einem Resort usw.
Wenn ein Dateisystem erstellt wird, wird zumindest etwas Reserveraum geschaffen, in den keine Daten geschrieben werden.
Was ist, wenn es komplett Null ist?
Dort heißt es reservierter Speicherplatz, das heißt, er kann freigegeben werden, und je nachdem, wie groß er angelegt wurde, erhält man freien Speicherplatz. Standardmäßig weiß ich nicht, wie viele es sind. Und in einem anderen Fall liefern Sie Datenträger, damit Sie einen Ort haben, an dem Sie einen Wiederherstellungsvorgang durchführen können. Sie können einige Tabellen löschen, die Sie garantiert nicht benötigen.
Gibt es keine anderen Tools?
Es ist immer handgemacht. Und an der Stelle wird offenbart, was dort besser zu tun ist, denn es gibt Daten, die kritisch sind, und es gibt unkritische Daten. Und für jede Datenbank und Anwendung, die damit arbeitet, kommt es auf das Unternehmen an. Es wird immer vor Ort entschieden.
Danke für den Bericht! Ich habe zwei Fragen. Zunächst haben Sie Folien gezeigt, in denen gezeigt wurde, dass bei hängengebliebenen Transaktionen sowohl der Tabellenplatz als auch die Größe des Index zunehmen. Und weiter unten im Bericht gab es eine Reihe von Dienstprogrammen, die das Tablet packten. Und was ist mit dem Index?
Sie packen sie auch ein.
Aber das Vakuum hat keinen Einfluss auf den Index?
Einige arbeiten mit einem Index. Zum Beispiel pg_rapack, pgcompacttable. Vakuum erstellt Indizes neu und beeinflusst sie. VACUUM FULL hat die Essenz, alles zu überschreiben, d. h. es funktioniert mit jedem.
Und die zweite Frage. Ich habe nicht verstanden, warum Berichte über Replikate so stark von der Replikation selbst abhängen. Es schien mir, dass Berichte das Lesen sind und die Replikation das Schreiben.
Was verursacht einen Replikationskonflikt? Wir haben einen Master, auf dem Prozesse ablaufen. Wir haben ein Autovakuum. Was macht Autovakuum eigentlich? Er schneidet einige alte Zeilen heraus. Wenn wir zu diesem Zeitpunkt eine Anfrage auf der Replik haben, die diese alten Zeilen liest, und auf dem Master eine Situation aufgetreten ist, in der das Autovakuum diese Zeilen als möglich zum Umschreiben markiert hat, dann haben wir sie überschrieben. Und wir haben ein Datenpaket erhalten. Wenn wir die Zeilen neu schreiben müssen, die die Anforderung auf dem Replikat benötigt, wartet der Replikationsprozess auf das von Ihnen konfigurierte Timeout. Und dann wird PostgreSQL entscheiden, was ihm wichtiger ist. Und die Replikation ist für ihn wichtiger als eine Anfrage, und er wird die Anfrage abfeuern, diese Änderungen an der Replik vorzunehmen.
Andrew, ich habe eine Frage. Sind diese wunderbaren Grafiken, die Sie während der Präsentation gezeigt haben, das Ergebnis einer Arbeit Ihres Versorgungsunternehmens? Wie wurden die Diagramme erstellt?
Dies ist ein Service .
Ist das ein kommerzielles Produkt?
Ja. Dies ist ein kommerzielles Produkt.
Source: habr.com