🥇Tiefer Einblick in die internen Statistiken von PostgreSQL. Alexey Lesovsky

Transkription des Berichts 2015 von Alexey Lesovsky „Deep Dive into PostgreSQL Internal Statistics“

Haftungsausschluss des Autors des Berichts: Ich stelle fest, dass dieser Bericht vom November 2015 stammt – mehr als 4 Jahre sind vergangen und es ist viel Zeit vergangen. Die im Bericht besprochene Version 9.4 wird nicht mehr unterstützt. In den letzten 4 Jahren wurden 5 Neuerscheinungen veröffentlicht, in denen viele Neuerungen, Verbesserungen und Änderungen in Bezug auf Statistiken erschienen sind und einige der Materialien veraltet und nicht relevant sind. Bei der Durchsicht habe ich versucht, diese Orte zu markieren, um Sie als Leser nicht in die Irre zu führen. Ich habe diese Orte nicht umgeschrieben, es gibt viele davon, und als Ergebnis wird ein völlig anderer Bericht herauskommen.

Das PostgreSQL-DBMS ist ein riesiger Mechanismus, und dieser Mechanismus besteht aus vielen Subsystemen, deren koordinierte Arbeit sich direkt auf die Leistung des DBMS auswirkt. Während des Betriebs werden Statistiken und Informationen über den Betrieb von Komponenten gesammelt, die es Ihnen ermöglichen, die Wirksamkeit von PostgreSQL zu bewerten und Maßnahmen zur Leistungsverbesserung zu ergreifen. Es gibt jedoch viele dieser Informationen und sie werden in einer eher vereinfachten Form dargestellt. Die Verarbeitung und Interpretation dieser Informationen ist manchmal keine triviale Aufgabe, und der „Zoo“ an Tools und Dienstprogrammen kann selbst einen fortgeschrittenen DBA leicht verwirren.

Guten Tag! Mein Name ist Alexey. Wie Ilya sagte, werde ich über PostgreSQL-Statistiken sprechen.

PostgreSQL-Aktivitätsstatistiken. PostgreSQL verfügt über zwei Statistiken. Aktivitätsstatistiken, die besprochen werden. Und Scheduler-Statistiken zur Datenverteilung. Ich werde speziell über PostgreSQL-Aktivitätsstatistiken sprechen, die es uns ermöglichen, die Leistung zu beurteilen und sie irgendwie zu verbessern.

Ich werde Ihnen sagen, wie Sie Statistiken effektiv nutzen können, um eine Vielzahl von Problemen zu lösen, die Sie haben oder haben könnten.

Was wird nicht im Bericht enthalten sein? Im Bericht werde ich nicht auf die Statistiken des Planers eingehen, weil. Dies ist ein separates Thema für einen separaten Bericht darüber, wie Daten in der Datenbank gespeichert werden und wie der Abfrageplaner eine Vorstellung von den qualitativen und quantitativen Merkmalen dieser Daten erhält.

Und es wird keine Tool-Bewertungen geben, ich werde kein Produkt mit einem anderen vergleichen. Es wird keine Werbung geben. Lassen wir es fallen.

Ich möchte Ihnen zeigen, dass die Verwendung von Statistiken nützlich ist. Es ist notwendig. Benutzen Sie es furchtlos. Wir benötigen lediglich einfaches SQL und Grundkenntnisse in SQL.

Und wir werden darüber sprechen, welche Statistiken wir zur Lösung von Problemen wählen sollten.

Wenn wir uns PostgreSQL ansehen und einen Befehl auf dem Betriebssystem ausführen, um die Prozesse anzuzeigen, sehen wir eine „Black Box“. Wir werden einige Prozesse sehen, die etwas tun, und anhand des Namens können wir uns ungefähr vorstellen, was sie dort tun, was sie tun. Aber in Wirklichkeit handelt es sich um eine Blackbox, in die wir nicht hineinschauen können.

Wir können uns die CPU-Auslastung ansehen top, können wir die Speicherauslastung einiger Systemdienstprogramme sehen, aber wir können keinen Blick in PostgreSQL werfen. Dafür brauchen wir andere Werkzeuge.

Und weiter unten werde ich Ihnen sagen, wo ich die Zeit verbringe. Wenn wir PostgreSQL in Form eines solchen Schemas darstellen, ist es möglich zu beantworten, wofür die Zeit aufgewendet wird. Dabei handelt es sich um zwei Dinge: Es handelt sich um die Verarbeitung von Client-Anfragen von Anwendungen und um die Hintergrundaufgaben, die PostgreSQL ausführt, um es am Laufen zu halten.

Wenn wir in die obere linke Ecke schauen, können wir sehen, wie Kundenanfragen verarbeitet werden. Die Anfrage kommt von der Anwendung und eine Client-Sitzung wird für weitere Arbeiten geöffnet. Die Anfrage wird an den Scheduler weitergeleitet. Der Planer erstellt einen Abfrageplan. Sendet es zur Ausführung weiter. Es gibt eine Art Block-E/A-Daten, die Tabellen und Indizes zugeordnet sind. Die erforderlichen Daten werden in einem speziellen Bereich namens „gemeinsam genutzte Puffer“ von den Festplatten in den Speicher eingelesen. Die Abfrageergebnisse werden, sofern es sich um Aktualisierungen oder Löschungen handelt, im Transaktionsprotokoll in WAL aufgezeichnet. Einige statistische Informationen werden im Protokoll oder Statistiksammler gespeichert. Und das Ergebnis der Anfrage wird an den Kunden zurückgegeben. Danach kann der Kunde alles mit einer neuen Anfrage wiederholen.

Was haben wir mit Hintergrundaufgaben und Hintergrundprozessen? Wir haben mehrere Prozesse, die dafür sorgen, dass die Datenbank normal läuft und läuft. Diese Prozesse werden ebenfalls im Bericht behandelt: Dies sind Autovacuum, Checkpointer, replikationsbezogene Prozesse und Hintergrundschreiber. Ich werde auf jeden einzelnen von ihnen eingehen, während ich berichte.

