🥇Deep Dive into PostgreSQL internal statistics. Alexey Lesovsky

Die Auswertung des Berichts von Alexey Lesovsky aus dem Jahr 2015 "Deep Dive into PostgreSQL interne Statistiken"

Haftungsausschluss des Autors des Berichts: Ich möchte darauf hinweisen, dass dieser Bericht aus November 2015 stammt — es sind mehr als 4 Jahre vergangen und viel Zeit vergangen. Die im Bericht behandelte Version 9.4 wird nicht mehr unterstützt. In den letzten 4 Jahren wurden 5 neue Versionen veröffentlicht, in denen viele Neuerungen, Verbesserungen und Änderungen hinsichtlich der Statistiken eingeführt wurden und ein Teil des Materials somit veraltet und nicht mehr aktuell ist. Ich habe beim Überarbeiten versucht, diese Stellen zu kennzeichnen, um den Leser nicht in die Irre zu führen. Ich habe jedoch nicht vor, diese Abschnitte neu zu schreiben, da es sehr viele davon gibt und letztlich ein ganz anderer Bericht herauskommen würde.

Das PostgreSQL-Datenbanksystem ist ein riesiger Mechanismus, der aus vielen Teilsystemen besteht, deren reibungslose Zusammenarbeit die Leistung des DBMS direkt beeinflusst. Während des Betriebs wird die Statistikerhebung und Informationssammlung über die Funktionsweise der Komponenten sichergestellt, was es ermöglicht, die Effizienz von PostgreSQL zu bewerten und Maßnahmen zur Leistungsteigerung zu ergreifen. Allerdings gibt es eine Menge Informationen, die in einer ziemlich vereinfachten Form dargestellt sind. Die Verarbeitung und Interpretation dieser Informationen ist oft eine alles andere als triviale Aufgabe, und der "Zoo" von Werkzeugen und Dienstprogrammen kann selbst erfahrene DBAs schnell überfordern.

Guten Tag! Mein Name ist Alexey. Wie Ilja gesagt hat, werde ich über die Statistiken von PostgreSQL sprechen.

Aktivitätsstatistiken von PostgreSQL. PostgreSQL hat zwei Arten von Statistiken. Die Aktivitätsstatistik, über die wir sprechen werden. Und die Statistiken des Planers über die Datenverteilung. Ich werde mich speziell auf die Aktivitätsstatistik von PostgreSQL konzentrieren, die es uns ermöglicht, die Leistung zu beurteilen und diese zu verbessern.

Ich werde erläutern, wie man Statistiken effektiv zur Lösung der verschiedenen Probleme, die bei Ihnen auftreten oder auftreten können, nutzt.

Was wird im Bericht nicht behandelt? Im Bericht werde ich nicht auf die Statistiken des Planers eingehen, da dies ein separates Thema für einen eigenen Bericht darüber ist, wie Daten in der Datenbank gespeichert werden und wie der Abfrageplaner ein Bild von den qualitativen und quantitativen Eigenschaften dieser Daten erhält.

Und es wird keine Überblick über die Werkzeuge geben, ich werde kein Produkt mit einem anderen vergleichen. Es wird keine Werbung geben. Lassen Sie uns das beiseite lassen.

Ich möchte Ihnen zeigen, dass es nützlich ist, Statistiken zu verwenden. Das ist notwendig. Es ist nicht beängstigend, sie zu nutzen. Wir benötigen nur ganz normales SQL und Grundkenntnisse über SQL.

Und wir werden darüber sprechen, welche Statistiken für die Problemlösung ausgewählt werden sollten.

Wenn wir uns PostgreSQL ansehen und im Betriebssystem einen Befehl zur Anzeige der Prozesse ausführen, sehen wir eine "schwarze Box". Wir sehen einige Prozesse, die etwas tun, und können anhand der Namen ungefähr vorstellen, was sie dort machen, womit sie beschäftigt sind. Aber im Grunde ist das eine schwarze Box, in die wir nicht hineinschauen können.

Wir können die CPU-Auslastung in top, wir können die Speicherauslastung mit verschiedenen Systemtools betrachten, aber wir können nicht in PostgreSQL hineinschauen. Dafür benötigen wir andere Werkzeuge.

Und weiterführend werde ich Ihnen erzählen, wo die Zeit hingeht. Wenn wir uns PostgreSQL in Form eines solchen Schemas vorstellen, können wir beantworten, wo die Zeit hingeht. Es sind zwei Dinge: die Bearbeitung von Client-Anfragen von Anwendungen und die Hintergrundaufgaben, die PostgreSQL zur Aufrechterhaltung seiner Funktionsfähigkeit ausführt.

Wenn wir von der oberen linken Ecke aus beginnen, können wir verfolgen, wie die Client-Anfragen verarbeitet werden. Eine Anfrage kommt von der Anwendung und eine Client-Sitzung wird für die weitere Bearbeitung geöffnet. Die Anfrage wird an den Planer weitergeleitet. Der Planer erstellt einen Ausführungsplan. Dieser wird zur Ausführung weitergeleitet. Es erfolgt eine blockbasierte Ein- und Ausgabe von Daten, die mit Tabellen und Indizes verbunden ist. Die benötigten Daten werden von den Festplatten in den Speicher in einen speziellen Bereich namens "shared buffers" gelesen. Die Ergebnisse der Anfrage, falls es sich um Updates oder Deletes handelt, werden im Transaktionsprotokoll im WAL festgehalten. Einige statistische Informationen gelangen in die Protokolle oder zum Statistik-Sammler. Und das Ergebnis der Anfrage wird bereits an den Client zurückgegeben. Danach kann der Client alles mit einer neuen Anfrage wiederholen.

Was ist mit den Hintergrundaufgaben und -prozessen? Es gibt mehrere Prozesse, die die Funktionsfähigkeit sicherstellen und die Datenbank im normalen Betriebsmodus halten. Diese Prozesse werden ebenfalls im Vortrag behandelt: autovacuum, Checkpointer, Prozesse, die mit der Replikation verbunden sind und der Background Writer. Jeden von ihnen werde ich im Verlauf des Vortrags ansprechen.

Welche Probleme gibt es mit den Statistiken?

