Ein wenig Sorgfalt und Pflege Ihrer PostgreSQL-Bereitstellung tragen wesentlich dazu bei, die Leistung sicherzustellen, unangenehme Entdeckungen zu vermeiden und eine sichere Vorhersagbarkeit zu schaffen. Hier sind 7 Dinge, die Sie im Auge behalten sollten.
Aufgeblähte Tabelle
PostgreSQL implementiert Transaktionen mit einer Technik namens MVCC. MVCC ist zu lang und ein Thema, um es im Detail zu diskutieren, aber es gibt drei Dinge, die Sie müssen davon wissen:
- Das Löschen einer Zeile markiert sie nur als „unsichtbar“ für zukünftige Transaktionen.
- Durch das Aktualisieren einer Zeile wird eine neue Version der Zeile erstellt. Die alte Version ist für zukünftige Transaktionen als unsichtbar markiert, und die neue Version ist als sichtbar markiert.
- In regelmäßigen Abständen muss sich jemand alle derzeit laufenden Transaktionen ansehen und sagen:OK, die älteste Transaktion hier ist Nr. 42, sodass jede Zeilenversion, die für Nr. 42 unsichtbar ist, physisch gelöscht werden kann, ohne die Datenkonsistenz zu beeinträchtigen.
So funktioniert MVCC (im Wesentlichen), und die Implikation ist, dass Updates werden Ihren physischen Datenbankspeicherbedarf erhöhen und Löschvorgänge nicht mach es kleiner. MVCC klingt nach einer faulen Methode, aber es ist beliebt, weil es sowohl Konsistenz als auch Leistung bietet.
Die unerwünschten, veralteten Zeilenversionen in einer Tabelle werden als Bloat bezeichnet (oder tote Reihen ). Der Prozess, der Blähungen beseitigen kann, wird Vakuum genannt . PostgreSQL hat einen automatisch ausgelösten Vakuumprozess mit einstellbaren Schwellenwerten namens Autovacuum und natürlich den VACUUM-Befehl.
Im Allgemeinen kann Bloat auch Abfragen aufgrund ungenauer Sichtbarkeitskarten und verschwendeter Festplatten-E/A verlangsamen.
Aus diesem Grund sollten Sie regelmäßig:
- überwachen Sie das Ausmaß der Aufblähung in einer Datenbank
- Lassen Sie das Vakuum regelmäßig laufen
- Überwachen Sie, ob das Vakuum regelmäßig für alle Tabellen ausgeführt wird
Es gibt einige SQL-Abfragen, um Aufblähungsschätzungen pro Tabelle bereitzustellen. Das Open-Source-Toolpgmetrics bietet Aufblähungsschätzungen sowie die letzten Laufzeiten des manuellen und automatischen Vakuums.
Indexaufblähung
Indizes können auch aufblähen. Obwohl die interne Struktur von Indizes für den SQL-Benutzer undurchsichtig ist und je nach Indextyp (BTree, Hash, GIN, GIST usw.) variiert, bleibt die allgemeine Idee bestehen, dass beim Löschen von Zeilen, auf die vom Index verwiesen wird, der Platz von den zugehörigen Informationen belegt wird innerhalb des Indexes wird nur logisch gelöscht und nicht wieder an das Dateisystem freigegeben. Der logisch gelöschte Platz kann später vom Index wiederverwendet werden.
Es gibt zwei Möglichkeiten, Postgres dazu zu bringen, die physische Größe eines Index zu verkleinern:
- die VOLLSTÄNDIGE Version des VACUUM-Befehls
- REININDEX
Das Aufblähen des Indexes muss überwacht werden, damit Sie zumindest wissen, wie viel Speicherplatz ungenutzt bleibt. In Tabellen mit hoher Zeilenänderung ist es nicht ungewöhnlich, regelmäßige Indexneuaufbau-Jobs einzurichten.
Index Bloat kann auch durch die gleichen Abfragen wie zuvor und auch über pgmetrics erhalten werden.
Lange laufende Transaktionen
Transaktionen sollten so kurz wie möglich gehalten werden, insbesondere in einem MVCC-System.
Stellen Sie sich vor, dass eine Transaktion gestern gestartet wurde und kurz danach ein Vakuumlauf stattfand. Nun, solange diese Transaktion offen ist, sind weitere Staubsauger nutzlos, da unsere Transaktion per Definition alle Zeilen aller Tabellen so sehen muss, wie sie waren, als unsere Transaktion gestern begann. Auch wenn unsere Transaktion schreibgeschützt ist, ist dies immer noch der Fall.
Infolgedessen führen lang andauernde Transaktionen zu einer Aufblähung. Sie hängen auch an Systemressourcen, halten nicht aufgehobene Sperren und erhöhen die Wahrscheinlichkeit von Deadlocks.
Der beste Weg, um nach lang andauernden Transaktionen Ausschau zu halten, besteht darin, eine Warnung für die Anzahl der Transaktionen einzurichten, die länger als eine bestimmte Dauer ausgeführt wurden. Diese erhalten Sie in der Statistikansicht pg_stat_activity , etwa so:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Replikationsverzögerung
Wenn die Streaming-Replikation verwendet wird, um alle Änderungen von einem primären PostgreSQL-Server auf einen Hot-Standby-Server (auch bekannt als Lesereplikat) zu replizieren, gibt es normalerweise eine geringfügige Verzögerung zwischen dem Zeitpunkt, zu dem Zeilenaktualisierungen auf dem primären Server erfolgen, und dem Zeitpunkt, zu dem die Änderungen für Anwendungen sichtbar sind, die mit dem Standby-Server verbunden sind .
Es gibt jedoch Fälle, in denen diese Verzögerung zunehmen kann:
- Das Standby-System ist nicht in der Lage, die Änderungen vom primären System schnell genug zu empfangen und anzuwenden, um damit Schritt zu halten, normalerweise wegen hoher Auslastung oder Unterversorgung
- ein fehlerhaftes Netzwerk oder Laufwerk
- Abfragekonflikte
Ein Standby mit einer hohen oder schlimmer noch zunehmenden Replikationsverzögerung kann dazu führen, dass Anfragen an das Standby veraltete Daten zurückgeben, und ein Standby, das für Failover nicht geeignet ist.
Wenn Sie eine Streaming-Replikation eingerichtet haben, ist die Überwachung der Replikationsverzögerungen zwischen jedem Primär-Standby-Paar sehr wichtig, und Sie sollten Warnungen einrichten, um zu überprüfen, ob die Replikationsverzögerungen eine Minute überschreiten oder welcher Schwellenwert für Ihre Einrichtung sinnvoll ist.
In diesem Beitrag erfahren Sie viel mehr darüber, wie Sie die Replikationsverzögerung sowohl vom primären als auch vom Standby-Ende aus messen und überwachen können.
Inaktive Replikationsslots
Die in PostgreSQL 9.4 eingeführte Verwendung von Replikationsslots macht die Streamingreplikation robuster und effizienter. Im Wesentlichen meldet der Standby-Server seinen Replikationsfortschritt an den Primärserver, der diese Informationen im „Replikations-Slot“ speichert.
Dadurch weiß der Primary jetzt jederzeit, wie weit der Standby hinterher ist. Dadurch kann der Primärserver einen ausreichenden Rückstand an WAL-Dateien (die zum Fortsetzen der Replikation benötigt werden) behalten, wenn der Standby-Server offline geht. Wenn also der Standby-Server auch nach langer Zeit wiederkehrt, kann der Primärserver immer noch garantieren, dass die Replikation fortgesetzt werden kann.
Vor den Replikationsslots kann der Primärserver alte WAL-Dateien bereinigen, da er nicht wissen konnte, ob seine Standbys sie benötigten oder nicht. Wenn eine von astandby benötigte WAL-Datei gelöscht wird, gibt es keine Möglichkeit, die Replikation fortzusetzen; es muss von Grund auf neu eingerichtet werden.
Das Verhalten des Primärservers, WAL-Dateien auf unbestimmte Zeit aufzubewahren, führt jedoch zu einem weiteren Problem. Wenn ein Standby zurückgezogen und der zugehörige Replikationsslot nicht gelöscht wurde, werden WAL-Dateien für immer aufbewahrt. WAL-Dateien, die aus diesem Grund aufbewahrt werden, unterliegen nicht den durch max_wal_size festgelegten Beschränkungen und andere Konfigurationsoptionen.
Diese Situation wird andauern, bis WAL-Dateien den gesamten Speicherplatz aufbrauchen, ohne dass eine Warnung in den PostgreSQL-Protokolldateien angezeigt wird.
Unnötig zu erwähnen, dass inaktive Replikationsschlitze behandelt werden müssen, wenn sie erfasst werden. Finden Sie Ihre inaktiven Replikationsslots mit:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Status analysieren
ANALYZE wird für Tabellen ausgeführt, um statistische Informationen über den Inhalt der Tabelle zu sammeln und zu aktualisieren. Diese Informationen werden vom Abfrageplaner verwendet, um den Ausführungsplan für jede SQL-Abfrage vorzubereiten. Aktuelle Statistiken über den Tabelleninhalt führen zu einem besseren Ausführungsplan, was wiederum zu einer schnelleren Abfrage führt.
Der Autovacuum-Daemon führt normalerweise ANALYZE nach VACUUM aus. Dies kann jedoch für ANALYZE nicht häufig genug sein. Wenn die Verteilung der Daten in einer Tabelle häufig ändert, sollten Sie ANALYZE häufiger ausführen.
Typischerweise verhält sich ANALYZE ziemlich gut – es benötigt nur Lesesperren, verbraucht nicht zu viel Ressourcen und wird in angemessener Zeit abgeschlossen. Es ist sicher, auf der Seite zu sein, es öfter als nicht auszuführen.
Es ist eine gute Idee, nach Tabellen Ausschau zu halten, die seit einiger Zeit nicht mehr ANALYSIERT wurden. Finden Sie mit der Abfrage heraus, wann Ihre Tabellen zuletzt (automatisch) analysiert wurden:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Ressourcennutzung
Die Überwachung der CPU-Auslastung, des Arbeitsspeichers und der Festplattennutzung trägt wesentlich dazu bei, dass Sie genügend Kapazität zur Verfügung haben, um die wachsenden Anforderungen der Anwendungen zu erfüllen, die Ihre Datenbank verwenden.
PostgreSQL erzeugt einen Prozess, um eine Verbindung zu handhaben. Obwohl dies heutzutage vielleicht nicht die skalierbarste Architektur ist, trägt sie doch viel zur Stabilität bei. Es macht auch die durchschnittliche OS-Last aussagekräftiger. Da PostgreSQL-Boxen normalerweise nur PostgreSQL ausführen, bedeutet ein Lastdurchschnitt von beispielsweise 3 normalerweise, dass 3 Verbindungen darauf warten, dass CPU-Kerne verfügbar werden, für die sie geplant werden können. Die Überwachung Ihrer durchschnittlichen maximalen Auslastung während eines typischen Tages oder einer typischen Woche kann eine Schätzung darüber liefern, wie über- oder unterversorgt Ihre Box an der CPU-Front ist.
Arbeitsspeicher und freier Speicherplatz sind natürlich standardmäßig zu überwachende Dinge. Mehr Verbindungen und länger laufende Transaktionen stellen höhere Anforderungen an den Speicher. Denken Sie bei der Überwachung des freien Speicherplatzes daran, ihn pro Tablespace zu verfolgen.