Was sind die Probleme mit Statistiken?

Viele Informationen. PostgreSQL 9.4 bietet 109 Metriken zum Anzeigen von Statistikdaten. Wenn die Datenbank jedoch viele Tabellen, Schemata und Datenbanken speichert, müssen alle diese Metriken mit der entsprechenden Anzahl von Tabellen und Datenbanken multipliziert werden. Das heißt, es gibt noch mehr Informationen. Und es ist sehr leicht, darin zu ertrinken.
Das nächste Problem besteht darin, dass Statistiken durch Zähler dargestellt werden. Wenn wir uns diese Statistiken ansehen, werden wir ständig steigende Zähler sehen. Und wenn seit dem Zurücksetzen der Statistiken viel Zeit vergangen ist, werden wir Milliarden von Werten sehen. Und sie sagen uns nichts.
Es gibt keine Geschichte. Wenn bei Ihnen ein Fehler auftritt, beispielsweise etwas, das vor 15 bis 30 Minuten heruntergefallen ist, können Sie die Statistiken nicht verwenden und sehen, was vor 15 bis 30 Minuten passiert ist. Das ist ein Problem.
Das Fehlen eines in PostgreSQL integrierten Tools ist ein Problem. Die Kernel-Entwickler stellen kein Dienstprogramm zur Verfügung. So etwas haben sie nicht. Sie geben lediglich Statistiken in der Datenbank ab. Benutzen Sie es, stellen Sie eine Anfrage, was auch immer Sie wollen, und dann tun Sie es.
Da in PostgreSQL kein Tool integriert ist, verursacht dies ein weiteres Problem. Viele Tools von Drittanbietern. Jedes Unternehmen, das mehr oder weniger direkte Hände hat, versucht, sein eigenes Programm zu schreiben. Daher verfügt die Community über zahlreiche Tools, mit denen Sie mit Statistiken arbeiten können. Und in einigen Tools gibt es einige Funktionen, in anderen Tools gibt es keine anderen Funktionen oder es gibt einige neue Funktionen. Und es entsteht die Situation, dass Sie zwei, drei oder vier Werkzeuge verwenden müssen, die sich überschneiden und unterschiedliche Funktionen haben. Das ist sehr ärgerlich.

Was folgt daraus? Es ist wichtig, Statistiken direkt erfassen zu können, um nicht auf Programme angewiesen zu sein oder diese Programme irgendwie selbst zu verbessern: Fügen Sie einige Funktionen hinzu, um Ihren Nutzen zu erzielen.

Und Sie benötigen Grundkenntnisse in SQL. Um einige Daten aus Statistiken zu erhalten, müssen Sie SQL-Abfragen durchführen, d. h. Sie müssen wissen, wie Auswahl und Verknüpfung erfolgen.

Statistiken sagen uns mehrere Dinge. Sie können in Kategorien unterteilt werden.

Die erste Kategorie sind die Ereignisse, die in der Datenbank stattfinden. Dies ist der Fall, wenn ein Ereignis in der Datenbank auftritt: eine Abfrage, ein Tabellenzugriff, Autovacuum, Commits, dann sind dies alles Ereignisse. Die diesen Ereignissen entsprechenden Zähler werden inkrementiert. Und wir können diese Ereignisse verfolgen.
Die zweite Kategorie sind die Eigenschaften von Objekten wie Tabellen, Datenbanken. Sie haben Eigenschaften. Dies ist die Größe der Tabellen. Wir können das Wachstum von Tabellen und Indizes verfolgen. Wir können Veränderungen in der Dynamik beobachten.
Und die dritte Kategorie ist die für die Veranstaltung aufgewendete Zeit. Anfrage ist ein Ereignis. Es hat sein eigenes spezifisches Maß für die Dauer. Hier begann es, hier endete es. Wir können es verfolgen. Entweder der Zeitpunkt des Lesens eines Blocks von der Festplatte oder des Schreibens. Auch diese Dinge werden verfolgt.

Die statistischen Quellen werden wie folgt dargestellt:

Im gemeinsam genutzten Speicher (gemeinsam genutzte Puffer) gibt es ein Segment zum Platzieren statischer Daten. Es gibt auch Zähler, die ständig erhöht werden, wenn bestimmte Ereignisse auftreten oder bestimmte Momente im Betrieb der Datenbank auftreten.
Alle diese Zähler stehen dem Benutzer nicht zur Verfügung und stehen nicht einmal dem Administrator zur Verfügung. Das sind Dinge auf niedrigem Niveau. Um darauf zuzugreifen, stellt PostgreSQL eine Schnittstelle in Form von SQL-Funktionen zur Verfügung. Mit diesen Funktionen können wir ausgewählte Auswahlen treffen und eine Art Metrik (oder einen Satz von Metriken) erhalten.
Allerdings ist die Verwendung dieser Funktionen nicht immer bequem, daher bilden Funktionen die Grundlage für Ansichten (VIEWs). Hierbei handelt es sich um virtuelle Tabellen, die Statistiken zu einem bestimmten Subsystem oder zu einer Reihe von Ereignissen in der Datenbank bereitstellen.
Diese integrierten Ansichten (VIEWs) sind die Hauptbenutzeroberfläche für die Arbeit mit Statistiken. Sie sind standardmäßig ohne zusätzliche Einstellungen verfügbar, Sie können sie sofort verwenden, ansehen und Informationen von dort abrufen. Und es gibt auch Beiträge. Beiträge sind offiziell. Sie können das Paket postgresql-contrib installieren (z. B. postgresql94-contrib), das erforderliche Modul in die Konfiguration laden, Parameter dafür angeben, PostgreSQL neu starten und es verwenden. (Notiz. Abhängig von der Distribution ist das Paket in neueren Versionen von contrib Teil des Hauptpakets).
Und es gibt inoffizielle Beiträge. Sie werden nicht mit der Standard-PostgreSQL-Distribution geliefert. Sie müssen entweder kompiliert oder als Bibliothek installiert werden. Die Optionen können sehr unterschiedlich sein, je nachdem, was sich der Entwickler dieses inoffiziellen Beitrags ausgedacht hat.