Es gibt viele Informationen. PostgreSQL 9.4 bietet 109 Metriken zur Anzeige von Statistiken. Wenn jedoch in der Datenbank viele Tabellen, Schemata und Datenbanken gespeichert sind, müssen all diese Metriken mit der entsprechenden Anzahl von Tabellen und Datenbanken multipliziert werden. Das heißt, die Informationen nehmen noch mehr zu. Und es ist sehr einfach, in ihnen unterzugehen.
Ein weiteres Problem ist, dass die Statistiken durch Zähler dargestellt werden. Wenn wir uns diese Statistiken anschauen, sehen wir ständig steigende Zähler. Wenn seit dem Zurücksetzen der Statistiken viel Zeit vergangen ist, sehen wir Milliardenwerte. Diese geben uns jedoch keine Informationen.
Es gibt keine Historie. Wenn Sie einen Ausfall hatten, der vor 15 - 30 Minuten aufgetreten ist, können Sie nicht auf die Statistik zugreifen und sehen, was in den letzten 15 - 30 Minuten passiert ist. Das ist ein Problem.
Das Fehlen eines integrierten Werkzeugs in PostgreSQL ist ein Problem. Die Entwickler des Kernels bieten kein Hilfsprogramm an. Sie haben nichts dergleichen. Sie geben einfach die Statistiken in der Datenbank zur Verfügung. Nutzen Sie es, stellen Sie Anfragen, was Sie möchten, machen Sie damit, was Sie wollen.
Da es kein integriertes Werkzeug in PostgreSQL gibt, führt dies zu einem anderen Problem. Viele Drittanbieter-Tools. Jedes Unternehmen, das mehr oder weniger kompetente Mitarbeiter hat, versucht, sein eigenes Programm zu schreiben. Schließlich gibt es in der Community viele Werkzeuge, die man zur Arbeit mit Statistiken verwenden kann. Einige Werkzeuge haben bestimmte Funktionen, während andere keine davon haben oder neue Funktionen bieten. So entsteht die Situation, dass man zwei, drei oder vier Werkzeuge nutzen muss, die sich teilweise überschneiden und unterschiedliche Funktionen haben. Das ist sehr unangenehm.

Was folgt daraus? Es ist wichtig, Statistiken direkt abzurufen, um nicht von Programmen abhängig zu sein, oder die Programme selbst zu verbessern: einige Funktionen hinzuzufügen, um einen eigenen Nutzen zu erhalten.

Und es sind grundlegende SQL-Kenntnisse erforderlich. Um Daten aus den Statistiken zu erhalten, müssen SQL-Abfragen formuliert werden, d.h. Sie müssen wissen, wie man SELECT und JOIN erstellt.

Statistiken bieten uns mehrere Aspekte. Diese können in Kategorien unterteilt werden.

Die erste Kategorie sind Ereignisse, die in der Datenbank stattfinden. Das sind Ereignisse wie Anfragen, Zugriffe auf Tabellen, Autovacuum, Commits – all das sind Ereignisse. Die entsprechenden Zähler, die mit diesen Ereignissen verbunden sind, werden inkrementiert. Und wir können diese Ereignisse verfolgen.
Die zweite Kategorie sind Eigenschaften von Objekten wie Tabellen und Datenbanken. Diese haben Eigenschaften, wie etwa die Größe der Tabellen. Wir können das Wachstum der Tabellen und Indizes verfolgen. Außerdem können wir Änderungen in der Dynamik ansehen.
Die dritte Kategorie ist die Zeit, die für ein Ereignis benötigt wird. Eine Anfrage ist ein Ereignis. Es hat eine spezifische Dauer. Hier startet es, dort endet es. Das können wir nachverfolgen. Entweder die Zeit zum Lesen eines Blocks von der Festplatte oder zum Schreiben. Solche Dinge werden ebenfalls verfolgt.

Die Quellen der Statistiken sind wie folgt dargestellt:

Im Shared Memory gibt es ein Segment zur Speicherung statischer Daten; dort befinden sich die Zähler, die ständig inkrementiert werden, wenn bestimmte Ereignisse eintreten oder es Momente im Datenbankbetrieb gibt.
All diese Zähler sind für den Benutzer und sogar für den Administrator nicht zugänglich. Es handelt sich um niedrigstufige Dinge. Um auf sie zuzugreifen, bietet PostgreSQL eine Schnittstelle in Form von SQL-Funktionen. Wir können mit diesen Funktionen SELECT-Abfragen durchführen und eine bestimmte Metrik (oder eine Reihe von Metriken) erhalten.
Allerdings ist die Benutzung dieser Funktionen nicht immer praktisch, daher sind diese Funktionen die Basis für Views. Das sind virtuelle Tabellen, die Statistiken zu einem spezifischen Teilsystem oder zu einem bestimmten Set von Ereignissen in der Datenbank bereitstellen.
Diese integrierten Views sind die Hauptschnittstelle für Benutzer zur Arbeit mit Statistiken. Sie sind standardmäßig ohne zusätzliche Konfiguration verfügbar, Sie können sie sofort verwenden, um Informationen abzurufen. Darüber hinaus gibt es die Contrib-Pakete. Die Contrib-Pakete sind offiziell. Sie können das Paket postgresql-contrib installieren (z. B. postgresql94-contrib), den erforderlichen Modul in der Konfiguration laden, ihm Parameter zuweisen, PostgreSQL neu starten und es verwenden. Je nach Distribution ist das Contrib-Paket in den neuesten Versionen Teil des Hauptpakets.).
Es gibt inoffizielle Contribs. Diese sind nicht in der Standardlieferung von PostgreSQL enthalten. Sie müssen entweder kompiliert oder als Bibliothek installiert werden. Die Varianten können sehr unterschiedlich sein, je nachdem, was der Entwickler dieses inoffiziellen Contribs sich ausgedacht hat.

Auf dieser Folie sind alle Ansichten (VIEWs) und einige der Funktionen aufgeführt, die in PostgreSQL 9.4 verfügbar sind. Wie wir sehen, gibt es sehr viele davon. Und es ist ziemlich leicht, den Überblick zu verlieren, wenn Sie damit zum ersten Mal konfrontiert werden.

