PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Wichtige Dinge, die in PostgreSQL überwacht werden müssen – Analysieren Ihrer Arbeitslast

Wichtige Dinge, die in PostgreSQL überwacht werden sollten – Analysieren Ihrer Arbeitslast

In Computersystemen ist Überwachung der Prozess des Sammelns von Metriken, Analysieren, Berechnen von Statistiken und Erstellen von Zusammenfassungen und Diagrammen bezüglich der Leistung oder Kapazität eines Systems sowie des Generierens von Warnungen bei unerwarteten Problemen oder Fehlern, die sofortige Aufmerksamkeit oder Maßnahmen erfordern. Daher hat die Überwachung zwei Verwendungszwecke:einen für die Analyse und Präsentation historischer Daten, die uns dabei helfen, mittel- und langfristige Trends in unserem System zu erkennen und somit Upgrades zu planen, und einen zweiten für sofortige Maßnahmen im Falle von Problemen.

Die Überwachung hilft uns, Probleme zu identifizieren und auf diese Probleme in einer Vielzahl von Bereichen zu reagieren, wie zum Beispiel:

  • Infrastruktur/Hardware (physisch oder virtuell)
  • Netzwerk
  • Speicherung
  • Systemsoftware
  • Anwendungssoftware
  • Sicherheit

Überwachung ist ein wichtiger Teil der Arbeit eines DBA. PostgreSQL ist aufgrund seines ausgeklügelten Designs traditionell als „wartungsarm“ bekannt, was bedeutet, dass das System im Vergleich zu anderen Alternativen mit geringer Wartung auskommen kann. Bei seriösen Installationen, bei denen hohe Verfügbarkeit und Leistung von entscheidender Bedeutung sind, muss das Datenbanksystem jedoch regelmäßig überwacht werden.

Die Rolle des PostgreSQL DBA kann neben der rein technischen auch auf höhere Ebenen innerhalb der Unternehmenshierarchie aufsteigen:Abgesehen von der grundlegenden Überwachung und Leistungsanalyse muss er in der Lage sein, Änderungen in Nutzungsmustern zu erkennen, mögliche Ursachen zu identifizieren, die Annahmen zu überprüfen und schließlich zu übersetzen Erkenntnisse in kaufmännischer Hinsicht. Beispielsweise muss der DBA in der Lage sein, eine plötzliche Änderung in einer bestimmten Aktivität zu erkennen, die mit einer möglichen Sicherheitsbedrohung verbunden sein könnte. Die Rolle des PostgreSQL DBA ist also eine Schlüsselrolle innerhalb des Unternehmens und muss eng mit anderen Abteilungsleitern zusammenarbeiten, um auftretende Probleme zu identifizieren und zu lösen. Überwachung ist ein großer Teil dieser Verantwortung.

PostgreSQL bietet viele sofort einsatzbereite Tools, die uns beim Sammeln und Analysieren von Daten helfen. Darüber hinaus bietet es aufgrund seiner Erweiterbarkeit die Möglichkeit, neue Module in das Kernsystem zu integrieren.

PostgreSQL ist stark abhängig von dem System (Hardware und Software), auf dem es ausgeführt wird. Wir können nicht erwarten, dass ein PostgreSQL-Server eine gute Leistung erbringt, wenn es Probleme in einer der lebenswichtigen Komponenten im Rest des Systems gibt. Die Rolle des PostgreSQL DBA überschneidet sich also mit der Rolle des Systemadministrators. Wenn wir im Folgenden untersuchen, was bei der PostgreSQL-Überwachung zu beachten ist, werden wir sowohl auf systemabhängige Variablen und Metriken als auch auf die spezifischen Zahlen von PostgreSQL stoßen.

Überwachung gibt es nicht umsonst. Das Unternehmen/die Organisation muss eine gute Investition tätigen und sich verpflichten, den gesamten Überwachungsprozess zu verwalten und aufrechtzuerhalten. Es fügt auch eine leichte Last auf dem PostgreSQL-Server hinzu. Dies ist kein Grund zur Sorge, wenn alles richtig konfiguriert ist, aber wir müssen bedenken, dass dies ein weiterer Weg sein kann, das System zu missbrauchen.