Diese Folie zeigt alle Ansichten (VIEWs) und einige dieser Funktionen, die in PostgreSQL 9.4 verfügbar sind. Wie wir sehen, gibt es viele davon. Und es ist ziemlich leicht, verwirrt zu werden, wenn man es zum ersten Mal erlebt.

Wenn wir jedoch das vorherige Bild machen Как тратится время на PostgreSQL und kompatibel mit dieser Liste, erhalten wir dieses Bild. Jede Ansicht (VIEWs) oder jede Funktion können wir für den einen oder anderen Zweck verwenden, um die entsprechenden Statistiken zu erhalten, wenn PostgreSQL ausgeführt wird. Und wir können bereits einige Informationen über die Funktionsweise des Subsystems erhalten.

Das erste, was wir uns ansehen werden, ist pg_stat_database. Wie wir sehen, handelt es sich hierbei um eine Darstellung. Es enthält viele Informationen. Die vielfältigsten Informationen. Und es liefert sehr nützliche Erkenntnisse darüber, was in der Datenbank vor sich geht.

Was können wir daraus mitnehmen? Beginnen wir mit den einfachsten Dingen.

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 Prozentsatz der Cache-Treffer. Der Cache-Treffer-Prozentsatz ist eine nützliche Kennzahl. Damit können Sie abschätzen, wie viele Daten aus dem gemeinsam genutzten Puffercache entnommen und wie viele von der Festplatte gelesen werden.

Es ist klar, dass Je mehr Cache-Treffer wir haben, desto besser. Wir bewerten diese Kennzahl als Prozentsatz. Und wenn wir beispielsweise einen Prozentsatz dieser Cache-Treffer von mehr als 90 % haben, dann ist das gut. Wenn er unter 90 % fällt, dann haben wir nicht genug Speicher, um den heißen Datenkopf im Speicher zu halten. Und um diese Daten nutzen zu können, ist PostgreSQL gezwungen, auf die Festplatte zuzugreifen, und das ist langsamer, als wenn die Daten aus dem Speicher gelesen würden. Und Sie müssen darüber nachdenken, den Speicher zu vergrößern: entweder die gemeinsam genutzten Puffer erhöhen oder den Eisenspeicher (RAM) erhöhen.

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 aus dieser Aufführung noch mitnehmen? Sie können die in der Datenbank auftretenden Anomalien sehen. Was wird hier gezeigt? Es gibt Commits, Rollbacks, die Erstellung temporärer Dateien, deren Größe, Deadlocks und Konflikte.

Wir können diese Anfrage nutzen. Dieses SQL ist ziemlich einfach. Und wir können diese Daten selbst sehen.

Und hier sind die Schwellenwerte. Wir betrachten das Verhältnis von Commits und Rollbacks. Commits sind eine erfolgreiche Bestätigung der Transaktion. Rollbacks sind Rollbacks, d. h. die Transaktion hat etwas Arbeit geleistet, die Datenbank belastet, etwas überlegt, und dann ist ein Fehler aufgetreten und die Ergebnisse der Transaktion werden verworfen. d.h. Schlimm ist, dass die Zahl der Rollbacks ständig steigt. Und Sie sollten sie irgendwie vermeiden und den Code so bearbeiten, dass dies nicht passiert.

Konflikte hängen mit der Replikation zusammen. Und sie sollten auch vermieden werden. Wenn auf dem Replikat einige Abfragen ausgeführt werden und Konflikte auftreten, müssen Sie diese Konflikte analysieren und sehen, was passiert. Einzelheiten finden Sie in den Protokollen. Und Konflikte lösen, damit Anwendungsanfragen fehlerfrei funktionieren.

Deadlocks sind ebenfalls eine schlechte Situation. Wenn Anforderungen um Ressourcen konkurrieren, hat eine Anforderung auf eine Ressource zugegriffen und die Sperre übernommen, die zweite Anforderung hat auf die zweite Ressource zugegriffen und ebenfalls die Sperre übernommen, und dann haben beide Anforderungen auf die Ressourcen der jeweils anderen zugegriffen und blockiert, während sie darauf gewartet haben, dass der Nachbar die Sperre aufhebt. Auch das ist eine problematische Situation. Sie müssen auf der Ebene des Neuschreibens von Anwendungen und der Serialisierung des Zugriffs auf Ressourcen angegangen werden. Und wenn Sie feststellen, dass Ihre Deadlocks ständig zunehmen, müssen Sie sich die Details in den Protokollen ansehen, die aufgetretenen Situationen analysieren und herausfinden, wo das Problem liegt.

Temporäre Dateien (temp_files) sind ebenfalls fehlerhaft. Wenn eine Benutzeranforderung nicht über genügend Speicher für die temporären Betriebsdaten verfügt, wird eine Datei auf der Festplatte erstellt. Und alle Operationen, die er in einem temporären Puffer im Speicher ausführen könnte, beginnt er bereits auf der Festplatte auszuführen. Es ist langsam. Dadurch erhöht sich die Ausführungszeit der Abfrage. Und der Client, der eine Anfrage an PostgreSQL gesendet hat, erhält wenig später eine Antwort. Wenn alle diese Vorgänge im Speicher ausgeführt werden, reagiert Postgres viel schneller und der Client muss weniger warten.

pg_stat_bgwriter – Diese Ansicht beschreibt den Betrieb von zwei PostgreSQL-Hintergrundsubsystemen: checkpointer и background writer.