Wenn wir jedoch das vorherige Bild betrachten Wie Zeit in PostgreSQL verbraucht wird und dieses mit der Liste abgleichen, erhalten wir solch ein Bild. Jede Ansicht (VIEWs) oder jede Funktion kann für unterschiedliche Zwecke zur Erfassung entsprechender Statistiken verwendet werden, während PostgreSQL arbeitet. Und wir können bereits einige Informationen über die Funktionsweise der Subsysteme erhalten.

Das erste, was wir betrachten werden, ist pg_stat_database. Wie wir sehen, handelt es sich um eine Ansicht. Sie enthält viele Informationen. Die Informationen sind sehr vielfältig. Und sie bietet sehr nützliches Wissen darüber, was in unserer Datenbank passiert.

Was können wir Nützliches daraus ziehen? Lassen Sie uns mit den einfachsten Dingen beginnen.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

Das erste, was wir uns ansehen können, ist der Cache-Hit-Prozentsatz. Der Cache-Hit-Prozentsatz ist eine nützliche Kennzahl. Sie ermöglicht es, zu bewerten, wie viel Daten aus den Shared Buffers abgerufen werden und wie viel von der Festplatte gelesen wird.

Es ist klar, dass je höher der Cache-Hit, desto besser. Wir bewerten diese Kennzahl als Prozentsatz. Wenn unser prozentuales Verhältnis dieser Cache-Hits beispielsweise über 90 % liegt, ist das gut. Wenn es jedoch unter 90 % sinkt, bedeutet das, dass wir nicht genügend Speicher haben, um die "heißen" Daten im Speicher zu halten. Um diese Daten zu verwenden, muss PostgreSQL auf die Festplatte zugreifen, was langsamer ist, als wenn die Daten aus dem Speicher gelesen würden. Und es muss bereits darüber nachgedacht werden, den Speicher zu erhöhen: entweder die Shared Buffers zu vergrößern oder den physischen Speicher (RAM) aufzurüsten.

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

Was kann man sonst noch aus dieser Ansicht entnehmen? Man kann die Atypien betrachten, die in der Datenbank auftreten. Was wird hier angezeigt? Es gibt Commits, Rollbacks, die Erstellung temporärer Dateien, deren Größe, Deadlocks und Konflikte.

Wir können diese Anfrage nutzen. Dieser SQL ist ziemlich einfach. Und wir können uns diese Daten anschauen.

Hier sind sofort die Schwellenwerte. Wir betrachten das Verhältnis von Commits und Rollbacks. Commits sind die erfolgreiche Bestätigung einer Transaktion. Rollbacks sind Rückabwicklungen, d. h. eine Transaktion hat irgendeine Arbeit geleistet, die Datenbank belastet, etwas berechnet, und dann trat ein Fehler auf, und die Ergebnisse der Transaktion werden verworfen. Das heißt, eine ständig steigende Anzahl von Rollbacks ist schlecht. Man sollte versuchen, sie zu vermeiden und den Code so zu ändern, dass so etwas nicht passiert.

Konflikte (conflicts) sind mit der Replikation verbunden. Auch sie sollten vermieden werden. Wenn Sie Anfragen haben, die auf der Replik ausgeführt werden und Konflikte entstehen, müssen diese Konflikte analysiert werden, um zu sehen, was passiert. Details finden Sie in den Protokollen. Und Konfliktsituationen sollten beseitigt werden, damit die Anfragen der Anwendung fehlerfrei funktionieren.

Deadlocks sind ebenfalls eine schlechte Situation. Wenn Anfragen um Ressourcen kämpfen, hat eine Anfrage auf eine Ressource zugegriffen und eine Sperre erlangt, während eine andere Anfrage auf eine zweite Ressource zugegriffen hat und ebenfalls eine Sperre erlangt hat, dann haben beide Anfragen auf die Ressourcen des jeweils anderen zugegriffen und sind in der Erwartung, dass der Nachbar die Sperre aufhebt, blockiert. Das ist auch eine problematische Situation. Diese müssen auf der Ebene der Neuprogrammierung der Anwendungen und der Serialisierung des Zugriffs auf Ressourcen gelöst werden. Und wenn Sie sehen, dass Ihre Deadlocks ständig zunehmen, sollten Sie die Details in den Protokollen überprüfen, die aufgetretenen Situationen analysieren und das Problem herausfinden.

Temporäre Dateien (temp_files) sind ebenfalls schlecht. Wenn einer Benutzeranfrage der Speicherplatz für die Speicherung von temporären Daten fehlt, wird eine Datei auf der Festplatte erstellt. Alle Operationen, die sie im temporären Puffer im Speicher ausführen könnte, werden dann auf der Festplatte ausgeführt. Das ist langsam. Das erhöht die Ausführungszeit der Anfrage. Und der Client, der die Anfrage an PostgreSQL gesendet hat, erhält die Antwort etwas später. Wenn all diese Operationen im Speicher ausgeführt werden, wird Postgres viel schneller antworten und der Client muss weniger warten.

Pg_stat_bgwriter ist eine Ansicht, die die Arbeit von zwei Hintergrundsystemen von PostgreSQL beschreibt: das ist Checkpointer und Background Writer.

Zunächst betrachten wir die Kontrollpunkte, die sogenannten. Checkpoints. Was sind Kontrollpunkte? Ein Kontrollpunkt ist eine Position im Transaktionsprotokoll, die anzeigt, dass alle in den Protokollen festgehaltenen Datenänderungen erfolgreich mit den Daten auf der Festplatte synchronisiert wurden. Der Prozess kann je nach Arbeitslast und Einstellungen lange dauern und besteht hauptsächlich darin, schmutzige Seiten in den gemeinsamen Puffern mit den Datendateien auf der Festplatte zu synchronisieren. Wozu ist das nötig? Wenn PostgreSQL ständig auf die Festplatte zugreifen und dort Daten abrufen und bei jedem Zugriff Daten schreiben würde, wäre das langsam. Daher hat PostgreSQL einen Arbeitsspeicherbereich, dessen Größe von den Konfigurationseinstellungen abhängt. Postgres platziert in diesem Speicher aktive Daten zur späteren Verarbeitung oder Ausgabe auf Anfragen. Bei Anfragen zur Datenänderung erfolgt deren Modifizierung. Und wir erhalten zwei Versionen von Daten. Eine im Speicher, die andere auf der Festplatte. Und regelmäßig müssen diese Daten synchronisiert werden. Wir müssen die im Speicher geänderten Daten auf die Festplatte synchronisieren. Dafür sind Checkpoints erforderlich.