Grundlagen der Systemüberwachung

Wichtige Variablen in der Systemüberwachung sind:

  • CPU-Auslastung
  • Netzwerknutzung
  • Festplattenspeicher / Festplattenauslastung
  • RAM-Nutzung
  • Datenträger-IOPS
  • Auslagerungsplatznutzung
  • Netzwerkfehler

Hier ist ein Beispiel für ClusterControl, das Diagramme für einige kritische PostgreSQL-Variablen zeigt, die von pg_stat_database und pg_stat_bgwriter stammen (die wir in den folgenden Abschnitten behandeln werden), während pgbench -c 64 -t 1000 pgbench zweimal ausgeführt wird:

Wir stellen fest, dass wir im ersten Durchlauf einen Spitzenwert beim Lesen von Blöcken haben, aber im zweiten Durchlauf nähern wir uns Null, da alle Blöcke in shared_buffers gefunden werden.

Andere interessierende Variablen sind unter anderem Paging-Aktivität, Interrupts, Kontextwechsel. Es gibt eine Fülle von Tools, die in Linux/BSDs und Unix- oder Unix-ähnlichen Systemen verwendet werden können. Einige davon sind:

  • ps:für eine Liste der laufenden Prozesse

  • top/htop/systat:zur Überwachung der Systemauslastung (CPU/Speicher)

  • vmstat:zur Überwachung der allgemeinen Systemaktivität (einschließlich des virtuellen Speichers)

  • iostat/iotop/top -mio:für IO-Überwachung

  • ntop:zur Netzwerküberwachung

Hier ist ein Beispiel für vmstat auf einer FreeBSD-Box während einer Abfrage, die einige Lesevorgänge auf der Festplatte und auch einige Berechnungen erfordert:

procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

Beim Wiederholen der Abfrage würden wir keinen neuen Burst der Festplattenaktivität bemerken, da sich diese Festplattenblöcke bereits im Cache des Betriebssystems befinden würden. Obwohl der PostgreSQL-DBA in der Lage sein muss, vollständig zu verstehen, was in der zugrunde liegenden Infrastruktur passiert, in der die Datenbank ausgeführt wird, ist eine komplexere Systemüberwachung normalerweise eine Aufgabe für den Systemadministrator, da dies ein großes Thema für sich ist.

Unter Linux eine sehr praktische Abkürzung für oben Dienstprogramm drückt „C“, wodurch die Befehlszeile der Prozesse angezeigt wird. PostgreSQL überschreibt standardmäßig die Befehlszeile der Backends mit der tatsächlichen SQL-Aktivität, die sie gerade ausführen, und auch mit dem Benutzer.

Grundlagen der PostgreSQL-Überwachung

Wichtige Variablen in der PostgreSQL-Überwachung sind:

  • Puffer-Cache-Leistung (Cache-Treffer vs. Festplatten-Lesevorgänge)
  • Anzahl der Commits
  • Anzahl der Verbindungen
  • Anzahl der Sitzungen
  • Checkpoints und Bgwriter-Statistiken
  • Staubsauger
  • Schlösser
  • Replikation
  • Und last but not least Abfragen

Im Allgemeinen gibt es in einem Monitoring-Setup zwei Möglichkeiten, um die Datenerfassung durchzuführen:

  • Erfassen von Daten über ein Protokoll
  • Erfassen von Daten durch Abfragen des PostgreSQL-Systems

Die protokolldateibasierte Datenerfassung hängt vom (richtig konfigurierten) PostgreSQL-Protokoll ab. Wir können diese Art der Protokollierung für die „Offline“-Verarbeitung der Daten verwenden. Die protokolldateibasierte Überwachung ist am besten geeignet, wenn ein minimaler Overhead für den PostgreSQL-Server erforderlich ist und wenn wir uns nicht um Live-Daten oder das Erhalten von Live-Warnungen kümmern (obwohl eine Live-Überwachung mithilfe von Protokolldateidaten möglich sein kann, indem z. B. das PostgreSQL-Protokoll an syslog und dann Syslog auf einen anderen Server streamen, der für die Protokollverarbeitung dediziert ist).

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 herunter