Lassen Sie uns zunächst die Kontrollpunkte analysieren, die sogenannten. checkpoints. Was sind Kontrollpunkte? Ein Prüfpunkt ist eine Position im Transaktionsprotokoll, die angibt, dass alle im Protokoll festgeschriebenen Datenänderungen erfolgreich mit den Daten auf der Festplatte synchronisiert wurden. Der Prozess kann je nach Arbeitslast und Einstellungen langwierig sein und besteht hauptsächlich aus der Synchronisierung schmutziger Seiten in gemeinsam genutzten Puffern mit Datendateien auf der Festplatte. Wofür ist das? Wenn PostgreSQL ständig auf die Festplatte zugreifen und Daten von dort abrufen und bei jedem Zugriff Daten schreiben würde, wäre es langsam. Daher verfügt PostgreSQL über ein Speichersegment, dessen Größe von den Parametern in der Konfiguration abhängt. Postgres reserviert Betriebsdaten in diesem Speicher zur weiteren Verarbeitung oder Abfrage. Bei Datenänderungswünschen werden diese geändert. Und wir erhalten zwei Versionen der Daten. Einer befindet sich im Speicher, der andere auf der Festplatte. Und regelmäßig müssen Sie diese Daten synchronisieren. Wir benötigen, was im Speicher geändert wird, um mit der Festplatte synchronisiert zu werden. Dies erfordert Kontrollpunkte.

Checkpoint durchsucht gemeinsam genutzte Puffer und markiert fehlerhafte Seiten, die für den Checkpoint benötigt werden. Dann beginnt der zweite Durchlauf durch gemeinsam genutzte Puffer. Und die Seiten, die für den Checkpoint markiert sind, synchronisiert er bereits. Somit sind die Daten bereits mit der Festplatte synchronisiert.

Es gibt zwei Arten von Kontrollpunkten. Bei Zeitüberschreitung wird ein Prüfpunkt ausgeführt. Dieser Kontrollpunkt ist nützlich und gut - checkpoint_timed. Und es gibt Kontrollpunkte auf Abruf - checkpoint required. Ein solcher Prüfpunkt tritt auf, wenn wir einen sehr großen Datensatz haben. Wir haben viele Transaktionsprotokolle aufgezeichnet. Und PostgreSQL glaubt, dass es das alles so schnell wie möglich synchronisieren, einen Kontrollpunkt erstellen und weitermachen muss.

Und wenn Sie sich die Statistiken ansehen pg_stat_bgwriter und schau, was du hast Wenn checkpoint_req viel größer als checkpoint_timed ist, ist das schlecht. Warum schlecht? Das bedeutet, dass PostgreSQL ständigem Stress ausgesetzt ist, wenn es Daten auf die Festplatte schreiben muss. Checkpoint by Timeout ist weniger stressig und wird nach dem internen Zeitplan und sozusagen über die Zeit gestreckt ausgeführt. PostgreSQL bietet die Möglichkeit, die Arbeit zu unterbrechen, ohne das Festplattensubsystem zu belasten. Dies ist nützlich für PostgreSQL. Und Anfragen, die während des Checkpoints ausgeführt werden, werden nicht durch die Tatsache belastet, dass das Festplattensubsystem ausgelastet ist.

Und es gibt drei Parameter zum Anpassen des Prüfpunkts:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

Sie ermöglichen Ihnen, den Betrieb von Kontrollpunkten zu steuern. Aber ich werde nicht weiter darauf eingehen. Ihr Einfluss ist ein separates Thema.

Hinweis: Die im Bericht berücksichtigte Version 9.4 ist nicht mehr relevant. In modernen Versionen von PostgreSQL ist der Parameter checkpoint_segments durch Parameter ersetzt min_wal_size и max_wal_size.

Das nächste Subsystem ist der Hintergrundwriter − background writer. Was macht er? Es läuft ständig in einer Endlosschleife. Es scannt Seiten in gemeinsam genutzte Puffer und schreibt die gefundenen fehlerhaften Seiten auf die Festplatte. Auf diese Weise hilft es dem Checkpointer, beim Checkpointing weniger Arbeit zu leisten.

Wofür wird er sonst noch benötigt? Es sieht die Notwendigkeit sauberer Seiten in gemeinsam genutzten Puffern vor, wenn diese plötzlich (in großen Mengen und sofort) zur Aufnahme von Daten benötigt werden. Angenommen, eine Situation ist aufgetreten, in der die Anforderung saubere Seiten erfordert und diese sich bereits in gemeinsam genutzten Puffern befinden. Postgres backend Er nimmt sie einfach und benutzt sie, er muss nichts selbst reinigen. Wenn aber plötzlich keine solchen Seiten mehr vorhanden sind, pausiert das Backend und beginnt mit der Suche nach Seiten, um sie auf die Festplatte zu leeren und für den eigenen Bedarf zu nutzen – was sich negativ auf die Zeit der aktuell ausgeführten Anfrage auswirkt. Wenn Sie sehen, dass Sie einen Parameter haben maxwritten_clean Wenn der Wert zu groß ist, bedeutet dies, dass der Hintergrundschreiber seine Aufgabe nicht erfüllt und Sie die Parameter erhöhen müssen bgwriter_lru_maxpagesDamit er in einem Zyklus mehr Arbeit erledigen und mehr Seiten löschen kann.

Und ein weiterer sehr nützlicher Indikator ist buffers_backend_fsync. Backends führen Fsync nicht aus, weil es langsam ist. Sie übergeben fsync den E/A-Stack-Checkpointer. Der Checkpointer verfügt über eine eigene Warteschlange, verarbeitet regelmäßig fsync und synchronisiert Seiten im Speicher mit Dateien auf der Festplatte. Wenn die Checkpointer-Warteschlange groß und voll ist, ist das Backend gezwungen, fsync selbst auszuführen, was das Backend verlangsamt, d. h. der Client erhält eine Antwort später als er könnte. Wenn Sie sehen, dass dieser Wert größer als Null ist, dann ist dies bereits ein Problem und Sie müssen auf die Einstellungen des Hintergrundschreibers achten und auch die Leistung des Festplattensubsystems bewerten.