Der Checkpoint durchläuft die gemeinsamen Puffer, kennzeichnet die schmutzigen Seiten, die für den Checkpoint benötigt werden. Dann wird ein zweiter Durchlauf durch die gemeinsamen Puffer gestartet. Und die Seiten, die für den Checkpoint markiert sind, werden synchronisiert. Auf diese Weise erfolgt die Daten-Synchronisierung bereits mit der Festplatte.

Es gibt zwei Arten von Kontrollpunkten. Ein Checkpoint wird nach Timeout durchgeführt. Dieser Checkpoint ist nützlich und gut – checkpoint_timed. Und es gibt Checkpoints auf Anfrage – checkpoint required. Ein solcher Kontrollpunkt tritt auf, wenn wir eine sehr hohe Datenaufzeichnung haben. Wir haben eine große Menge an Transaktionsprotokollen geschrieben. Und PostgreSQL glaubt, dass es alles so schnell wie möglich synchronisieren, einen Kontrollpunkt setzen und weitermachen muss.

Und wenn Sie die Statistiken betrachtet haben pg_stat_bgwriter und gesehen haben, dass Ihre checkpoint_req viel größer ist als checkpoint_timed, dann ist das schlecht. Warum ist das schlecht? Das bedeutet, dass PostgreSQL sich in einer ständigen Stresssituation befindet, in der es Daten auf die Festplatte schreiben muss. Ein Checkpoint nach Timeout ist weniger stressig und erfolgt nach einem internen Zeitplan und ist zeitlich gestreckt. PostgreSQL hat die Möglichkeit, Pausen in der Arbeit einzulegen und das Festplattensystem nicht zu belasten. Das ist für PostgreSQL vorteilhaft. Und die Anfragen, die während des Checkpoints ausgeführt werden, werden nicht durch die ausgelastete Festplattensystem belastet.

Und für die Regelung des Checkpoints gibt es drei Parameter:

checkpoint_segments.
checkpoint_timeout.
checkpoint_completion_target.

Sie ermöglichen die Regulierung der Arbeit der Kontrollpunkte. Aber ich werde nicht lange darauf eingehen. Ihr Einfluss ist ein eigenes Thema.

Achtung: Die im Bericht behandelte Version 9.4 ist bereits veraltet. In modernen Versionen von PostgreSQL wurde der Parameter checkpoint_segments durch die Parameter min_wal_size und max_wal_size.

Das nächste Subsystem ist der Hintergrundschreiber — Background Writer. Was macht er? Er arbeitet ständig in einer Endlosschleife. Er scannt Seiten im Shared Buffers und schreibt die schmutzigen Seiten, die er gefunden hat, auf die Festplatte. So hilft er dem Checkpointer, weniger Arbeit bei der Ausführung der Kontrollpunkte zu leisten.

Wozu wird er noch benötigt? Er sichert den Bedarf an sauberen Seiten im Shared Buffers, falls diese plötzlich (in großer Anzahl und sofort) für die Datenspeicherung benötigt werden. Stellen Sie sich vor, es tritt eine Situation auf, in der saubere Seiten benötigt werden, und sie sind bereits im Shared Buffers vorhanden. PostgreSQL backend nimmt sie einfach und nutzt sie, er muss nichts selbst säubern. Wenn es jedoch keine solchen Seiten gibt, stoppt das Backend die Arbeit und beginnt, Seiten zu suchen, um sie auf die Festplatte zu schreiben und für seine Bedürfnisse zu verwenden – was sich negativ auf die Ausführungszeit der gerade laufenden Anfrage auswirkt. Wenn Sie sehen, dass Ihr Parameter maxwritten_clean hoch ist, bedeutet dies, dass der Hintergrundschreiber seine Arbeit nicht bewältigt und die Parameter bgwriter_lru_maxpages, um ihn in einem Zyklus mehr Arbeit leisten zu lassen und mehr Seiten zu säubern.

Ein weiterer sehr nützlicher Indikator ist buffers_backend_fsync. Backends führen kein fsync durch, weil das langsam ist. Sie übergeben fsync an den Checkpointer höher im IO-Stack. Der Checkpointer hat seine eigene Warteschlange, die er regelmäßig fsync bearbeitet und die Seiten im Speicher mit den Dateien auf der Festplatte synchronisiert. Wenn die Warteschlange des Checkpointers groß und voll ist, sieht sich das Backend gezwungen, selbst fsync durchzuführen, was die Arbeit des Backends verlangsamt,, d. h. der Client erhält die Antwort später, als er könnte. Wenn Sie sehen, dass dieser Wert größer als null ist, dann ist das bereits ein Problem und es sollte Aufmerksamkeit auf die Einstellungen des Hintergrundschreibers gelegt werden, und auch die Leistungsfähigkeit des Festplattensubsystems sollte bewertet werden.

Achtung: _Der folgende Text beschreibt statistische Darstellungen im Zusammenhang mit der Replikation. Die meisten Namen von Darstellungen und Funktionen wurden in Postgres 10 umbenannt. Der Sinn der Umbenennungen bestand darin, zu ersetzen xlog auf wal und Standort auf in den Namen der Funktionen/Darstellungen usw. Ein spezielles Beispiel, die Funktion pg_xlog_location_diff() wurde umbenannt in pg_wal_lsn_diff() Hier haben wir auch viele Dinge. Aber wir benötigen nur die Punkte, die mit der location zusammenhängen.._

Wenn wir sehen, dass alle Werte gleich sind, ist das die ideale Situation und die Replikation ist nicht hinter dem Master zurück.

Dieser hexadezimale Wert ist die Position im Transaktionsprotokoll. Er wächst ständig, wenn im Datenbankbetrieb Aktivitäten stattfinden: Einfügungen, Löschungen usw.

