PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Cose chiave da monitorare in PostgreSQL:analisi del carico di lavoro

Cose chiave da monitorare in PostgreSQL:analisi del carico di lavoro

Nei sistemi informatici, il monitoraggio è il processo di raccolta di metriche, analisi, calcolo di statistiche e generazione di riepiloghi e grafici relativi alle prestazioni o alla capacità di un sistema, nonché alla generazione di avvisi in caso di problemi o guasti imprevisti che richiedono attenzione o azione immediata. Pertanto, il monitoraggio ha due usi:uno per l'analisi e la presentazione dei dati storici che ci aiutano a identificare le tendenze a medio e lungo termine all'interno del nostro sistema e quindi ci aiutano a pianificare gli aggiornamenti, e un secondo per un'azione immediata in caso di problemi.

Il monitoraggio ci aiuta a identificare i problemi ea reagire a quei problemi che riguardano un'ampia gamma di campi come:

  • Infrastruttura/Hardware (fisico o virtuale)
  • Rete
  • Stoccaggio
  • Software di sistema
  • Software applicativo
  • Sicurezza

Il monitoraggio è una parte importante del lavoro di un DBA. PostgreSQL, tradizionalmente, è noto per essere "a bassa manutenzione" grazie al suo design sofisticato e questo significa che il sistema può vivere con una bassa frequenza rispetto ad altre alternative. Tuttavia, per installazioni serie in cui l'elevata disponibilità e le prestazioni sono di fondamentale importanza, il sistema di database deve essere monitorato regolarmente.

Il ruolo del DBA PostgreSQL può salire a livelli più alti all'interno della gerarchia aziendale oltre che strettamente tecnico:oltre al monitoraggio di base e all'analisi delle prestazioni, deve essere in grado di individuare i cambiamenti nei modelli di utilizzo, identificare le possibili cause, verificare le ipotesi e infine tradurre le risultati in termini commerciali. Ad esempio, il DBA deve essere in grado di identificare qualche cambiamento improvviso in una determinata attività che potrebbe essere collegato a una possibile minaccia alla sicurezza. Quindi il ruolo del DBA PostgreSQL è un ruolo chiave all'interno dell'azienda e deve lavorare a stretto contatto con altri capi dipartimento per identificare e risolvere i problemi che si presentano. Il monitoraggio è una parte importante di questa responsabilità.

PostgreSQL fornisce molti strumenti pronti all'uso per aiutarci a raccogliere e analizzare i dati. Inoltre, grazie alla sua estensibilità, fornisce i mezzi per sviluppare nuovi moduli nel sistema centrale.

PostgreSQL dipende fortemente dal sistema (hardware e software) su cui gira. Non possiamo aspettarci che un server PostgreSQL funzioni bene se ci sono problemi in uno qualsiasi dei componenti vitali nel resto del sistema. Quindi il ruolo del DBA PostgreSQL si sovrappone al ruolo dell'amministratore di sistema. Di seguito, mentre esaminiamo cosa guardare nel monitoraggio di PostgreSQL, incontreremo sia variabili e metriche dipendenti dal sistema, sia cifre specifiche di PostgreSQL.

Il monitoraggio non è gratuito. Un buon investimento deve essere investito dall'azienda/organizzazione con l'impegno di gestire e mantenere l'intero processo di monitoraggio. Aggiunge anche un leggero carico sul server PostgreSQL. Questo è poco di cui preoccuparsi se tutto è configurato correttamente, ma dobbiamo tenere presente che questo può essere un altro modo per abusare del sistema.

Nozioni di base sul monitoraggio del sistema

Le variabili importanti nel monitoraggio del sistema sono:

  • Utilizzo CPU
  • Utilizzo della rete
  • Spazio su disco/Utilizzo del disco
  • Utilizzo della RAM
  • IOPS disco
  • Scambia l'utilizzo dello spazio
  • Errori di rete

Ecco un esempio di ClusterControl che mostra i grafici per alcune variabili PostgreSQL critiche provenienti da pg_stat_database e pg_stat_bgwriter (che tratteremo nei paragrafi seguenti) durante l'esecuzione di pgbench -c 64 -t 1000 pgbench due volte:

Notiamo che abbiamo un picco sui blocchi letti nella prima esecuzione, ma ci avviciniamo allo zero durante la seconda poiché tutti i blocchi si trovano in shared_buffers.

Altre variabili di interesse sono l'attività di paging, gli interrupt, i cambi di contesto, tra gli altri. C'è una pletora di strumenti da utilizzare in Linux/BSD e sistemi unix o simili a unix. Alcuni di loro sono:

  • ps:per un elenco dei processi in esecuzione

  • top/htop/systat:per il monitoraggio dell'utilizzo del sistema (CPU/memoria)

  • vmstat:per il monitoraggio dell'attività generale del sistema (compresa la memoria virtuale)

  • iostat/iotop/top -mio:per il monitoraggio IO

  • ntop:per il monitoraggio della rete

Ecco un esempio di vmstat su un box di FreeBSD durante una query che richiede alcune letture del disco e anche un po' di calcolo:

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

Ripetendo la query non noteremo alcun nuovo scoppio nell'attività del disco poiché quei blocchi di disco sarebbero già nella cache del sistema operativo. Sebbene il DBA di PostgreSQL debba essere in grado di comprendere appieno ciò che sta accadendo nell'infrastruttura sottostante in cui viene eseguito il database, il monitoraggio del sistema più complesso è solitamente un compito per l'amministratore di sistema, poiché questo è un argomento ampio in sé.

In Linux, una scorciatoia molto utile per il top l'utilità sta premendo "C", che alterna mostrando la riga di comando dei processi. PostgreSQL per impostazione predefinita riscrive la riga di comando dei backend con l'effettiva attività SQL in esecuzione al momento e anche l'utente.

Nozioni di base sul monitoraggio di PostgreSQL

Le variabili importanti nel monitoraggio di PostgreSQL sono:

  • Prestazioni della cache del buffer (riscontri della cache rispetto alle letture del disco)
  • Numero di commit
  • Numero di connessioni
  • Numero di sessioni
  • Punti di controllo e statistiche di bgwriter
  • Aspiratori
  • Blocca
  • Replica
  • E, ultimo ma non meno importante, le domande

In genere ci sono due modi in una configurazione di monitoraggio per eseguire la raccolta dei dati:

  • Per acquisire dati tramite un Log
  • Per acquisire dati interrogando il sistema PostgreSQL