Hinweis: _Der folgende Text beschreibt die mit der Replikation verbundenen statistischen Ansichten. Die meisten Ansichts- und Funktionsnamen wurden in Postgres 10 umbenannt. Der Kern der Umbenennungen bestand darin, sie zu ersetzen xlog auf wal и location auf lsn in Funktions-/Ansichtsnamen usw. Besonderes Beispiel, Funktion pg_xlog_location_diff() wurde umbenannt in pg_wal_lsn_diff()._

Wir haben hier auch viel. Wir benötigen jedoch nur standortbezogene Elemente.

Wenn wir sehen, dass alle Werte gleich sind, dann ist dies ideal und das Replikat hinkt dem Master nicht hinterher.

Diese hexadezimale Position ist hier die Position im Transaktionsprotokoll. Sie erhöht sich ständig, wenn in der Datenbank eine Aktivität stattfindet: Einfügungen, Löschungen usw.

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

Wenn diese Dinge unterschiedlich sind, gibt es eine Art Verzögerung. Verzögerung ist die Verzögerung des Replikats gegenüber dem Master, d. h. die Daten unterscheiden sich zwischen den Servern.

Für die Verzögerung gibt es drei Gründe:

Es ist das Festplattensubsystem, das Dateisynchronisierungsschreibvorgänge nicht verarbeiten kann.
Hierbei handelt es sich um mögliche Netzwerkfehler oder Netzwerküberlastungen, wenn die Daten keine Zeit haben, das Replikat zu erreichen und diese nicht reproduzieren können.
Und der Prozessor. Der Prozessor ist ein sehr seltenes Gehäuse. Und das habe ich zwei-, dreimal gesehen, aber das kann auch passieren.

Und hier sind drei Abfragen, die es uns ermöglichen, Statistiken zu verwenden. Wir können abschätzen, wie viel in unserem Transaktionsprotokoll aufgezeichnet wird. Es gibt eine solche Funktion pg_xlog_location_diff und wir können die Replikationsverzögerung in Bytes und Sekunden schätzen. Auch hierfür verwenden wir den Wert aus dieser Ansicht (VIEWs).

Hinweis: _Statt pg_xlog_locationMit der diff()-Funktion können Sie den Subtraktionsoperator verwenden und einen Ort von einem anderen subtrahieren. Komfortabel.

Bei einer Verzögerung, die in Sekunden liegt, gibt es einen Moment. Wenn auf dem Master keine Aktivität stattfindet, war die Transaktion vor etwa 15 Minuten dort und es gibt keine Aktivität. Wenn wir uns diese Verzögerung auf dem Replikat ansehen, sehen wir eine Verzögerung von 15 Minuten. Das ist eine Erinnerung wert. Und es kann zu einer Benommenheit führen, wenn man diese Verzögerung sieht.

pg_stat_all_tables ist eine weitere nützliche Ansicht. Es zeigt Statistiken zu Tabellen an. Wenn wir Tabellen in der Datenbank haben, gibt es eine gewisse Aktivität, einige Aktionen, wir können 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 ansehen können, sind sequentielle Tabellenscans. Die Zahl selbst nach diesen Passagen ist nicht unbedingt schlecht und weist nicht darauf hin, dass wir bereits etwas tun müssen.

Es gibt jedoch eine zweite Metrik – seq_tup_read. Dies ist die Anzahl der vom sequentiellen Scan zurückgegebenen Zeilen. Wenn die durchschnittliche Anzahl 1, 000, 10, 000 überschreitet, ist dies bereits ein Indikator dafür, dass Sie möglicherweise irgendwo einen Index erstellen müssen, damit die Zugriffe nach Index erfolgen, oder dass Abfragen, die solche sequentiellen Scans verwenden, so optimiert werden können das passiert nicht. war.

Ein einfaches Beispiel: Nehmen wir an, eine Anfrage mit einem großen OFFSET und LIMIT lohnt sich. Beispielsweise werden 100 Zeilen in einer Tabelle gescannt und danach 000 erforderliche Zeilen entnommen und die zuvor gescannten Zeilen verworfen. Auch das ist ein schlimmer Fall. Und solche Anfragen müssen optimiert werden. Und hier ist so eine einfache SQL-Abfrage, auf der Sie die erhaltenen Zahlen sehen und auswerten können.

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;

Über diese Tabelle und zusätzliche Funktionen können auch Tabellengrößen ermittelt werden pg_total_relation_size(), pg_relation_size().

Im Allgemeinen gibt es Metabefehle dt и di, das Sie in PSQL verwenden und auch Tabellen- und Indexgrößen anzeigen können.

Die Verwendung von Funktionen hilft uns jedoch, die Größen von Tabellen zu betrachten, auch unter Berücksichtigung von Indizes oder ohne Berücksichtigung von Indizes, und bereits einige Schätzungen basierend auf dem Wachstum der Datenbank, d. h. wie sie mit uns wächst, zu treffen welche Intensität, und ziehen Sie bereits einige Rückschlüsse auf die Größenoptimierung.

Schreibaktivität. Was ist ein Datensatz? Schauen wir uns die Operation an UPDATE – der Vorgang des Aktualisierens von Zeilen in der Tabelle. Tatsächlich besteht die Aktualisierung aus zwei Vorgängen (oder sogar mehr). Dadurch wird eine neue Zeilenversion eingefügt und die alte Zeilenversion als veraltet markiert. Später wird das Autovakuum kommen und diese veralteten Versionen der Leitungen reinigen und diesen Ort als zur Wiederverwendung verfügbar markieren.