wie viele xlog in Bytes geschrieben wurden $ select pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000'); Replikationsverzögerung in Bytes $ select client_addr, pg_xlog_location_diff(pg_current_xlog_location(), replay_location) from pg_stat_replication; Replikationsverzögerung in Sekunden $ select extract(epoch from now() - pg_last_xact_replay_timestamp());

Wenn sich diese Dinge unterscheiden, dann gibt es eine Verzögerung. Eine Verzögerung ist das Zurückbleiben der Replik von dem Master, d.h. die Daten unterscheiden sich zwischen den Servern.

Es gibt drei Gründe für das Zurückbleiben:

Das ist, weil das Speichersystem mit dem synchronen Schreiben der Dateien überfordert ist.

Es kann auch möglich sein, dass es Netzwerkprobleme gibt oder eine Überlastung des Netzwerks, bei der die Daten nicht rechtzeitig die Replik erreichen und sie nicht wiedergegeben werden können.
Und der Prozessor. Der Prozessor ist ein sehr seltener Fall. Ich habe das zwei oder drei Mal gesehen, aber es kann auch vorkommen.
Und hier sind drei Abfragen, die es uns ermöglichen, die Statistiken zu nutzen. Wir können einschätzen, wie viel wir im Transaktionsprotokoll geschrieben haben. Es gibt eine solche Funktion

pg_xlog_location_diff und wir können die Replikationsverzögerung in Bytes und Sekunden bewerten. Auch dafür verwenden wir Werte aus dieser Ansicht (VIEWs). _Anstelle von pg_xlog_location

Hinweis: diff() kann der Subtraktionsoperator verwendet werden, um einen Standort von einem anderen abzuziehen. Praktisch.Es gibt einen Punkt zur Verzögerung in Sekunden. Wenn auf dem Master keine Aktivitäten stattfinden, die Transaktion vor etwa 15 Minuten war und keine Aktivitäten mehr vorhanden sind, und wir diese Verzögerung auf der Replik sehen, werden wir eine Verzögerung von 15 Minuten sehen. Das sollte man sich merken. Und das kann verwirrend sein, wenn man sich diese Verzögerung angesehen hat.

Es gibt einen Punkt beim Lag in Sekunden. Wenn auf dem Master keine Aktivität stattfindet, die Transaktion jedoch vor etwa 15 Minuten war und es keine Aktivität gibt, und wenn wir diesen Lag auf der Replik betrachten, dann sehen wir einen Lag von 15 Minuten. Das sollte man im Hinterkopf behalten. Das kann verwirrend sein, wenn man diesen Lag betrachtet.

Pg_stat_all_tables – eine weitere nützliche Ansicht. Sie zeigt Statistiken zu den Tabellen. Wenn wir in unserer Datenbank Tabellen haben, die aktiv sind oder auf die zugegriffen wird, können wir diese Informationen aus dieser Ansicht abrufen.

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

Das Erste, was wir uns anschauen können, sind die sequentiellen Scans der Tabelle. Die Zahl nach diesen Durchgängen ist noch nicht unbedingt schlecht und ein Indikator dafür, dass wir bereits Maßnahmen ergreifen müssen.

Es gibt jedoch eine zweite Metrik – seq_tup_read. Dies ist die Anzahl der Zeilen, die durch das sequentielle Scannen zurückgegeben werden. Wenn die durchschnittliche Zahl 1.000, 10.000, 50.000, 100.000 übersteigt, ist das ein Hinweis darauf, dass möglicherweise ein Index erstellt werden sollte, um den Zugriff über den Index zu ermöglichen, oder dass die Abfragen, die solche sequentiellen Scans verwenden, optimiert werden sollten, um dies zu vermeiden.

Ein einfaches Beispiel: Nehmen wir an, eine Abfrage mit großem OFFSET und LIMIT wird verwendet. Zum Beispiel werden 100.000 Zeilen in der Tabelle gescannt, und danach werden 50.000 benötigte Zeilen entnommen, während die zuvor gescannten Zeilen verworfen werden. Dies ist ebenfalls ein schlechter Fall. Solche Abfragen sollten optimiert werden. Hier ist eine einfache SQL-Abfrage, mit der man dies einsehen und die erhaltenen Zahlen bewerten kann.

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

Die Größen der Tabellen können auch über diese Ansicht und mithilfe zusätzlicher Funktionen ermittelt werden. pg_total_relation_size(), pg_relation_size().

Im Allgemeinen gibt es Metakommandos dt und di, die in PSQL verwendet werden können, um ebenfalls die Größen der Tabellen und Indizes zu überprüfen.

Die Verwendung von Funktionen hilft uns jedoch, die Größen der Tabellen sowohl unter Berücksichtigung als auch ohne Berücksichtigung der Indizes einzusehen und bereits einige Bewertungen auf Grundlage des Wachstums der Datenbank vorzunehmen, d. h. wie sie wächst, mit welcher Intensität, und darauf basierend Optimierungen zu machen.

Aktivität beim Schreiben. Was bedeutet Schreiben? Lassen Sie uns die Operation betrachten. UPDATE – die Aktualisierung von Zeilen in der Tabelle. Im Wesentlichen bedeutet Update zwei (oder mehr) Operationen. Es handelt sich um das Einfügen einer neuen Version der Zeile und die Kennzeichnung der alten Version der Zeile als veraltet. Später wird der Autovakuum kommen und diese veralteten Zeilen entfernen, diesen Platz als verfügbar zum Wiederverwenden kennzeichnen.

Darüber hinaus ist Update nicht nur das Aktualisieren der Tabelle. Es beinhaltet auch die Aktualisierung der Indizes. Wenn Sie viele Indizes in der Tabelle haben, müssen beim Update alle Indizes, in denen die im Anfrage aktualisierten Felder beteiligt sind, ebenfalls aktualisiert werden. In diesen Indizes werden ebenfalls veraltete Versionen der Zeilen vorhanden sein, die bereinigt werden müssen.

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