L'acquisizione dei dati basata su file di registro dipende dal registro PostgreSQL (correttamente configurato). Possiamo utilizzare questo tipo di registrazione per l'elaborazione "off-line" dei dati. Il monitoraggio basato su file di registro è più adatto quando è richiesto un sovraccarico minimo per il server PostgreSQL e quando non ci interessano i dati in tempo reale o la ricezione di avvisi in tempo reale (sebbene il monitoraggio in tempo reale utilizzando i dati dei file di registro possa essere possibile, ad esempio, indirizzando il log postgresql a syslog e quindi eseguire lo streaming di syslog su un altro server dedicato all'elaborazione dei registri).

Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaper

Collettore di statistiche PostgreSQL

PostgreSQL fornisce un ricco set di viste e funzioni prontamente disponibili tramite il sottosistema Statistics Collector. Anche in questo caso quei dati sono divisi in due categorie:

  • Informazioni dinamiche su ciò che il sistema sta facendo in questo momento.
  • Statistiche accumulate dall'ultima reimpostazione del sottosistema di raccolta delle statistiche.

Viste statistiche dinamiche fornire informazioni sull'attività corrente per processo (pg_stat_activity), lo stato della replica fisica (pg_stat_replication), lo stato di standby fisico (pg_stat_wal_receiver) o logico (pg_stat_subscription), ssl (pg_stat_ssl) e vuoto (pg_stat_progress_vacuum).

Visualizzazioni statistiche raccolte fornire informazioni su importanti processi in background come wal archiver, bgwriter e oggetti database:tabelle utente o di sistema, indici, sequenze e funzioni, nonché i database stessi.

A questo punto dovrebbe essere abbastanza ovvio che esistono diversi modi per classificare i dati relativi al monitoraggio:

  • Per fonte:
    • Strumenti di sistema (ps, top, iotop, ecc.)
    • File di registro PgSQL
    • Banca dati
      • Dinamico
      • Raccolti
  • Per operazione specifica del database:
    • Cache del buffer
    • Si impegna
    • Query
    • Sessioni
    • Punti di controllo
    • Ecc

Dopo aver letto questo articolo e aver sperimentato le nozioni, i concetti ei termini presentati, dovresti essere in grado di creare una matrice 2D con tutte le possibili combinazioni. Ad esempio, l'attività specifica di PostgreSQL (comando SQL) può essere trovata utilizzando:ps o top (utilità di sistema), i file di registro di PostgreSQL, pg_stat_activity (vista dinamica), ma anche utilizzando pg_stat_statements un'estensione trovata in contrib (vista statistiche raccolte) . Allo stesso modo, le informazioni sui blocchi possono essere trovate nei file di registro di PostgreSQL, pg_locks e pg_stat_activity (presentato appena sotto) usando wait_event e wait_event_type . Per questo motivo, è difficile coprire la vasta area del monitoraggio in modo lineare unidimensionale e l'autore rischia di creare confusione nel lettore per questo motivo. Per evitare ciò, tratteremo il monitoraggio in modo approssimativo seguendo il corso della documentazione ufficiale e aggiungendo le informazioni correlate secondo necessità.

Viste statistiche dinamiche

Utilizzando pg_stat_activity siamo in grado di vedere qual è l'attività corrente dei vari processi di back-end. Ad esempio, se eseguiamo la seguente query su parti di tabella con circa 3 milioni di righe:

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                   |           |          |

Ed eseguiamo la seguente query, che richiede alcuni secondi per essere completata:

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

Aprendo un nuovo terminale ed eseguendo la seguente query, mentre la precedente è ancora in esecuzione, otteniamo:

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

La visualizzazione pg_stat_activity ci fornisce informazioni sul processo di back-end, l'utente, il client, la transazione, la query, lo stato, nonché informazioni complete sullo stato di attesa della query.

Ma perché 3 righe? Nelle versioni>=9.6, se una query può essere eseguita in parallelo o parti di essa possono essere eseguite in parallelo e l'ottimizzatore ritiene che l'esecuzione parallela sia la strategia più veloce, crea un Raccolta o Raccogli unione nodo e quindi richiede al massimo max_parallel_workers_per_gather processi di lavoro in background, che per impostazione predefinita è 2, da cui le 3 righe che vediamo nell'output sopra. Possiamo distinguere il processo di back-end del client dal lavoratore in background utilizzando il backend_type colonna. Per abilitare la visualizzazione pg_stat_activity dovrai assicurarti che il parametro di configurazione del sistema track_activities è acceso. pg_stat_activity fornisce informazioni dettagliate per determinare le query bloccate mediante l'uso delle colonne wait_event_type e wait_event.

Un modo più raffinato per monitorare le dichiarazioni è tramite pg_stat_statements estensione contrib, menzionata in precedenza. Su un sistema Linux recente (Ubuntu 17.10, PostgreSQL 9.6), questo può essere installato abbastanza facilmente:

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

Creiamo una tabella con 100000 righe, quindi reimpostare pg_stat_statements, riavviare il server PostgreSQL, eseguire una selezione su questa tabella sul sistema (ancora freddo), quindi vedere il contenuto di pg_stat_statements per la selezione:

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=#

Ora eseguiamo il select * ancora una volta e poi guardiamo di nuovo nel contenuto di pg_stat_statements per questa query:

[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)

Quindi, la seconda volta l'istruzione select trova tutti i blocchi richiesti nei buffer condivisi di PostgreSQL e pg_stat_statements lo segnala tramite shared_blks_hit . pg_stat_statements fornisce informazioni sul numero totale di chiamate di un'istruzione, total_time, min_time, max_time e mean_time, che possono essere estremamente utili quando si tenta di analizzare il carico di lavoro del sistema. Una query lenta eseguita molto frequentemente dovrebbe richiedere un'attenzione immediata. Allo stesso modo, percentuali di successo costantemente basse possono significare la necessità di rivedere i buffer_condivisi impostazione.

pg_stat_replication fornisce informazioni sullo stato corrente della replica per ogni wal_sender. Supponiamo di aver impostato una semplice topologia di replica con il nostro primario e uno hot standby, quindi possiamo interrogare pg_stat_replication sul primario (fare lo stesso in standby non produrrà risultati a meno che non abbiamo impostato la replica a cascata e questo specifico standby funge da upstream ad altri standby a valle) per vedere lo stato corrente della replica:

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

Le 4 colonne sent_lsn , write_lsn , flush_lsn , replay_lsn dirci l'esatta posizione WAL in ogni fase del processo di replica in standby remoto. Quindi creiamo del traffico intenso sul primario con un comando come:

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

E guarda di nuovo pg_stat_replication:

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

Ora vediamo che abbiamo un ritardo tra il primario e lo standby rappresentato in sent_lsn , write_lsn , flush_lsn , replay_lsn valori. A partire da PgSQL 10.0, pg_stat_replication mostra anche il ritardo tra un WAL scaricato di recente in locale e il tempo impiegato rispettivamente per essere scritto, scaricato e riprodotto in remoto. Vedere valori null in quelle 3 colonne significa che il primario e lo standby sono sincronizzati.

L'equivalente di pg_stat_replication sul lato standby viene chiamato: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=#

Quando non c'è attività e lo standby ha riprodotto tutto, allora latest_end_lsn deve essere uguale a sent_lsn sul primario (e su tutti i numeri di sequenza del registro intermedio).

Analogamente alla replica fisica, nel caso della replica logica, dove il ruolo di primario è assunto dall'editore, e il ruolo di standby è assunto dall'abbonato, naturalmente il ruolo di pg_stat_wal_receiver è preso da pg_stat_subscription . Possiamo interrogare pg_stat_subscription come segue:

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

Si noti che sul lato editore, la visualizzazione corrispondente è la stessa del caso della replica fisica:pg_stat_replication .

Viste statistiche raccolte

pg_stat_archiver view ha una riga che fornisce informazioni sull'archiviatore wal. Mantenere un'istantanea di questa riga a intervalli regolari consente di calcolare la dimensione del traffico WAL tra quegli intervalli. Fornisce inoltre informazioni sugli errori durante l'archiviazione dei file WAL.

pg_stat_bgwriter view fornisce informazioni molto importanti sul comportamento di:

  • Il checkpoint
  • Lo scrittore in background
  • I backend (servizio client)

Poiché questa vista fornisce dati cumulativi dall'ultimo ripristino, è molto utile creare un'altra tabella con timestamp con snapshot periodici di pg_stat_bgwriter , in modo che sia facile ottenere una prospettiva incrementale tra due snapshot. L'ottimizzazione è una scienza (o magia) e richiede una registrazione e un monitoraggio approfonditi, nonché una chiara comprensione dei concetti sottostanti e degli interni di PostgreSQL per ottenere buoni risultati, e questa vista è da dove iniziare, cercando cose come:

  • I punti_di_controllo sono scaduti la stragrande maggioranza dei posti di blocco totali? In caso contrario, è necessario intraprendere azioni, misurare i risultati e ripetere l'intero processo fino a quando non vengono rilevati miglioramenti.
  • Sono i buffers_checkpoint una buona maggioranza rispetto agli altri due tipi (buffers_clean ma soprattutto buffers_backend ) ? Se i buffers_backend sono alti, di nuovo, alcuni parametri di configurazione devono essere modificati, nuove misurazioni da prendere e rivalutare.

Pg_stat_[user|sys|all]_tables

L'uso più basilare di queste viste è verificare che la nostra strategia del vuoto funzioni come previsto. Valori elevati di tuple morte rispetto a tuple vive indicano un'aspirazione inefficiente. Tali visualizzazioni forniscono anche informazioni su scansioni e recuperi di seq e indice, informazioni sul numero di righe inserite, aggiornate, eliminate e aggiornamenti HOT. Dovresti cercare di mantenere il numero di aggiornamenti HOT più alto possibile per migliorare le prestazioni.

Pg_stat_[user|sys|all]_indexes

Qui il sistema memorizza e mostra le informazioni sull'utilizzo dell'indice individuale. Una cosa da tenere a mente è che idx_tup_read è più accurato di idx_tup_fetch. Indici non PK/ non univoci con idx_scan basso dovrebbero essere presi in considerazione per la rimozione, poiché ostacolano solo gli aggiornamenti HOT. Come accennato nel blog precedente, l'indicizzazione eccessiva dovrebbe essere evitata, l'indicizzazione ha un costo.

Pg_statio_[user|sys|all]_tables

In queste viste possiamo trovare informazioni sulle prestazioni della cache per quanto riguarda le letture dell'heap delle tabelle, le letture degli indici e le letture TOAST. Una semplice query per contare la percentuale di hit e la distribuzione degli hit tra le tabelle sarebbe:

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

Questo ci dice che almeno il 50% delle tabelle ha una percentuale di successo superiore al 96,93% e l'83,5% delle tabelle ha una percentuale di successo migliore del 59,4%

Pg_statio_[user|sys|all]_indexes

Questa vista contiene informazioni di lettura/risultato del blocco per gli indici.

Pg_stat_database

Questa vista contiene una riga per database. Mostra alcune delle informazioni delle viste precedenti aggregate all'intero database (blocchi letti, blocchi colpiti, informazioni sui tups), alcune informazioni relative all'intero database (totali xazioni, file temporanei, conflitti, deadclock, tempo di lettura/scrittura) e infine il numero di backend correnti.

Le cose da cercare qui sono il rapporto tra blks_hit/(blks_hit + blks_read) :maggiore è il valore, migliore sarà l'I/O del sistema. Tuttavia, gli errori non dovrebbero essere necessariamente presi in considerazione per le letture del disco poiché potrebbero essere stati serviti molto bene dalla cache dei filesys del sistema operativo.

Analogamente ad altre viste statistiche raccolte menzionate sopra, è necessario creare una versione con timestamp del pg_stat_database visualizzare e visualizzare le differenze tra due istantanee consecutive:

  • Il numero di rollback è in aumento?
  • O il numero di xazioni impegnate?
  • Stiamo ricevendo molti più conflitti rispetto a ieri (questo vale per gli standby)?
  • Abbiamo un numero anormalmente elevato di deadlock?

Tutti questi sono dati molto importanti. I primi due potrebbero significare qualche cambiamento in qualche modello di utilizzo, che deve essere spiegato. Un numero elevato di conflitti potrebbe significare che la replica necessita di una messa a punto. Un numero elevato di deadlock è negativo per molte ragioni. Non solo le prestazioni sono basse perché le transazioni vengono annullate, ma anche se un'applicazione soffre di deadlock in una topologia master singolo, i problemi verranno amplificati solo se passiamo al multi-master. In questo caso, il reparto di ingegneria del software deve riscrivere i pezzi di codice che causano i deadlock.

Blocca

Risorse correlate ClusterControl per PostgreSQL Come gestire e monitorare il server Postgres esistente Come eseguire il benchmark delle prestazioni di PostgreSQL

Il blocco è un argomento molto importante in PostgreSQL e merita i propri blog. Tuttavia, il monitoraggio di base delle serrature deve essere eseguito allo stesso modo degli altri aspetti del monitoraggio presentati sopra. pg_locks view fornisce informazioni in tempo reale sui blocchi correnti nel sistema. Potremmo intercettare blocchi di lunga attesa impostando log_lock_waits , le informazioni sulle lunghe attese verranno registrate nel registro PgSQL. Se notiamo un blocco elevato insolito che si traduce in lunghe attese, come nel caso dei deadlock sopra menzionati, gli ingegneri del software devono rivedere tutti i pezzi di codice che potrebbero causare blocchi a lungo termine, ad es. blocco esplicito nell'applicazione (LOCK TABLE o SELECT … FOR UPDATE).

Analogamente al caso dei deadlock, un sistema con lock brevi passerà più facilmente a una configurazione multi-master.