Außerdem geht es bei der Aktualisierung nicht nur um die Aktualisierung einer Tabelle. Es handelt sich immer noch um ein Index-Update. Wenn die Tabelle viele Indizes enthält, müssen mit der Aktualisierung auch alle Indizes aktualisiert werden, an denen die in der Abfrage aktualisierten Felder beteiligt sind. Diese Indizes enthalten auch veraltete Zeilenversionen, 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 seines Designs ist UPDATE eine Schwergewichtsoperation. Aber sie können einfacher gemacht werden. Essen hot updates. Sie erschienen in PostgreSQL Version 8.3. Und was ist das? Dies ist ein leichtes Update, das nicht dazu führt, dass Indizes neu erstellt werden. Das heißt, wir haben den Datensatz aktualisiert, aber nur der Datensatz auf der Seite (der zur Tabelle gehört) wurde aktualisiert, und die Indizes verweisen immer noch auf denselben Datensatz auf der Seite. Es gibt eine so interessante Arbeitslogik: Wenn ein Vakuum entsteht, dann gibt es diese Ketten hot wird neu erstellt und alles funktioniert weiterhin, ohne dass die Indizes aktualisiert werden müssen, und alles geschieht mit weniger Ressourcenverschwendung.

Und wenn Sie es getan haben n_tup_hot_upd groß, es ist sehr gut. Das bedeutet, dass sich Lightweight-Updates durchsetzen und das ist für uns ressourcenmäßig günstiger und alles ist in Ordnung.

ALTER TABLE table_name SET (fillfactor = 70);

So erhöhen Sie die Lautstärke hot updateov? Wir können benutzen fillfactor. Es bestimmt die Größe des reservierten freien Speicherplatzes beim Füllen einer Seite in einer Tabelle mithilfe von INSERTs. Wenn Einfügungen in die Tabelle eingefügt werden, füllen sie die Seite vollständig aus und lassen keinen leeren Platz darin. Dann wird eine neue Seite hervorgehoben. Die Daten werden erneut ausgefüllt. Und das ist das Standardverhalten, Füllfaktor = 100 %.

Wir können den Füllfaktor auf 70 % einstellen. Das heißt, bei Einfügungen wurde eine neue Seite zugewiesen, aber nur 70 % der Seite wurden gefüllt. Und wir haben noch 30 % in Reserve. Wenn Sie eine Aktualisierung durchführen müssen, geschieht dies höchstwahrscheinlich auf derselben Seite und die neue Version der Zeile passt auf dieselbe Seite. Und hot_update wird durchgeführt. Dies erleichtert das Schreiben auf Tischen.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as 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
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Autovakuum-Warteschlange. Autovacuum ist ein solches Subsystem, für das es in PostgreSQL nur sehr wenige Statistiken gibt. Wir können in den Tabellen in pg_stat_activity nur sehen, wie viele Vakuum wir im Moment haben. Es ist jedoch sehr schwierig zu verstehen, wie viele Tische sich unterwegs in der Warteschlange befinden.

Hinweis: _Seit Postgres 10 hat sich die Situation bei der Verfolgung des Vakuumvakuums erheblich verbessert – die Ansicht pg_stat_progress ist erschienenVakuum, was das Problem der Autovakuumüberwachung erheblich vereinfacht.

Wir können diese vereinfachte Abfrage verwenden. Und wir können sehen, wann das Vakuum erzeugt werden sollte. Aber wie und wann soll das Vakuum beginnen? Dies sind die alten Versionen der Saiten, über die ich zuvor gesprochen habe. Es wurde eine Aktualisierung durchgeführt, die neue Version der Zeile wurde eingefügt. Es ist eine veraltete Version der Zeichenfolge aufgetaucht. Tisch pg_stat_user_tables Es gibt einen solchen Parameter n_dead_tup. Es zeigt die Anzahl der „toten“ Zeilen. Und sobald die Anzahl der toten Reihen einen bestimmten Schwellenwert überschreitet, kommt ein Autovakuum zum Einsatz.

Und wie wird dieser Schwellenwert berechnet? Dies ist ein ganz bestimmter Prozentsatz der Gesamtzahl der Zeilen in der Tabelle. Es gibt einen Parameter autovacuum_vacuum_scale_factor. Es definiert den Prozentsatz. Nehmen wir an, 10 % + es gibt einen zusätzlichen Basisschwellenwert von 50 Zeilen. Und was passiert? Wenn wir mehr tote Zeilen als „10 % + 50“ aller Zeilen in der Tabelle haben, versetzen wir die Tabelle in den automatischen Vakuummodus.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as 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
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Es gibt jedoch einen Punkt. Grundlegende Schwellenwerte für Parameter av_base_thresh и av_scale_factor können individuell vergeben werden. Und dementsprechend wird der Schwellenwert nicht global, sondern individuell für die Tabelle sein. Um dort zu berechnen, müssen Sie daher Tricks und Tricks anwenden. 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 wurde im Text aktualisiert).

Sie schrieben für Munin-Plugindas berücksichtigt diese Dinge. Auf zwei Laken liegt ein Fußtuch. Aber er denkt richtig und lässt uns ganz effektiv einschätzen, wo wir viel Vakuum für Tische brauchen, wo wenig.

Was können wir dagegen tun? Wenn wir eine lange Warteschlange haben und das Autovakuum nicht ausreicht, können wir die Anzahl der Vakuumarbeiter erhöhen oder einfach das Vakuum aggressiver machenDamit es früher auslöst, wird die Tabelle in kleinen Stücken verarbeitet. Und so wird die Warteschlange kleiner. - Hier geht es vor allem darum, die Belastung der Festplatten zu überwachen, denn. Das Vakuum-Ding ist nicht kostenlos, obwohl das Problem mit dem Aufkommen von SSD-/NVMe-Geräten weniger auffällig geworden ist.

pg_stat_all_indexes ist eine Statistik über Indizes. Sie ist nicht groß. Und wir können daraus Informationen über die Verwendung von Indizes erhalten. Und wir können zum Beispiel bestimmen, welche Indizes wir zusätzlich haben.

