Die Verwaltung von Datenbanken ist keine leichte Aufgabe und kann leicht frustrierend sein, wenn man nicht weiß, was unter der Decke passiert. Unabhängig davon, ob Sie herausfinden möchten, ob neue Indizes hilfreich sind, die Anzahl der Transaktionen in einer Datenbank zu einem bestimmten Zeitpunkt oder wer zu einem bestimmten Zeitpunkt mit der Datenbank verbunden ist, Daten, die es den Administratoren ermöglichen, wirklich zu wissen, wie ihre Datenbanken funktionieren, sind von entscheidender Bedeutung. Glücklicherweise sind bei PostgreSQL die Daten für all dies im PostgreSQL-Systemkatalog verfügbar.
Der PostgreSQL-Systemkatalog ist ein Schema mit Tabellen und Ansichten, die Metadaten zu allen anderen Objekten in der Datenbank und mehr enthalten. Damit können wir feststellen, wann verschiedene Operationen stattfinden, wie auf Tabellen oder Indizes zugegriffen wird und sogar, ob das Datenbanksystem Informationen aus dem Speicher liest oder Daten von der Festplatte abrufen muss.
Hier werden wir einen Überblick über den Systemkatalog geben und zeigen, wie man ihn liest und nützliche Informationen daraus zieht. Einige der Metadaten sind unkompliziert, und andere Teile erfordern ein wenig Verdauung, um wirklich nützliche Informationen zu generieren. Wie auch immer, PostgreSQL bietet uns eine großartige Plattform, um alle Informationen zu erstellen, die wir über die Datenbank selbst benötigen.
Der PostgreSQL-Katalog
PostgreSQL speichert die Metadateninformationen über die Datenbank und den Cluster im Schema „pg_catalog“. Diese Informationen werden teilweise von PostgreSQL selbst verwendet, um den Überblick zu behalten, aber sie werden auch so präsentiert, dass externe Personen / Prozesse das Innere der Datenbanken verstehen können.
Der PostgreSQL-Katalog hat eine ziemlich solide Regel:Anschauen, nicht anfassen. Während PostgreSQL all diese Informationen in Tabellen speichert, wie es jede andere Anwendung tun würde, werden die Daten in den Tabellen vollständig von PostgreSQL selbst verwaltet und sollten nicht geändert werden, es sei denn, es handelt sich um einen absoluten Notfall, und selbst dann ist wahrscheinlich ein Neuaufbau danach angebracht.
Wir werden ein paar nützliche Katalogtabellen durchgehen, wie man die Daten liest und clevere Dinge, die man mit den Daten selbst machen kann. Es gibt einige Tabellen im Katalog, auf die wir nicht eingehen werden, aber alle Informationen zu diesen verschiedenen Tabellen finden Sie in der offiziellen Dokumentation von PostgreSQL.
Systemweite Metadaten
Ein Großteil der Tabellen, die wir im Katalog abfragen können, sind „systemweite“ Tabellen, bei denen es keine Rolle spielt, mit welcher Datenbank wir verbunden sind, die Daten repräsentieren den gesamten Cluster, keine einzelne Datenbank.
Datenbankinformationen
Allgemeine Datenbankinformationen werden in pg_database gespeichert und Statistiken werden in pg_stat_database gespeichert.
pg_database:
postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid | 16396
datname | severalnines
datdba | 10
encoding | 6
datcollate | en_US.UTF-8
datctype | en_US.UTF-8
datistemplate | f
datallowconn | t
datconnlimit | -1
datlastsysoid | 13804
datfrozenxid | 548
datminmxid | 1
dattablespace | 1663
datacl |Die Tabelle pg_database enthält eine Zeile für jede Datenbank im Cluster, einschließlich der drei standardmäßigen (postgres, template0 und template1). Diese Zeile enthält Informationen zur Codierung, zum Verbindungslimit und zu anderen grundlegenden Metadaten.
Interessante Spalten:
oid – Die Objektkennung, die nicht in einer Abfrageausgabe erscheint, es sei denn, es wird direkt darauf verwiesen. Diese Nummer entspricht einem Verzeichnis im Datenverzeichnis des Clusters
datname – Der Name der Datenbank.
datdba – Der Besitzer der Datenbank, oid verweist auf pg_authid .oid.
encoding – Die Zeichenkodierung für diese Datenbank, pg_encoding_to_char(), wird in einen lesbaren Namen konvertiert.
datconnlimit – Die maximale Anzahl gleichzeitiger Verbindungen, die in der Datenbank erlaubt sind.
dattablespace – Der Standard-Tablespace für diese Datenbank, verweist auf pg_tablespace.oid.
pg_stat_database:
postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid | 13805
datname | postgres
numbackends | 2
xact_commit | 477460
xact_rollback | 13
blks_read | 417
blks_hit | 16488702
tup_returned | 252376522
tup_fetched | 2637123
tup_inserted | 114
tup_updated | 3
tup_deleted | 1
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
blk_read_time | 0
blk_write_time | 0
stats_reset | 2018-02-04 19:52:39.129052+00In dieser Statistiktabelle erhalten wir interessante und nützliche Daten. Jede Zeile in dieser Tabelle enthält Live-Daten für jede Datenbank und kann regelmäßig exportiert werden, um sie im Laufe der Zeit zu verfolgen, wenn Sie Änderungen überwachen möchten.
Transaktionen
Transaktionsinformationen finden Sie in den Spalten xact_commit und xact_rollback, die die Anzahl der Transaktionen enthalten, die die Datenbank festgeschrieben bzw. zurückgesetzt hat. Dies hilft dabei, zu zeigen, wie aktiv eine Datenbank ist, und mögliche Fehler bei Programmen zu erkennen, die möglicherweise mit alarmierender Häufigkeit fehlerhaft sind oder zurückgesetzt werden.
Festplatten- und Speicherzugriff
Informationen darüber, ob Daten von der Festplatte oder dem Speicher abgerufen werden oder nicht, werden in den Spalten blks_read und blks_hit gespeichert. Blks_read zeigt die Anzahl der Blöcke, die diese Datenbank von der Festplatte gelesen hat, während blks_hit die Anzahl der Blöcke anzeigt, die im Puffercache von PostgreSQL gefunden wurden (dargestellt durch den Parameter shared_buffers). Da RAM viel schneller ist als die Festplatte, würden wir im Idealfall blks_hit konstant höher als blks_read sehen, und wenn nicht, können wir unseren verfügbaren Speicher neu bewerten.
Tupel
Die nächsten Spalten befassen sich mit Tupeln. Tup_returned ist die Anzahl der in der Datenbank zurückgegebenen Zeilen, d. h. die Anzahl der Zeilen, die von sequentiellen Scans aus einer Tabelle gelesen werden, oder die Anzahl der zurückgegebenen Indexeinträge, wenn sie aus einem Index stammen. Tup_fetched ist die Anzahl der in der Datenbank abgerufenen Zeilen, was bedeutet, dass sie das Ergebnis von Bitmap-Scans waren, was die Anzahl der Tabellenzeilen ist, die von Bitmap-Scans aus einer Tabelle abgerufen wurden, oder der Tabellenzeilen, die von einfachen Index-Scans abgerufen wurden, wenn ein Index verwendet wurde.
Wir haben auch tup_inserted, tup_updated und tup_deleted, was die Anzahl der in dieser Datenbank eingefügten, aktualisierten bzw. gelöschten Tupel darstellt. Dies hilft zu verstehen, wie Daten in die Datenbank eingegeben, geändert und verlassen werden. Da aktualisierte und gelöschte Tupel zu toten Zeilen führen, würden hohe Werte in diesen Spalten darauf hindeuten, dass Selbstbereinigungsvorgänge optimiert werden, um die Anforderungen der Datenbankaktivität zu erfüllen.
Konflikte
Wenn es sich bei der betreffenden Datenbank um einen Standby-Server handelt, ist die Spalte „conflicts“ praktisch, um nachzuverfolgen, wie viele Abfragen aufgrund von Konflikten mit dem Standby-Server im „Wiederherstellungsmodus“ abgebrochen wurden. Wenn es sich nicht um einen Standby-Cluster handelt, kann diese Spalte ignoriert werden.
Temporäre Dateien / Daten
Manchmal müssen Abfragen in temporäre Dateien schreiben. Dies kann passieren, wenn die der Verbindung zugewiesene Menge an work_mem aufgebraucht ist und eine Sortieroperation auf der Festplatte statt im Arbeitsspeicher fortgesetzt werden muss. Die Spalte temp_files verfolgt die Anzahl dieser Dateien, die erstellt wurden, und temp_bytes verfolgt die Gesamtgröße aller verwendeten temporären Dateien. Diese Daten können dabei helfen, work_mem-Tuning zu informieren oder sogar Abfragen zu finden, die neu geschrieben werden könnten, wenn die Größe der temporären Datei zu groß ist.
Deadlocks
Die Deadlocks-Spalte verfolgt, wie oft ein Deadlock auftritt. Da ein Deadlock Fehler bei Abfragen verursachen kann, die andernfalls nicht fehlschlagen würden, ist es gut, dies zu verfolgen und sicherzustellen, dass sich Anwendungen nicht gegenseitig auf die Füße treten.
Lese- und Schreibzeiten
Die Spalten blk_read_time und blk_write_time verfolgen die Gesamtzahl der Millisekunden, die Backends in der Datenbank mit dem Lesen und Schreiben von Daten verbringen, was hilfreich sein kann, wenn Sie versuchen, die Lese-/Schreibgeschwindigkeit der Festplatte zu vergleichen/verbessern
Statistiken zurückgesetzt
Diese Spalte, stats_reset, zeigt einfach einen Zeitstempel (mit Zeitzone) des letzten Mal, als die in dieser Zeile erwähnten Statistiken zurückgesetzt wurden. Ein Nullwert bedeutet, dass sie seit ihrer Einführung nicht zurückgesetzt wurden, oder möglicherweise sogar ein Absturz der Datenbank, der diese Statistiken möglicherweise gelöscht hat.
Checkpoints und The Background Writer
pg_stat_bgwriter
postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 47829
checkpoints_req | 2
checkpoint_write_time | 7323
checkpoint_sync_time | 38
buffers_checkpoint | 76
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 5
buffers_backend_fsync | 0
buffers_alloc | 440
stats_reset | 2018-02-04 19:52:34.712832+00Der PostgtreSQL-Cluster verwaltet das Schreiben von Daten auf die Festplatte auf verschiedene Arten. In Bezug auf „schmutzige Puffer“ (Daten im Speicher, die seit dem Lesen von der Festplatte geändert wurden, aber diese Änderung noch nicht auf die Festplatte geschrieben wurde) wird dies entweder von einem Prüfpunkt oder dem Hintergrundschreiber durchgeführt. Da ein fehlerhafter Puffer auf die Festplatte geschrieben werden muss, bevor er freigegeben oder neu zugewiesen werden kann, ist es entscheidend, sicherzustellen, dass diese Prozesse fein abgestimmt sind, und diese Tabelle hilft, Licht ins Dunkel zu bringen, wie das alles funktioniert.
Kontrollpunkte
Ein Prüfpunkt findet entweder nach Zeitplan statt (dargestellt durch den Parameter checkpoint_timeout) oder wenn die maximale Anzahl an WAL-Dateien seit dem letzten Prüfpunkt verwendet wurde und einen Prüfpunkt erzwingen muss. In jedem Fall schreibt ein Prüfpunkt schmutzige Puffer auf die Festplatte, und es gibt vier Spalten, die ihn verfolgen.
Die Spalten checkpoints_timed und checkpoints_req zeigen die Anzahl der geplanten Checkpoints (timed) und die Anzahl der angeforderten Checkpoints (auch als erzwungen bezeichnet). Ein hoher Kletterwert von checkpoint_req könnte auf einen unzureichenden max_wal_size-Wert hindeuten.
Die Spalten checkpoint_write_time und checkpoint_sync_time zeichnen die Gesamtzeit (in Millisekunden) auf, die der Checkpoint-Prozess mit dem Schreiben und Synchronisieren auf die Festplatte verbracht hat.
Schließlich ist buffers_checkpoint die Gesamtzahl der Puffer, die von Checkpoints auf die Platte geschrieben wurden.
Hintergrundschreiber
Der Hintergrundschreiber ist ein separater Prozess, der unsaubere Puffer auf die Festplatte schreibt, was im Idealfall die Menge an Arbeit reduziert, die der Checkpointer erledigen muss.
Die Spalte buffers_clean stellt die Anzahl der Puffer dar, die vom Hintergrundprozess auf die Festplatte geschrieben wurden. Im Vergleich zu buffers_checkpoint zeigt es, wie viel der Arbeitslast von jedem Prozess verarbeitet wird (mit dem zusätzlichen Wissen, dass der Hintergrundschreiber die Möglichkeit hat, Puffer mehrmals zu schreiben, wenn sie sich häufig ändern, im Vergleich zu weniger häufig mit einem zeitgesteuerten Prüfpunkt).
Maxwritten_clean stellt dar, wie oft der Hintergrundschreiber die maximale Anzahl von Seiten erreicht hat, die bei jeder Ausführung geleert werden müssen (gesteuert mit dem Parameter bgwriter_lru_maxpages).
Puffer im Allgemeinen
Die verbleibenden Spalten zeigen uns die allgemeinen Pufferinformationen, wobei buffers_backend die Anzahl der Puffer ist, die ein Backend selbst schreiben musste, anstelle von Hintergrundschreiber oder Checkpointer, buffers_backend_fsync eine Zählung dafür ist, wie oft ein Backend seinen eigenen fsync-Aufruf ausführen musste, und buffers_alloc zeigt die Anzahl der Puffer, die allgemein allokiert wurden.
Datenbankaktivität und Sperren
Es gibt zwei Ansichten, die die aktuelle Benutzeraktivität anzeigen, pg_stat_activity und pg_locks. Wenn sie abgefragt werden, zeigen diese Informationen über aktuelle Verbindungen zu den Datenbanken und welche Sperren sie für welche Relationen haben.
pg_stat_activity
postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid | 13805
datname | severalnines
pid | 29730
usesysid | 10
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2018-07-21 02:29:48.976588+00
xact_start | 2018-07-21 02:30:03.73683+00
query_start | 2018-07-21 02:30:03.73683+00
state_change | 2018-07-21 02:30:03.736835+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 559
query | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type | client backendAllgemeine Informationen
Die Ansicht pg_stat_activity zeigt eine Zeile für jede Verbindung zur Datenbank und einige grundlegende Informationen darüber. Die Spalte datname stellt die Datenbank dar, mit der die Verbindung tatsächlich verbunden ist, pid ist die Prozess-ID der Verbindung auf dem Datenbankhost selbst, und usesysid und usename stellen den verbundenen Datenbankbenutzer dar.
Für die Quelle des Clients ist client_addr die IP-Adresse des Hosts, von dem die Verbindung kam, null bedeutet, dass es sich um eine lokale Unix-Socket-Verbindung handelt.
Zeitstempel
Es gibt vier Timestamp-Spalten, die zeigen, wann bestimmte Dinge gestartet wurden:backend_start ist, wann die Verbindung tatsächlich hergestellt wurde, xact_start ist, wann die aktuelle Transaktion gestartet wurde (null, wenn der Client keine offene Transaktion hat), query_start ist, wann die aktuelle oder letzte Abfrage gestartet wurde, und state_change ist die Zeit, zu der sich der Status der Verbindung zuletzt geändert hat.
Verbindungsstatus
Die letzten Bits von pg_stat_activity decken den tatsächlichen Status der Verbindung ab. Wenn die Abfrage auf eine andere wartet, um Sperren freizugeben, enthält wait_event_type einige Informationen darüber, um welche Art von Warteereignis es sich handelt, und die Spalte wait_event zeigt den Namen des Warteereignisses. Die Liste ist lang, aber weitere Informationen finden Sie in der PostgreSQL-Dokumentation.
Schließlich zeigt die Spalte „Status“ an, in welchem Zustand sich die aktuelle Verbindung befindet, z. B. aktiv, im Leerlauf, im Leerlauf in Transaktion, und die Abfragespalte zeigt die aktuell ausgeführte oder zuletzt ausgeführte Abfrage.
pg_lock
SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 3/475862
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 3/475862
pid | 29730
mode | ExclusiveLock
granted | t
fastpath | tDie pg_locks-Tabelle arbeitet Hand in Hand mit pg_stat_activity, wenn die Abfrageaktivität untersucht wird. Jedes Mal, wenn eine Beziehung gesperrt wird, werden diese Informationen in pg_locks gespeichert. Unter Verwendung der PID von pg_stat_activity können wir pg_locks abfragen, um zu sehen, auf welche Relationen eine Verbindung möglicherweise Sperren hat, welche Arten von Sperren das sind und ob die Sperren gewährt wurden oder nicht.
Die wichtigsten Spalten sind 'pid', das mit der pid von pg_stat_activity übereinstimmt, 'relation', das mit der OID von pg_class übereinstimmt, 'mode', das den Namen des gehaltenen Sperrmodus anzeigt, und 'granted', das angibt, ob die Sperre aktiviert ist oder nicht Frage wurde genehmigt.
Replikationsinformationen
Da PostgreSQL über eingebaute Replikationsfunktionen verfügt, gibt es einige Ansichten, die Aufschluss über die Leistung und den Status der Replikation selbst geben.
pg_stat_replication anzeigen: enthält eine Zeile für jeden WAL-Senderprozess mit Informationen zu seinem Status, dem Speicherort der WAL-Dateien, an denen er arbeitet, und den Verbindungsinformationen des Standby-Hosts, der die WAL-Daten zur Replikation empfängt.
pg_stat_wal_receiver anzeigen: Wenn der Cluster ein Standby-Cluster ist, enthält dieser eine einzelne Zeile mit Statistiken über den Empfängerprozess vom Host.
pg_stat_subscription anzeigen: Wenn WAL-Daten an einen Standby-Knoten gesendet werden, stellt jede Zeile hier dieses Abonnement dar und enthält Informationen über den Status der Abonnements.
pg_replication_slots anzeigen: Enthält eine Liste aller Replikationsslots, die im Cluster vorhanden sind, und ihren aktuellen Status.
Datenbankspezifische Metadaten
In jeder Datenbank gibt es eine Sammlung von Katalogtabellen, die Informationen enthalten, die für die abgefragte Datenbank spezifisch sind. Wenn wir nach bestimmten Daten aus diesen Tabellen suchen, müssen wir sicherstellen, dass wir mit der richtigen Datenbank verbunden sind, wenn wir die Abfragen ausgeben.
Hier kann das Herzstück der Datenanalyse ins Spiel kommen, wo wir sehen können, wie auf unsere Benutzerdaten zugegriffen wird. Von Tabellen über Indizes bis hin zu Sequenzen werden die Abfragen, die in die Datenbank eingehen und Daten abrufen oder ändern, ihre Aktionen und Auswirkungen in diesen Tabellen gespeichert, und wir können diese Informationen einsehen, um fundierte Entscheidungen über die Verwaltung der Datenbank später zu treffen Straße.
Tabellen-Metadaten
Metadaten zu unseren Benutzertabellen werden in den folgenden zwei Tabellen gespeichert, und sie haben jeweils eine Zeile für jede im System erstellte Benutzertabelle. Die Tabelle pg_stat_user_tables enthält Statistiken über den Benutzerzugriff auf die Tabelle, während pg_statio_user_tables I/O-Statistiken für jede Tabelle enthält.
HINWEIS:Die hier enthaltenen Daten sind nicht immer 100 % perfekt und hängen von häufigen Analysen der Tabellen ab, um korrekt zu sein. Autoanalyze deckt dies ab, aber eine gute Abstimmung des Autoanalyse-Prozesses, damit er gute Statistiken über jede Tabelle führen kann. Wenn die Statistiken ausgeschaltet zu sein scheinen, werden sie durch manuelles Ausführen einer ANALYSE auf der Tabelle aktualisiert.
Tabelle pg_stat_user_tables:
severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid | 2766788
schemaname | public
relname | history
seq_scan | 13817
seq_tup_read | 466841
idx_scan | 12251
idx_tup_fetch | 127652
n_tup_ins | 11
n_tup_upd | 13
n_tup_del | 3
n_tup_hot_upd | 13
n_live_tup | 3
n_dead_tup | 21
n_mod_since_analyze | 19
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0Für unsere Benutzertabellenstatistiken haben wir eine ganze Reihe von Daten.
Tabellenzugriffsmethoden
Wenn Clients auf Daten aus der Tabelle zugreifen, geschieht dies entweder direkt oder über Indizes. Die Spalte „seq_scan“ zählt die Anzahl der sequentiellen Scans, die die Tabelle erhalten hat, und „seq_tup_read“ zählt die Anzahl der Tupel, die durch diesen Prozess gelesen wurden. Die Spalte „idx_scan“ zählt, wie oft ein Index der Tabelle zum Abrufen von Daten verwendet wurde.
Tabellen-Tupel-Aktivität
Wir haben jetzt eine Handvoll Spalten, die verschiedene Aktivitäten auf der Tabelle zählen.
‚n_tup_ins‘ verfolgt die Anzahl der eingefügten Tupel
„n_tup_upd“ verfolgt die Anzahl der aktualisierten Tupel
‘n_tup_del’ verfolgt die Anzahl der gelöschten Tupel
Status des Tabellentupels
Aufgrund von Aktualisierungen und Löschungen können tote Tupel vorhanden sein, die keine aktiven Daten mehr sind, und der Vakuumprozess wird sie schließlich freigeben. Die Spalten „n_tup_ins“ und „n_tup_ins“ verfolgen die Anzahl der lebendigen bzw. toten Tupel. Wenn tote Tupel einen bestimmten Punkt erreichen, wird abhängig von den Autovacuum-Einstellungen ein Autovacuum gestartet.
Tischvakuumaktivität
Die Tabellenpflege erfolgt entweder über VACUUM oder AUTOVACUUM, und Statistiken werden über ANALYZE oder AUTOANALYZE gesammelt. Die nächsten vier Spalten enthalten die Daten für die letzte Ausführung dieser Operationen:„last_vacuum“, „last_autovacuum“, „last_analyze“, „last_autoanalyze“.
Wir haben auch vier praktischere Spalten, die einfach zählen, wie oft die vorherigen Aktionen auftreten. Anhand dieser können wir sehen, welche Tabellen die meiste Aktivität aufweisen:„vacuum_count“, „autovacuum_count“, „analyze_count“ und „autoanalyze_count“.
Tabelle pg_statio_user_tables:
severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid | 2766788
schemaname | public
relname | history
heap_blks_read | 4
heap_blks_hit | 63081
idx_blks_read | 5
idx_blks_hit | 44147
toast_blks_read | 0
toast_blks_hit | 0
tidx_blks_read | 0
tidx_blks_hit | 0Der E/A-Ausgang ist nützlich, um zu verstehen, wie auf die Daten unter der Decke zugegriffen wird. Die Spalte „heap_blks_read“ stellt die Anzahl der für diese Tabelle gelesenen Plattenblöcke dar, und „heap_blks_hit“ stellt die aus dem Speicher dieser Tabelle gelesenen Pufferblöcke dar. Dies ist hilfreich, um zu wissen, ob Abfragen, die auf die Tabelle zugreifen, ständig auf die Festplatte gehen oder die Daten aus dem Speicher abrufen müssen.
Indexstatistiken in der Tabelle zeigen dieselben Informationen mit den Spalten „idx_blks_read“ und „idx_blks_hit“.
Wenn die Tabelle schließlich TOAST-Tabellen enthält, verfolgen die Spalten „toast_blks_hit“ und „toast_blks_read“ Toast-Tabellen, während „tdix_blks_read“ und „tdix_blks_read“ die Indizes dieser Toast-Tabellen verfolgen.
Index-Metadaten
pg_stat_user_indexes
severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_scan | 43910
idx_tup_read | 98147
idx_tup_fetch | 98147Ähnlich wie die Tabellenentsprechungen enthält diese Tabelle Informationen speziell zu den Indizes. Eine Zeile pro Index, diese Tabelle zeigt, wie oft der Index mit der Spalte „idx_scan“ gescannt wurde, wie viele Tupel mit „idx_tup_read“ gelesen wurden und wie viele Live-Zeilen tatsächlich mit „idx_tup_fetch“ abgerufen wurden.
pg_statio_user_indexes
severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_blks_read | 2
idx_blks_hit | 49380Für pg_statio_user_indexes sind die beiden für Daten verfügbaren Spalten „idx_blks_read“ und „idx_blks_hit“, die die Anzahl der von der Festplatte und aus dem Speicher gelesenen Blöcke darstellen.
Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunterWas können wir mit diesen Daten machen?
Werde kreativ! Wenn Abfragen an eine bestimmte Tabelle extrem langsam zu sein scheinen, verfolgen Sie ihre Aktivität im Laufe der Zeit, sehen Sie sich an, wie viele sequentielle Scans sie im Vergleich zu Index-Scans erhält, und prüfen Sie, ob die Daten auf die Festplatte oder in den Speicher gelangen.
Wenn eine große Tabelle häufig automatisch evakuiert wird, verfolgen Sie die Live-to-Dead-Tupel im Laufe der Zeit, möglicherweise muss die Autovakuierung speziell optimiert werden, damit sie schneller abgeschlossen werden kann, oder vielleicht ist die Tabelle sogar ein Kandidat für die Partitionierung.
Da wir sehen können, wann Daten von der Festplatte oder dem Speicher kommen, können wir ein Verhältnis von Speicher zu Festplatte im Laufe der Zeit erstellen und feststellen, ob das Verhältnis zu irgendeinem Zeitpunkt im Laufe des Tages sinkt.
Die Anzahl der Tabellen, die wir behandelt haben, ging über die großen Hitter hinaus, die wichtigsten Daten, die nützlich sind, um das Innenleben der Datenbanken zu kennen. Es gibt aber noch viele weitere Tabellen im Systemkatalog, die situativ nützliche Daten enthalten. Das Lesen anderer Tabellen wie zuvor hilft dabei, Einblicke in den Zustand der Datenbank im Allgemeinen zu erhalten.
Weitere Informationen zu allen Tabellen oder Ansichten im PostgreSQL-Katalog finden Sie in der offiziellen Dokumentation hier sowie Informationen zum Statistiksammler hier.