PostgreSQL-Statistiksammler

PostgreSQL bietet eine Vielzahl von Ansichten und Funktionen, die über das Statistics Collector-Subsystem verfügbar sind. Auch diese Daten sind in zwei Kategorien unterteilt:

  • Dynamische Informationen darüber, was das System gerade tut.
  • Statistiken, die seit dem letzten Zurücksetzen des Statistiksammler-Subsystems angesammelt wurden.

Dynamische Statistikansichten Informationen über die aktuelle Aktivität pro Prozess (pg_stat_activity), Status der physischen Replikation (pg_stat_replication), Status des physischen Standby (pg_stat_wal_receiver) oder logisch (pg_stat_subscription), SSL (pg_stat_ssl) und Vakuum (pg_stat_progress_vacuum) bereitstellen.

Erfasste Statistikansichten liefern Informationen über wichtige Hintergrundprozesse wie den wal-Archiver, den bgwriter und Datenbankobjekte:Benutzer- oder Systemtabellen, Indizes, Sequenzen und Funktionen sowie die Datenbanken selbst.

Es sollte mittlerweile klar sein, dass es mehrere Möglichkeiten gibt, Daten im Zusammenhang mit der Überwachung zu kategorisieren:

  • Nach Quelle:
    • Systemtools (ps, top, iotop usw.)
    • PgSQL-Protokolldatei
    • Datenbank
      • Dynamisch
      • Gesammelt
  • Durch bestimmte Datenbankoperation:
    • Puffer-Cache
    • Commits
    • Abfragen
    • Sitzungen
    • Kontrollpunkte
    • usw.

Nachdem Sie diesen Artikel gelesen und mit den vorgestellten Begriffen, Konzepten und Begriffen experimentiert haben, sollten Sie in der Lage sein, eine 2D-Matrix mit allen möglichen Kombinationen zu erstellen. Beispielsweise kann die spezifische PostgreSQL-Aktivität (SQL-Befehl) gefunden werden mit:ps oder top (Systemdienstprogramme), den PostgreSQL-Protokolldateien, pg_stat_activity (dynamische Ansicht), aber auch mit pg_stat_statements, einer Erweiterung, die in contrib (Ansicht der gesammelten Statistiken) zu finden ist. . Ebenso finden sich Informationen zu Sperren in den PostgreSQL-Protokolldateien pg_locks und pg_stat_activity (gleich unten dargestellt) mit wait_event und wait_event_type . Aus diesem Grund ist es schwierig, den weiten Bereich der Überwachung in einer eindimensionalen linearen Weise abzudecken, und der Autor riskiert, den Leser dadurch zu verwirren. Um dies zu vermeiden, decken wir die Überwachung grob ab, indem wir dem Verlauf der offiziellen Dokumentation folgen und bei Bedarf entsprechende Informationen hinzufügen.

Dynamische Statistikansichten

Verwenden von pg_stat_activity Wir können sehen, was die aktuellen Aktivitäten der verschiedenen Backend-Prozesse sind. Wenn wir zum Beispiel die folgende Abfrage auf Tabellenteilen mit etwa 3 Millionen Zeilen ausführen:

testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

Lassen Sie uns die folgende Abfrage ausführen, die einige Sekunden zum Abschließen benötigt:

testdb=# select avg(age(date_added)) FROM parts;

Indem wir ein neues Terminal öffnen und die folgende Abfrage ausführen, während die vorherige noch läuft, erhalten wir:

testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

Die Ansicht pg_stat_activity gibt uns Informationen über den Backend-Prozess, den Benutzer, den Client, die Transaktion, die Abfrage, den Status sowie eine umfassende Information über den Wartestatus der Abfrage.