Wie ich schon sagte, Update aktualisiert nicht nur Tabellen, sondern auch Indizes. Wenn wir dementsprechend viele Indizes in der Tabelle haben, müssen beim Aktualisieren der Zeilen in der Tabelle auch die Indizes der indizierten Felder aktualisiert werden, und Wenn wir ungenutzte Indizes haben, für die es keine Index-Scans gibt, dann hängen sie als Ballast bei uns. Und Sie müssen sie loswerden. Dafür benötigen wir ein Feld idx_scan. Wir schauen uns nur die Anzahl der Indexscans an. Wenn die Indizes über einen relativ langen Zeitraum der Statistikspeicherung (mindestens 2–3 Wochen) keine Scans durchführen, handelt es sich höchstwahrscheinlich um fehlerhafte Indizes. Wir müssen sie entfernen.

Hinweis: Bei der Suche nach ungenutzten Indizes bei Streaming-Replikationsclustern müssen Sie alle Knoten des Clusters überprüfen, weil Statistiken sind nicht global, und wenn der Index nicht auf dem Master verwendet wird, kann er auf Replikaten verwendet werden (sofern eine Auslastung vorliegt).

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

Dies sind erweiterte Abfragebeispiele zum Nachschlagen nicht verwendeter Indizes.

Der zweite Link ist eine ziemlich interessante Abfrage. Darin liegt eine sehr nicht triviale Logik. Ich empfehle es zur Rezension.

Was sollte sonst noch durch Indizes zusammengefasst werden?

Nicht verwendete Indizes sind schlecht.
Sie nehmen Platz ein.
Verlangsamen Sie Aktualisierungsvorgänge.
Mehrarbeit für das Vakuum.

Wenn wir nicht verwendete Indizes entfernen, verbessern wir nur die Datenbank.

Die nächste Ansicht ist pg_stat_activity. Dies ist ein Analogon des Dienstprogramms ps, nur in PostgreSQL. Wenn ps'Oh, dann beobachte doch mal die Vorgänge im Betriebssystem pg_stat_activity zeigt Ihnen die Aktivität in PostgreSQL.

Was können wir daraus mitnehmen?

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

Wir können die Gesamtaktivität sehen, die in der Datenbank stattfindet. Wir können eine neue Bereitstellung durchführen. Dort ist alles explodiert, neue Verbindungen werden nicht akzeptiert, Fehler strömen 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 Abfrage wie diese ausführen und den Gesamtprozentsatz der Verbindungen im Verhältnis zum maximalen Verbindungslimit sehen und sehen, wer die meisten Verbindungen hat. Und in diesem Fall sehen wir diesen Benutzer cron_role 508 Verbindungen geöffnet. Und ihm ist etwas passiert. Man muss damit klarkommen und sehen. Und es ist durchaus möglich, dass es sich hierbei um eine ungewöhnliche Anzahl von Verbindungen handelt.

Wenn wir eine OLTP-Auslastung haben, sollten Abfragen schnell, sehr schnell erfolgen und es sollte keine langen Abfragen geben. Wenn es jedoch lange Anfragen gibt, besteht kurzfristig kein Grund zur Sorge, aber Auf lange Sicht schädigen lange Abfragen die Datenbank und verstärken den Aufblähungseffekt von Tabellen, wenn eine Tabellenfragmentierung auftritt. Sowohl aufgeblähte als auch lange Abfragen müssen beseitigt werden.

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: Bei einer solchen Anfrage können wir lange Anfragen und Transaktionen definieren. Wir nutzen die Funktion clock_timestamp() um die Arbeitszeit zu bestimmen. Lange Anfragen, die wir gefunden haben, können wir uns an sie erinnern und sie ausführen explain, Pläne anschauen und irgendwie optimieren. Wir schießen die aktuellen Langwünsche und leben weiter.

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

Fehlerhafte Transaktionen sind bei Transaktionen im Leerlauf und bei Transaktionen im Leerlauf (abgebrochene Transaktionen).

Was bedeutet das? Transaktionen haben mehrere Zustände. Und einer dieser Zustände kann jederzeit eintreten. Es gibt ein Feld zum Definieren von Zuständen state in dieser Ansicht. Und wir nutzen es, um den Zustand zu bestimmen.

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

Und wie ich oben sagte, diese beiden Staaten „Idle in Transaction“ und „Idle in Transaction (abgebrochen)“ sind schlecht. Was ist das? Dies ist der Zeitpunkt, an dem die Anwendung eine Transaktion eröffnet, einige Aktionen ausführt und ihrer Arbeit nachgeht. Die Transaktion bleibt offen. Es hängt, nichts passiert darin, es benötigt eine Verbindung, sperrt geänderte Zeilen und erhöht aufgrund der Architektur der Postrges-Transaktions-Engine möglicherweise noch die Aufblähung anderer Tabellen. Und solche Geschäfte sollten auch erschossen werden, denn sie sind im Allgemeinen auf jeden Fall schädlich.

Wenn Sie feststellen, dass Ihre Datenbank mehr als 5-10-20 davon enthält, müssen Sie sich Sorgen machen und anfangen, etwas mit ihnen zu unternehmen.

Auch hier verwenden wir für die Berechnung die Zeit clock_timestamp(). Wir erfassen Transaktionen, wir optimieren die Anwendung.

Wie ich oben sagte, liegen Sperren vor, wenn zwei oder mehr Transaktionen um eine oder eine Gruppe von Ressourcen konkurrieren. Dafür haben wir ein Feld waiting mit booleschem Wert true oder false.

Stimmt – das bedeutet, dass der Prozess wartet und etwas getan werden muss. Wenn ein Prozess wartet, wartet auch der Client, der den Prozess initiiert hat. Der Client sitzt im Browser und wartet ebenfalls.

Hinweis: _Ab Postgres 9.6 ist das Feld waiting entfernt und durch zwei weitere informative Felder ersetzt wait_event_type и wait_event._