Und aufgrund ihres Designs sind UPDATE-Operationen schwergewichtig. Aber sie können erleichtert werden. Es gibt Hot Updates. Sie wurden in PostgreSQL Version 8.3 eingeführt. Und was ist das? Das ist ein leichtgewichtiger Update, der keine Neuordnung der Indizes verursacht. Das heißt, wir haben den Datensatz aktualisiert, aber es wurde nur der Datensatz auf der Seite (die zur Tabelle gehört) aktualisiert, während die Indizes weiterhin auf denselben Datensatz auf der Seite verweisen. Es gibt dort eine interessante Logik: wenn der Vakuum kommt, reorganisiert er diese Ketten. Hot und alles funktioniert weiter ohne eine Aktualisierung der Indizes, und das geschieht mit geringeren Ressourcenaufwand.

Und wenn Sie n_tup_hot_upd hoch ist, dann ist das sehr gut. Das bedeutet, dass leichtgewichtige Updates überwiegen und es für die Ressourcen günstiger ist und alles hervorragend funktioniert.

ALTER TABLE table_name SET (fillfactor = 70);

Wie man das Volumen von Hot Updateserhöht? Wir können verwenden Fillfactor. Dieser definiert die Größe des reservierten freien Platzes beim Befüllen einer Seite in der Tabelle durch INSERTs. Wenn in die Tabelle Inserts kommen, füllen sie die Seite vollständig aus, ohne freien Platz zu lassen. Dann wird eine neue Seite reserviert. Wieder werden die Daten befüllt. Dieses Verhalten ist standardmäßig, fillfactor = 100 %.

Wir können den Fillfactor auf 70 % einstellen. Das bedeutet, dass bei Inserts eine neue Seite erstellt wird, aber nur 70 % dieser Seite belegt sind. Und 30 % bleiben als Reserve. Wenn ein Update erforderlich ist, wird es mit hoher Wahrscheinlichkeit auf derselben Seite stattfinden, und die neue Version der Zeile wird auf dieser Seite gespeichert. Ein Hot-Update wird durchgeführt. Dadurch wird das Schreiben in den Tabellen erleichtert.

select c.relname,
current_setting('autovacuum_vacuum_threshold') als av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') als av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
von pg_stat_user_tables s join pg_class c ON s.relname = c.relname
wo s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Warteschlange für den Autovacuum. Der Autovacuum ist ein Subsystem, über das es in PostgreSQL nur sehr wenig Statistik gibt. Wir können in den Tabellen nur in pg_stat_activity sehen, wie viele Vakuumvorgänge derzeit stattfinden. Es ist jedoch sehr schwierig zu verstehen, wie viele Tabellen er in der Warteschlange hat.

Hinweis: Mit der Version Postgres 10 hat sich die Situation mit dem Tracking des Autovacuum erheblich verbessert — es gibt jetzt die Ansicht pg_stat_progressvacuum, die die Überwachung des Autovacuums erheblich vereinfacht.

Wir können eine solche vereinfachte Abfrage verwenden. Und wir können sehen, wann das Vakuum durchgeführt werden sollte. Aber wie und wann sollte das Vakuum gestartet werden? Hier sind die veralteten Versionen der Zeilen, von denen ich zuvor gesprochen habe. Ein Update fand statt, die neue Version der Zeile wurde eingefügt. Damit entstand eine veraltete Version der Zeile. In der Tabelle pg_stat_user_tables gibt es einen solchen Parameter n_dead_tup. Dieser zeigt die Anzahl der "toten" Zeilen an. Sobald die Anzahl der toten Zeilen einen bestimmten Schwellenwert überschreitet, wird das Autovacuum für die Tabelle gestartet.

Wie wird dieser Schwellenwert berechnet? Es handelt sich um ein konkretes prozentuales Verhältnis zur Gesamtzahl der Zeilen in der Tabelle. Es gibt den Parameter autovacuum_vacuum_scale_factor. Dieser definiert das prozentuale Verhältnis. Angenommen, 10 % + ein zusätzlicher Basiswert von 50 Zeilen. Was passiert also? Wenn die Anzahl der toten Zeilen die Formel "10 % + 50" von allen Zeilen in der Tabelle überschreitet, wird die Tabelle für das Autovacuum freigegeben.

select c.relname,
current_setting('autovacuum_vacuum_threshold') als av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') als av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
von pg_stat_user_tables s join pg_class c ON s.relname = c.relname
wo s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Es gibt jedoch einen Punkt. Die Basiswerte der Parameter av_base_thresh und av_scale_factor Sie können individuell zugewiesen werden. Und entsprechend wird die Schwelle nicht global sein, sondern individuell für die Tabelle. Daher müssen wir einige Tricks und Kniffe verwenden, um die Berechnung vorzunehmen. Und wenn Sie interessiert sind, können Sie sich die Erfahrungen unserer Kollegen von Avito ansehen (der Link auf der Folie ist ungültig und im Text aktualisiert).

Sie haben für munin plugin, das diese Dinge berücksichtigt. Dort gibt es eine Auflistung auf zwei Seiten. Aber es berechnet korrekt und ermöglicht es recht effizient zu bewerten, wo wir viel Vakuum für die Tabellen benötigen und wo wenig.

Was können wir damit machen? Wenn wir eine große Warteschlange haben und das Auto-Vakuum nicht bewältigen kann, können wir die Anzahl der Vakuumarbeiter erhöhen oder einfach das Vakuum aggressiver gestalten, damit es früher ausgelöst wird und die Tabelle in kleinen Stücken verarbeitet. Und somit wird die Warteschlange kleiner. — Wichtig ist, die Belastung der Festplatten im Auge zu behalten, da Vakuum keine kostenlose Sache ist, obwohl mit dem Aufkommen von SSD/NVMe-Geräten das Problem weniger auffällig geworden ist.

Pg_stat_all_indexes – das sind Statistiken zu den Indizes. Sie ist klein. Und wir können basierend darauf Informationen zur Nutzung der Indizes erhalten. Und zum Beispiel können wir ermitteln, welche Indizes überflüssig sind.

Wie ich bereits erwähnt habe, update – das ist nicht nur die Aktualisierung von Tabellen, sondern auch die Aktualisierung von Indizes. Folglich müssen viele Indizes auf der Tabelle, wenn Zeilen aktualisiert werden, ebenfalls aktualisiert werden, und wenn wir ungenutzte Indizes haben, für die keine Index-Scans existieren, hängen sie wie Ballast fest. Und wir müssen sie loswerden. Dafür benötigen wir das Feld idx_scan. Wir schauen uns einfach die Anzahl der Index-Scans an. Wenn Indizes in einem relativ langen Zeitraum der Speicherung der Statistiken (mindestens 2-3 Wochen) null Scans aufweisen, handelt es sich höchstwahrscheinlich um schlechte Indizes, von denen wir uns trennen müssen.