Aber warum 3 Reihen? Wenn in Versionen>=9.6 eine Abfrage parallel ausgeführt werden kann oder Teile davon parallel ausgeführt werden können und der Optimierer der Meinung ist, dass die parallele Ausführung die schnellste Strategie ist, erstellt er ein Gather oder Gather Merge Knoten und fordert dann höchstens max_parallel_workers_per_gather an Hintergrundarbeitsprozesse, was standardmäßig 2 ist, daher die 3 Zeilen, die wir in der obigen Ausgabe sehen. Wir können den Client-Backend-Prozess vom Hintergrund-Worker unterscheiden, indem wir den backend_type verwenden Säule. Damit die Ansicht pg_stat_activity aktiviert wird, müssen Sie sicherstellen, dass der Systemkonfigurationsparameter track_activities ist an. Die pg_stat_activity bietet umfassende Informationen, um blockierte Abfragen durch die Verwendung der Spalten wait_event_type und wait_event zu ermitteln.

Eine raffiniertere Methode zum Überwachen von Anweisungen bietet die pg_stat_statements contrib-Erweiterung, die bereits erwähnt wurde. Auf einem neueren Linux-System (Ubuntu 17.10, PostgreSQL 9.6) kann dies ziemlich einfach installiert werden:

testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

Lassen Sie uns eine Tabelle mit 100000 Zeilen erstellen und dann pg_stat_statements zurücksetzen, den PostgreSQL-Server neu starten, eine Auswahl für diese Tabelle auf dem (noch kalten) System durchführen und dann den Inhalt von pg_stat_statements für die Auswahl anzeigen:

testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

Lassen Sie uns jetzt noch einmal select * ausführen und dann erneut im Inhalt von pg_stat_statements nach dieser Abfrage suchen:

[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

Beim zweiten Mal findet die select-Anweisung also alle erforderlichen Blöcke in den gemeinsamen PostgreSQL-Pufferspeichern, und pg_stat_statements meldet dies über shared_blks_hit . pg_stat_statements liefert Informationen über die Gesamtzahl der Aufrufe einer Anweisung, total_time, min_time, max_time und mean_time, was äußerst hilfreich sein kann, wenn Sie versuchen, die Auslastung Ihres Systems zu analysieren. Eine langsame Abfrage, die sehr häufig ausgeführt wird, sollte sofortige Aufmerksamkeit erfordern. Ebenso können durchgängig niedrige Trefferquoten darauf hindeuten, dass die shared_buffers überprüft werden müssen Einstellung.

pg_stat_replication liefert Informationen zum aktuellen Status der Replikation für jeden wal_sender. Nehmen wir an, wir haben eine einfache Replikationstopologie mit unserem primären und einem Hot-Standby eingerichtet, dann können wir pg_stat_replication auf dem primären abfragen (dieselbe Vorgehensweise auf dem Standby führt zu keinen Ergebnissen, es sei denn, wir haben eine kaskadierende Replikation eingerichtet und dieses spezielle Standby dient als Upstream zu anderen Downstream-Standbys), um den aktuellen Status der Replikation anzuzeigen:

testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

Die 4 Spalten sent_lsn , write_lsn , flush_lsn , replay_lsn Teilen Sie uns die genaue WAL-Position in jeder Phase des Replikationsprozesses im Remote-Standby mit. Dann erzeugen wir mit einem Befehl wie dem folgenden starken Datenverkehr auf der Primärseite:

testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

Und schauen Sie sich noch einmal pg_stat_replication an:

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

Jetzt sehen wir, dass wir eine Verzögerung zwischen dem primären und dem Standby haben, die in sent_lsn dargestellt sind , write_lsn , flush_lsn , replay_lsn Werte. Seit PgSQL 10.0 zeigt pg_stat_replication auch die Verzögerung zwischen einer kürzlich lokal geleerten WAL und der Zeit, die es dauerte, remote geschrieben, geleert und wiedergegeben zu werden. Nullen in diesen 3 Spalten zu sehen bedeutet, dass die Primär- und die Standby-Datei synchron sind.

Das Äquivalent von pg_stat_replication auf der Standby-Seite heißt:pg_stat_wal_receiver: 

testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

Wenn keine Aktivität vorhanden ist und der Standby alles wiedergegeben hat, dann latest_end_lsn muss gleich sent_lsn sein auf der primären (und allen Zwischenprotokoll-Sequenznummern).

Ähnlich wie bei der physischen Replikation wird im Fall der logischen Replikation, bei der die Rolle des Primärservers vom Herausgeber und die Rolle des Standbyservers vom Abonnenten übernommen wird, natürlich die Rolle von pg_stat_wal_receiver übernommen wird von pg_stat_subscription übernommen . Wir können pg_stat_subscription abfragen wie folgt:

testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

Beachten Sie, dass die entsprechende Ansicht auf der Herausgeberseite dieselbe ist wie im Fall der physischen Replikation:pg_stat_replication .

Gesammelte Statistikansichten

pg_stat_archiver view hat eine Zeile, die Informationen über den Wal-Archivierer enthält. Wenn Sie in regelmäßigen Abständen einen Snapshot dieser Zeile erstellen, können Sie die Größe des WAL-Datenverkehrs zwischen diesen Intervallen berechnen. Außerdem gibt es Informationen über Fehler beim Archivieren von WAL-Dateien.

pg_stat_bgwriter view gibt sehr wichtige Informationen über das Verhalten von:

  • Der Checkpointer
  • Der Hintergrundautor
  • Die (Client-serving) Backends

Da diese Ansicht akkumulierte Daten seit dem letzten Zurücksetzen liefert, ist es sehr nützlich, eine weitere Tabelle mit Zeitstempeln mit periodischen Schnappschüssen von pg_stat_bgwriter zu erstellen , sodass es einfach ist, zwischen zwei Schnappschüssen eine inkrementelle Perspektive zu erhalten. Tuning ist eine Wissenschaft (oder Magie), und es erfordert umfangreiche Protokollierung und Überwachung sowie ein klares Verständnis der zugrunde liegenden Konzepte und PostgreSQL-Interna, um gute Ergebnisse zu erzielen, und diese Ansicht ist der Ausgangspunkt, um nach Dingen zu suchen wie:

  • Sind die checkpoints_timed die überwiegende Mehrheit der gesamten Checkpoints? Wenn nicht, müssen Maßnahmen ergriffen, Ergebnisse gemessen und der gesamte Prozess wiederholt werden, bis keine Verbesserungen mehr gefunden werden.
  • Sind die buffers_checkpoint eine gute Mehrheit gegenüber den anderen beiden Arten (buffers_clean aber am wichtigsten buffers_backend ) ? Wenn buffers_backend hoch ist, müssen wiederum bestimmte Konfigurationsparameter geändert, neue Messungen durchgeführt und neu bewertet werden.

Pg_stat_[user|sys|all]_tables

Die grundlegendste Verwendung dieser Ansichten besteht darin, zu überprüfen, ob unsere Vakuumstrategie wie erwartet funktioniert. Große Werte von toten Tupeln relativ zu lebenden Tupeln bedeuten ineffizientes Besaugen. Diese Ansichten bieten auch Informationen zu Seq- und Index-Scans und -Abrufen, Informationen zur Anzahl der eingefügten, aktualisierten, gelöschten Zeilen sowie HOT-Updates. Sie sollten versuchen, die Anzahl der HOT-Updates so hoch wie möglich zu halten, um die Leistung zu verbessern.

Pg_stat_[user|sys|all]_indexes

Hier speichert und zeigt das System Informationen zur individuellen Indexnutzung. Beachten Sie, dass idx_tup_read genauer ist als idx_tup_fetch. Nicht-PK/nicht eindeutige Indizes mit niedrigem idx_scan sollten zur Entfernung in Betracht gezogen werden, da sie nur HOT-Updates behindern. Wie im vorherigen Blog erwähnt, sollte eine Überindizierung vermieden werden, denn die Indizierung hat ihren Preis.

Pg_statio_[user|sys|all]_tables

In diesen Ansichten finden wir Informationen zur Leistung des Caches in Bezug auf Tabellenheap-Lesevorgänge, Index-Lesevorgänge und TOAST-Lesevorgänge. Eine einfache Abfrage zum Zählen des Prozentsatzes der Treffer und der Verteilung der Treffer auf die Tabellen wäre:

with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

Dies sagt uns, dass mindestens 50 % der Tabellen eine Trefferquote von über 96,93 % und 83,5 % der Tabellen eine Trefferquote von über 59,4 % aufweisen

Pg_statio_[user|sys|all]_indexes

Diese Ansicht enthält Blocklese-/Trefferinformationen für Indizes.

Pg_stat_database

Diese Ansicht enthält eine Zeile pro Datenbank. Es zeigt einige der Informationen der vorherigen Ansichten, die für die gesamte Datenbank aggregiert sind (gelesene Blöcke, getroffene Blöcke, Informationen zu Tups), einige Informationen, die für die gesamte Datenbank relevant sind (Gesamtxactions, temporäre Dateien, Konflikte, Deadclocks, Lese-/Schreibzeit) , und schließlich die Anzahl der aktuellen Backends.

Worauf Sie hier achten sollten, ist das Verhältnis von blks_hit/(blks_hit + blks_read) :Je höher der Wert, desto besser für die E/A des Systems. Fehlschläge sollten jedoch nicht unbedingt als Festplattenlesevorgänge angesehen werden, da sie möglicherweise sehr gut vom Filesys-Cache des Betriebssystems bedient wurden.

Ähnlich wie bei anderen oben erwähnten gesammelten Statistikansichten sollte man eine zeitgestempelte Version der pg_stat_database erstellen ansehen und sich die Unterschiede zwischen zwei aufeinanderfolgenden Schnappschüssen ansehen:

  • Nehmt die Zahl der Rollbacks zu?
  • Oder die Anzahl der begangenen Aktionen?
  • Bekommen wir viel mehr Konflikte als gestern (dies gilt für Standbys)?
  • Haben wir ungewöhnlich viele Deadlocks?

All das sind sehr wichtige Daten. Die ersten beiden könnten eine Änderung in einem Nutzungsmuster bedeuten, die erklärt werden muss. Eine hohe Anzahl von Konflikten kann bedeuten, dass die Replikation etwas optimiert werden muss. Eine hohe Anzahl von Deadlocks ist aus vielen Gründen schlecht. Nicht nur die Leistung ist niedrig, weil Transaktionen zurückgesetzt werden, sondern auch, wenn eine Anwendung unter Deadlocks in einer Single-Master-Topologie leidet, werden die Probleme nur verstärkt, wenn wir zu Multi-Master wechseln. In diesem Fall muss die Softwareentwicklungsabteilung die Codeteile neu schreiben, die die Deadlocks verursachen.

Schlösser

Verwandte Ressourcen ClusterControl für PostgreSQL Wie Sie Ihren vorhandenen Postgres-Server verwalten und überwachen Wie Sie die Leistung von PostgreSQL bewerten

Sperren ist ein sehr wichtiges Thema in PostgreSQL und verdient einen eigenen Blog. Nichtsdestotrotz muss die grundlegende Sperrenüberwachung auf die gleiche Weise durchgeführt werden wie die anderen oben vorgestellten Aspekte der Überwachung. pg_locks view bietet Echtzeit-Informationen zu den aktuellen Sperren im System. Wir können Sperren für lange Wartezeiten abfangen, indem wir log_lock_waits setzen , dann werden Informationen zu langen Wartezeiten im PgSQL-Protokoll protokolliert. Wenn wir ungewöhnlich hohe Sperren bemerken, die zu langen Wartezeiten führen, müssen die Softwareingenieure, wie im Fall der oben erwähnten Deadlocks, alle Codeteile überprüfen, die möglicherweise lange gehaltene Sperren verursachen, z. explizites Sperren in der Anwendung (LOCK TABLE oder SELECT … FOR UPDATE).

Ähnlich wie bei Deadlocks wird ein System mit kurzen Sperren leichter zu einem Multi-Master-Setup wechseln.