Was zu tun ist? Wenn Sie lange Zeit wahr sehen, sollten Sie solche Anfragen loswerden. Wir schießen solche Transaktionen einfach ab. Wir schreiben den Entwicklern, was irgendwie optimiert werden muss, damit es nicht zu einem Wettlauf um Ressourcen kommt. Und dann optimieren die Entwickler die Anwendung, damit das nicht passiert.

Und ein extremer, aber möglicherweise nicht tödlicher Fall ist Auftreten von Deadlocks. Zwei Transaktionen haben zwei Ressourcen aktualisiert, dann greifen sie erneut auf sie zu, bereits auf entgegengesetzte Ressourcen. PostgreSQL übernimmt in diesem Fall die Transaktion selbst und schießt sie ab, damit die andere weiterarbeiten kann. Das ist eine Sackgasse und sie versteht sich selbst nicht. Daher ist PostgreSQL gezwungen, extreme 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, mit denen Sie Sperren verfolgen können. Wir nutzen die Ansicht pg_locks, mit dem Sie schwere Schlösser verfolgen können.

Und der erste Link ist der Anfragetext selbst. Es ist ziemlich lang.

Und der zweite Link ist ein Artikel über Schlösser. Es ist nützlich zu lesen, es ist sehr interessant.

Was sehen wir also? Wir sehen zwei Anfragen. Transaktion mit ALTER TABLE ist eine Sperrtransaktion. Es begann, endete aber nicht, und die Anwendung, die diese Transaktion gepostet hat, macht irgendwo andere Dinge. Und die zweite Anfrage ist Update. Es wartet, bis die Änderungstabelle abgeschlossen ist, bevor es seine Arbeit fortsetzt.

So können wir herausfinden, wer wen eingesperrt hat, wer wen festhält, und uns weiter damit befassen.

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

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

Was können wir daraus mitnehmen? Wenn wir über einfache Dinge sprechen, können wir die durchschnittliche Ausführungszeit einer Abfrage annehmen. Die Zeit drängt, was bedeutet, dass PostgreSQL langsam reagiert und etwas getan werden muss.

Wir können die aktivsten Schreibtransaktionen in der Datenbank sehen, die Daten in gemeinsam genutzten Puffern ändern. Sehen Sie, wer dort Daten aktualisiert oder löscht.

Und wir können uns einfach verschiedene Statistiken für diese Abfragen ansehen.

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

Wir pg_stat_statements Wird zum Erstellen von Berichten verwendet. Wir setzen die Statistiken einmal täglich zurück. Sammeln wir es. Bevor wir die Statistiken das nächste Mal zurücksetzen, erstellen wir einen Bericht. Hier ist ein Link zum Bericht. Du kannst es dir ansehen.

Was machen wir? Wir berechnen die Gesamtstatistik für alle Abfragen. Anschließend zählen wir für jede Abfrage ihren individuellen Beitrag zu dieser Gesamtstatistik.

Und was können wir sehen? Wir können die Gesamtausführungszeit aller Anfragen eines bestimmten Typs vor dem Hintergrund aller anderen Anfragen sehen. Wir können die CPU- und I/O-Auslastung im Verhältnis zum Gesamtbild betrachten. Und schon diese Anfragen zu optimieren. Auf Basis dieses Berichts erstellen wir Top-Anfragen und erhalten bereits Denkanstöße, was wir optimieren sollten.

Was haben wir hinter den Kulissen? Es gibt noch ein paar Einsendungen, die ich aus Zeitgründen nicht berücksichtigt habe.

Es gibt pgstattuple ist auch ein zusätzliches Modul aus dem Standard-Contribs-Paket. Es ermöglicht Ihnen eine Bewertung bloat Tische, sog. Tabellenfragmentierung. Und wenn die Fragmentierung groß ist, müssen Sie sie mit verschiedenen Werkzeugen entfernen. Und Funktion pgstattuple Funktioniert schon lange. Und je mehr Tische, desto länger funktioniert es.

Der nächste Beitrag ist pg_buffercache. Damit können Sie gemeinsam genutzte Puffer überprüfen: wie intensiv und für welche Tabellen Pufferseiten genutzt werden. Und es ermöglicht Ihnen lediglich, einen Blick in gemeinsam genutzte Puffer zu werfen und zu bewerten, was dort passiert.

Das nächste Modul ist pgfincore. Es ermöglicht Ihnen, Tabellenoperationen auf niedriger Ebene über einen Systemaufruf auszuführen mincore(), d. h. es ermöglicht Ihnen, die Tabelle in gemeinsam genutzte Puffer zu laden oder zu entladen. Und es ermöglicht unter anderem die Überprüfung des Seitencaches des Betriebssystems, d.

Das nächste Modul ist pg_stat_kcache. Es verwendet auch den Systemaufruf getrusage(). Und es führt es vor und nach der Ausführung der Anfrage aus. Und anhand der erhaltenen Statistiken können wir abschätzen, wie viel unsere Anfrage für Festplatten-I/O aufgewendet hat, also für Vorgänge mit dem Dateisystem, und einen Blick auf die Prozessorauslastung werfen. Allerdings ist das Modul jung (khe-khe) und für seine Arbeit benötigt es PostgreSQL 9.4 und pg_stat_statements, die ich bereits erwähnt habe.

Die Möglichkeit, Statistiken zu verwenden, ist nützlich. Sie benötigen keine Software von Drittanbietern. Man kann schauen, sehen, etwas tun, auftreten.
Die Verwendung von Statistiken ist einfach, es ist reines SQL. Sie haben eine Anfrage gesammelt, zusammengestellt, abgeschickt, angeschaut.
Statistiken helfen bei der Beantwortung von Fragen. Wenn Sie Fragen haben, wenden Sie sich an die Statistik – schauen Sie, ziehen Sie Schlussfolgerungen, analysieren Sie die Ergebnisse.
Und experimentieren. Viele Anfragen, viele Daten. Sie können jederzeit eine vorhandene Abfrage optimieren. Sie können Ihre eigene Version der Anfrage erstellen, die besser zu Ihnen passt als das Original, und diese verwenden.