Hinweis: Bei der Suche nach ungenutzten Indizes im Falle von Streaming-Replikations-Clustern müssen alle Knoten des Clusters überprüft werden, da die Statistiken nicht global sind, und wenn ein Index auf dem Master nicht verwendet wird, kann er auf den Replikaten (wenn dort eine Belastung besteht) verwendet werden.

Zwei Links:

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

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

Das sind fortgeschrittenere Beispiele für Abfragen, wie man ungenutzte Indizes sucht.

Der zweite Link ist eine ziemlich interessante Anfrage. Dort ist eine sehr untriviale Logik hinterlegt. Ich empfehle ihn zur Kenntnisnahme.

Was gibt es noch zu den Indizes zusammenzufassen?

Nicht verwendete Indizes sind schlecht.
Sie nehmen Platz weg.
Sie verlangsamen Aktualisierungsoperationen.
Zusätzliche Arbeit für den Vakuum-Manager.

Wenn wir die nicht verwendeten Indizes löschen, verbessern wir die Datenbank nur.

Die nächste Darstellung ist pg_stat_activity. Dies ist ein Äquivalent zu dem Dienstprogramm ps, nur in PostgreSQL. Wenn psSie‘ im Betriebssystem Prozesse betrachten, dann pg_stat_activity zeigt es Ihnen die Aktivität innerhalb von PostgreSQL.

Was können wir dort Nützliches entnehmen?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

Wir können die allgemeine Aktivität sehen, was in der Datenbank passiert. Wir können ein neues Deployment durchführen. Dort hat alles gesprengt, neue Verbindungen werden nicht angenommen, Fehler fließen in die Anwendung.

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

Wir können eine solche Anfrage durchführen und den Gesamtprozentsatz der Verbindungen im Verhältnis zur maximalen Verbindungsgrenze sehen und beobachten, wer die meisten Verbindungen hat. In diesem speziellen Fall sehen wir, dass der Benutzer cron_role 508 Verbindungen geöffnet hat. Irgendetwas ist dort passiert. Wir müssen mit ihm klären und nachsehen. Es ist durchaus möglich, dass dies eine anormale Anzahl von Verbindungen ist.

Wenn wir eine OLTP-Last haben, sollten die Anfragen schnell, sehr schnell ausgeführt werden, und es dürfen keine langen Anfragen vorhanden sein. Wenn jedoch lange Anfragen auftreten, ist das kurzfristig nicht schlimm, aber langfristig schädigen lange Anfragen die Datenbank, da sie den Bloat-Effekt von Tabellen erhöhen, was zu einer Fragmentierung der Tabellen führt. Sowohl vom Bloat als auch von den langen Anfragen sollten wir uns befreien.

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

Bitte beachten Sie: Mit dieser Anfrage können wir lange Anfragen und Transaktionen identifizieren. Wir verwenden die Funktion clock_timestamp() um die Arbeitszeit zu bestimmen. Lange Anfragen, die wir gefunden haben, können wir uns merken, sie ausführen explain, die Pläne ansehen und eventuell optimieren. Die aktuellen langen Anfragen schießen wir ab und leben weiter.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Schlechte Transaktionen sind Transaktionen im Zustand idle in transaction und idle in transaction (aborted).

Was bedeutet das? Transaktionen haben mehrere Zustände. Und einer dieser Zustände kann jederzeit angenommen werden. Zur Bestimmung der Zustände gibt es ein Feld state in dieser Ansicht. Und wir verwenden es zur Bestimmung des Zustands.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Und wie ich bereits erwähnt habe, sind diese beiden Zustände idle in transaction und idle in transaction (aborted) – das ist schlecht. Was bedeutet das? Das ist der Fall, wenn die Anwendung eine Transaktion eröffnet hat, einige Aktionen durchgeführt hat und dann ihren eigenen Dingen nachgeht. Die Transaktion bleibt offen. Sie hängt, es passiert nichts, sie belegt die Verbindung, Sperren auf geänderte Zeilen und erhöht potenziell auch den Bloat anderer Tabellen aufgrund der Architektur der Transaktions-Engine von PostgreSQL. Solche Transaktionen sollten ebenfalls beendet werden, da sie unter allen Umständen schädlich sind.

Wenn Sie sehen, dass Sie mehr als 5-10-20 davon in Ihrer Datenbank haben, sollten Sie sich bereits Sorgen machen und beginnen, etwas dagegen zu unternehmen.

Hier verwenden wir auch zur Berechnung der Zeit clock_timestamp(). Wir beenden Transaktionen, optimieren die Anwendung.

Wie ich bereits oben erwähnt habe, sind Sperren der Fall, wenn zwei oder mehr Transaktionen um eine oder eine Gruppe von Ressourcen kämpfen. Dafür haben wir das Feld waiting mit einem Booleschen Wert true oder false.

True – das bedeutet, dass der Prozess wartet, es muss etwas unternommen werden. Wenn der Prozess wartet, bedeutet das, dass der Client, der diesen Prozess initiiert hat, ebenfalls wartet. Der Client im Browser sitzt und wartet ebenfalls.

Achtung: _Seit der Version Postgres 9.6 wurde das Feld waiting entfernt und stattdessen wurden zwei informativere Felder hinzugefügt wait_event_type und wait_event._

Was tun? Wenn Sie true über längere Zeit sehen, dann sollten solche Anfragen eliminiert werden. Wir beenden einfach solche Transaktionen. Wir schreiben an die Entwickler, dass sie irgendwie optimieren müssen, um keine Ressourcenkonflikte zu verursachen. Und dann optimisieren die Entwickler die Anwendung, sodass das nicht mehr vorkommt.

Und der letzte, aber potenziell nicht fatale Fall ist das Auftreten von Deadlocks. Zwei Transaktionen haben zwei Ressourcen aktualisiert, dann greifen sie erneut auf sie zu, jedoch auf die entgegengesetzten Ressourcen. PostgreSQL beendet in diesem Fall selbst die eine Transaktion, damit die andere weiterarbeiten kann. Dies ist eine Sackgasse, die sich nicht selbst löst. Daher ist PostgreSQL gezwungen, drastische Maßnahmen zu ergreifen.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

Und hier sind zwei Abfragen, die es ermöglichen, Sperren zu verfolgen. Wir verwenden die Ansicht pg_locks, die es ermöglicht, schwergewichtige Sperren nachverfolgen.

Und der erste Link ist der eigentliche Text der Anfrage. Er ist ziemlich lang.

Und der zweite Link ist ein Artikel über Locks. Es ist nützlich, ihn zu lesen; er ist sehr interessant.

Also, was sehen wir? Wir sehen zwei Anfragen. Eine Transaktion mit ALTER TABLE – das ist eine blockierende Transaktion. Sie wurde gestartet, aber nicht abgeschlossen, und die Anwendung, die diese Transaktion ausgelöst hat, beschäftigt sich irgendwo anders mit anderen Dingen. Und die zweite Anfrage ist ein Update. Sie wartet, bis das Alter Table abgeschlossen ist, um mit ihrer Arbeit fortzufahren.

So können wir herausfinden, wer wen gesperrt hat, festhält und können damit weiterarbeiten.

Das nächste Modul ist pg_stat_statements. Wie ich schon sagte, das ist ein Modul. Um es zu nutzen, müssen wir seine Bibliothek in der Konfiguration laden, PostgreSQL neu starten, das Modul installieren (mit einem Befehl) und dann haben wir eine neue Ansicht.

Durchschnittliche Anfragezeit in Millisekunden
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Aktivste schreibende (in shared_buffers) Anfragen
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

Was können wir daraus entnehmen? Wenn wir über einfache Sachen sprechen, können wir die durchschnittliche Ausführungszeit der Anfrage nehmen. Wenn die Zeit steigt, bedeutet das, dass PostgreSQL langsam reagiert und wir etwas unternehmen müssen.

Wir können die aktivsten schreibenden Transaktionen in der Datenbank ansehen, die Daten in den Shared Buffers verändern. Wir können sehen, wer dort Daten aktualisiert oder löscht.

Und wir können einfach verschiedene Statistiken zu diesen Anfragen anschauen.

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

Wir pg_stat_statements verwendet zur Erstellung von Berichten. Einmal täglich setzen wir die Statistik zurück. Wir sammeln sie. Vor dem nächsten Statistikreset erstellen wir einen Bericht. Hier ist der Link zum Bericht. Sie können ihn sich ansehen.

Was machen wir? Wir zählen die gesamte Statistik für alle Anfragen. Dann berechnen wir für jede Anfrage ihren individuellen Beitrag zu dieser Gesamtheit.

Und was können wir uns ansehen? Wir können die gesamte Ausführungszeit aller Anfragen eines bestimmten Typs im Vergleich zu allen anderen Anfragen betrachten. Wir können die Ressourcennutzung von CPU und I/O im Verhältnis zum Gesamtbild sehen. Und dann diese Anfragen optimieren. Wir erstellen eine Top-Liste der Anfragen basierend auf diesem Bericht und erhalten bereits Denkanstöße, was optimiert werden kann.

Was ist hinter den Kulissen geblieben? Es gibt noch einige Präsentationen, die ich nicht berücksichtigt habe, da die Zeit begrenzt ist.

Ja pgstattuple – das ist auch ein zusätzliches Modul aus dem Standardpaket contribs. Es ermöglicht die Bewertung bloat von Tabellen, d. h. der Fragmentierung der Tabellen. Und wenn die Fragmentierung groß ist, muss sie beseitigt werden, es sollten verschiedene Werkzeuge verwendet werden. Und die Funktion pgstattuple arbeitet lange. Und je mehr Tabellen vorhanden sind, desto länger wird sie arbeiten.

Das nächste contrib ist pg_buffercache. Es ermöglicht die Inspektion der Shared Buffers: wie intensiv und für welche Tabellen die Seiten des Buffers genutzt werden. Es ermöglicht einfach einen Blick in die Shared Buffers und eine Bewertung der dort ablaufenden Vorgänge.

Das nächste Modul ist pgfincore. Es ermöglicht niederlevelige Operationen mit Tabellen über den Systemaufruf mincore(), d. h. es erlaubt, eine Tabelle in die Shared Buffers zu laden oder sie herauszuladen. Außerdem ermöglicht es die Inspektion des Seiten-Cache des Betriebssystems, d. h. in welchem Umfang unsere Tabelle im Page Cache, in den Shared Buffers belegt ist und einfach zu bewerten, wie stark die Tabelle ausgelastet ist.

Das nächste Modul ist pg_stat_kcache. Es verwendet ebenfalls den Systemaufruf getrusage(). Und führt ihn vor und nach der Ausführung einer Abfrage aus. In den erhaltenen Statistiken ermöglicht es die Einschätzung, wie viel unsere Abfrage für die Durchführung von E/A-Vorgängen auf der Festplatte, d. h. für Operationen mit dem Dateisystem, benötigt hat und untersucht die CPU-Nutzung. Allerdings ist das Modul neu (hust-hust) und für seine Funktion benötigt es PostgreSQL 9.4 und pg_stat_statements, über das ich zuvor gesprochen habe.

Die Fähigkeit, mit Statistiken umzugehen, ist nützlich. Sie benötigen keine externen Programme. Sie können selbst einen Blick werfen, schauen, etwas tun, ausführen.
Die Nutzung von Statistiken ist nicht kompliziert, es ist normales SQL. Sie haben eine Abfrage erstellt, formuliert, gesendet, angesehen.
Statistiken helfen, Fragen zu beantworten. Wenn Fragen aufkommen, wenden Sie sich an die Statistiken – schauen Sie, ziehen Sie Schlussfolgerungen, analysieren Sie die Ergebnisse.
Und experimentieren Sie. Es gibt viele Abfragen, viele Daten. Man kann immer eine bereits bestehende Abfrage optimieren. Man kann seine eigene Version einer Abfrage erstellen, die besser zu einem passt als das Original und diese nutzen.