Klíčové věci ke sledování v PostgreSQL – Analýza vaší pracovní zátěže

Klíčové věci ke sledování v PostgreSQL – Analýza vaší pracovní zátěže

V počítačových systémech je monitorování procesem shromažďování metrik, analýzy, výpočtu statistik a generování souhrnů a grafů týkajících se výkonu nebo kapacity systému, stejně jako generování výstrah v případě neočekávaných problémů nebo selhání, které vyžadují okamžitou pozornost nebo akci. Monitorování má proto dvě použití:jedno pro analýzu a prezentaci historických dat, které nám pomáhají identifikovat střednědobé a dlouhodobé trendy v našem systému, a tím nám pomáhají plánovat upgrady, a druhé pro okamžitou akci v případě problémů.

Monitoring nám pomáhá identifikovat problémy a reagovat na tyto problémy týkající se široké škály oblastí, jako jsou:

• Infrastruktura/hardware (fyzický nebo virtuální)
• Síť
• Úložiště
• Systémový software
• Aplikační software
• Zabezpečení

Monitorování je hlavní součástí práce DBA. PostgreSQL je tradičně znám jako „nízkoúdržbový“ díky svému sofistikovanému designu, což znamená, že systém může žít s nízkou návštěvností ve srovnání s jinými alternativami. Nicméně u seriózních instalací, kde je klíčová vysoká dostupnost a výkon, musí být databázový systém pravidelně monitorován.

Role PostgreSQL DBA může posouvat na vyšší úrovně v rámci firemní hierarchie kromě čistě technické:kromě základního monitorování a analýzy výkonu musí být schopen odhalit změny ve vzorcích používání, identifikovat možné příčiny, ověřit předpoklady a nakonec přeložit zjištění v obchodních podmínkách. Například DBA musí být schopen identifikovat nějakou náhlou změnu v určité činnosti, která by mohla souviset s možnou bezpečnostní hrozbou. Role PostgreSQL DBA je tedy klíčovou rolí v rámci společnosti a musí úzce spolupracovat s ostatními vedoucími oddělení, aby bylo možné identifikovat a řešit problémy, které nastanou. Monitorování je velkou součástí této odpovědnosti.

PostgreSQL poskytuje mnoho předdefinovaných nástrojů, které nám pomáhají shromažďovat a analyzovat data. Navíc díky své rozšiřitelnosti poskytuje prostředky pro vývoj nových modulů do základního systému.

PostgreSQL je vysoce závislý na systému (hardwaru a softwaru), na kterém běží. Nemůžeme očekávat, že PostgreSQL server bude fungovat dobře, pokud se vyskytnou problémy v některé z důležitých komponent ve zbytku systému. Role PostgreSQL DBA se tedy překrývá s rolí sysadmina. Níže, když zkoumáme, co sledovat při monitorování PostgreSQL, narazíme na proměnné a metriky závislé na systému a také na konkrétní čísla PostgreSQL.

Monitoring není zadarmo. Společnost/organizace do toho musí vložit dobrou investici se závazkem řídit a udržovat celý proces monitorování. Také to mírně zatěžuje server PostgreSQL. Pokud je vše správně nakonfigurováno, není toho třeba se obávat, ale musíme mít na paměti, že to může být další způsob, jak systém zneužít.

Základy monitorování systému

Důležité proměnné v monitorování systému jsou:

• Využití CPU
• Využití sítě
• Místo na disku / využití disku
• Využití RAM
• IOPS disku
• Využití prostoru pro výměnu
• Chyby sítě

Zde je příklad ClusterControl zobrazující grafy pro některé kritické proměnné PostgreSQL pocházející z pg_stat_database a pg_stat_bgwriter (kterému se budeme věnovat v následujících odstavcích) při dvakrát spuštěném pgbench -c 64 -t 1000 pgbench:

Všimli jsme si, že v prvním běhu máme maximum při čtení bloků, ale během druhého běhu se blížíme k nule, protože všechny bloky se nacházejí ve sdílených_bufferech.

Dalšími zajímavými proměnnými jsou mimo jiné aktivita stránkování, přerušení, přepínání kontextu. V Linuxu/BSD a unixových nebo unixových systémech lze použít nepřeberné množství nástrojů. Některé z nich jsou:

• ps:pro seznam běžících procesů

• top/htop/systat:pro sledování využití systému (CPU / paměti)

• vmstat:pro obecné monitorování aktivity systému (včetně virtuální paměti)

• iostat/iotop/top -mio:pro monitorování IO

• ntop:pro monitorování sítě

Zde je příklad vmstat na FreeBSD boxu během dotazu, který vyžaduje nějaké čtení disku a také nějaké výpočty:

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

Při opakování dotazu bychom nezaznamenali žádný nový nárůst aktivity disku, protože tyto bloky disku by již byly v mezipaměti operačního systému. Ačkoli PostgreSQL DBA musí být schopen plně porozumět tomu, co se děje v základní infrastruktuře, kde databáze běží, složitější monitorování systému je obvykle úkolem systémového správce, protože toto je velké téma samo o sobě.

V linuxu velmi šikovná zkratka pro top obslužný program stiskne „C“, čímž se přepne zobrazení příkazového řádku procesů. PostgreSQL ve výchozím nastavení přepisuje příkazový řádek backendů aktuální aktivitou SQL, kterou právě provozují, a také uživatelem.

Základy monitorování PostgreSQL

Důležité proměnné v monitorování PostgreSQL jsou:

• Výkon mezipaměti vyrovnávací paměti (zásahy do mezipaměti vs. čtení disku)
• Počet odevzdání
• Počet připojení
• Počet relací
• Kontrolní body a statistiky bgwriter
• Vakua
• Zámky
• Replikace
• A v neposlední řadě dotazy

Obecně existují dva způsoby, jak v nastavení monitorování provádět sběr dat:

• Získávání dat prostřednictvím protokolu
• Získávání dat dotazováním systému PostgreSQL

Získávání dat na základě souboru protokolu závisí na (správně nakonfigurovaném) protokolu PostgreSQL. Tento druh logování můžeme použít pro „off-line“ zpracování dat. Monitorování založené na souborech protokolu je nejvhodnější, když je vyžadována minimální režie na server PostgreSQL a když se nestaráme o živá data nebo o získávání živých výstrah (ačkoli živé monitorování pomocí dat souboru protokolu může být možné např. přesměrováním protokolu postgresql na syslog a poté streamování syslog na jiný server určený pro zpracování protokolu).

Sběratel statistik PostgreSQL

PostgreSQL poskytuje bohatou sadu pohledů a funkcí snadno dostupných prostřednictvím subsystému Statistics Collector. Tato data jsou opět rozdělena do dvou kategorií:

• Dynamické informace o tom, co systém právě dělá.
• Statistiky nashromážděné od posledního resetování subsystému sběrače statistik.

Zobrazení dynamických statistik poskytují informace o aktuální aktivitě na proces (pg_stat_activity), stavu fyzické replikace (pg_stat_replication), stavu fyzického pohotovostního režimu (pg_stat_wal_receiver) nebo logického (pg_stat_subscription), ssl (pg_stat_ssl) a vakua (pg_stat_progress_vacuum).

Zobrazení shromážděných statistik poskytují informace o důležitých procesech na pozadí, jako je archivátor wal, bgwriter a databázové objekty:uživatelské nebo systémové tabulky, indexy, sekvence a funkce i samotné databáze.

Nyní by mělo být zcela zřejmé, že existuje několik způsobů, jak kategorizovat data související s monitorováním:

• Podle zdroje:
  • Systémové nástroje (ps, top, iotop atd.)
  • Soubor protokolu PgSQL
  • Databáze
    • Dynamické
    • Shromážděno
• Podle konkrétní operace databáze:
  • Vyrovnávací paměť
  • Závazky
  • Dotazy
  • Relace
  • Kontrolní body
  • Atd.

Po přečtení tohoto článku a experimentování s prezentovanými pojmy, koncepty a termíny byste měli být schopni vytvořit 2D matici se všemi možnými kombinacemi. Jako příklad lze konkrétní aktivitu PostgreSQL (příkaz SQL) nalézt pomocí:ps nebo top (systémové nástroje), souborů protokolu PostgreSQL, pg_stat_activity (dynamické zobrazení), ale také pomocí pg_stat_statements rozšíření nalezeného v contrib (zobrazení sebraných statistik) . Stejně tak informace o zámcích lze nalézt v souborech protokolu PostgreSQL, pg_locks a pg_stat_activity (uvedeno níže) pomocí wait_event a wait_event_type . Z tohoto důvodu je obtížné pokrýt rozsáhlou oblast monitorování jednorozměrným lineárním způsobem a autor riskuje, že kvůli tomu vytvoří pro čtenáře zmatek. Abychom tomu zabránili, pokryjeme monitorování zhruba sledováním průběhu oficiální dokumentace a přidáním souvisejících informací podle potřeby.

Zobrazení dynamických statistik

Pomocí pg_stat_activity jsme schopni vidět, jaká je aktuální aktivita různých backendových procesů. Pokud například spustíme následující dotaz na části tabulky s přibližně 3 miliony řádků:

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

A spusťte následující dotaz, jehož dokončení potřebuje několik sekund:

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

Otevřením nového terminálu a spuštěním následujícího dotazu, zatímco předchozí stále běží, dostaneme:

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

Pohled pg_stat_activity nám poskytuje informace o backendovém procesu, uživateli, klientovi, transakci, dotazu, stavu a také komplexní informace o stavu čekání na dotaz.

Ale proč 3 řady? Pokud lze ve verzích>=9.6 dotaz spustit paralelně nebo jeho části lze spustit paralelně a optimalizátor se domnívá, že paralelní provádění je nejrychlejší strategií, vytvoří Shromáždit nebo Gather Merge uzel a poté požaduje maximálně max_parallel_workers_per_gather pozadí pracovních procesů, což je ve výchozím nastavení 2, tedy 3 řádky, které vidíme ve výstupu výše. Pomocí parametru backend_type můžeme odlišit proces klientského backendu od pracovníka na pozadí sloupec. Chcete-li povolit zobrazení pg_stat_activity, musíte se ujistit, že parametr konfigurace systému track_activities je zapnuto. Pg_stat_activity poskytuje bohaté informace, aby bylo možné určit blokované dotazy pomocí sloupců wait_event_type a wait_event.

Propracovanější způsob monitorování výpisů je pomocí pg_stat_statements contrib rozšíření, zmíněný dříve. Na nejnovějším systému Linux (Ubuntu 17.10, PostgreSQL 9.6) to lze nainstalovat poměrně snadno:

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

Vytvořme tabulku s 100 000 řádky a poté resetujeme pg_stat_statements, restartujeme PostgreSQL server, provedeme výběr na této tabulce v (stále studeném) systému a pak uvidíme obsah pg_stat_statements pro select:

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

Nyní provedeme select * ještě jednou a pak se znovu podíváme do obsahu pg_stat_statements pro tento dotaz:

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

Podruhé tedy příkaz select najde všechny požadované bloky ve sdílených bufferech PostgreSQL a pg_stat_statements to hlásí pomocí shared_blks_hit . pg_stat_statements poskytuje informace o celkovém počtu volání příkazu, total_time, min_time, max_time a mean_time, což může být velmi užitečné při pokusu o analýzu zátěže vašeho systému. Pomalý dotaz, který je spouštěn velmi často, by měl vyžadovat okamžitou pozornost. Podobně může trvale nízká míra požadavků na server znamenat nutnost zkontrolovat shared_buffers nastavení.

pg_stat_replication poskytuje informace o aktuálním stavu replikace pro každého wal_sender. Předpokládejme, že jsme nastavili jednoduchou topologii replikace s naším primárním a jedním aktivním pohotovostním režimem, pak se můžeme zeptat na pg_stat_replication na primárním zařízení (totéž v pohotovostním režimu nepřinese žádné výsledky, pokud nenastavíme kaskádovou replikaci a tento konkrétní pohotovostní režim slouží jako upstream do dalších pohotovostních režimů po proudu) zobrazíte aktuální stav replikace:

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

4 sloupce sent_lsn , write_lsn , flush_lsn , replay_lsn sdělte nám přesnou pozici WAL v každé fázi procesu replikace ve vzdáleném pohotovostním režimu. Poté vytvoříme na primárním serveru nějaký hustý provoz příkazem jako:

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

A znovu se podívejte na 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

Nyní vidíme, že mezi primárním a pohotovostním režimem je zpoždění zobrazené v sent_lsn , write_lsn , flush_lsn , replay_lsn hodnoty. Od PgSQL 10.0 pg_stat_replication také ukazuje zpoždění mezi nedávno lokálně vyprázdněnou WAL a dobou, kterou zabralo vzdálené zapsání, vyprázdnění a přehrání. Vidíte-li v těchto 3 sloupcích nuly, znamená to, že primární a pohotovostní režim jsou synchronizovány.

Ekvivalent pg_stat_replication na straně pohotovostního režimu se nazývá: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=#

Když nedochází k žádné aktivitě a v pohotovostním režimu se vše přehrálo, pak latest_end_lsn musí být rovno sent_lsn na primárním (a všech mezilehlých sekvenčních číslech protokolu).

Podobně jako u fyzické replikace je v případě logické replikace, kde roli primárního přebírá vydavatel a roli pohotovostního režimu předplatitel, přirozeně role pg_stat_wal_receiver je převzato pomocí pg_stat_subscription . Můžeme se zeptat na pg_stat_subscription takto:

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

Všimněte si, že na straně vydavatele je odpovídající zobrazení stejné jako v případě fyzické replikace:pg_stat_replication .

Zobrazení shromážděných statistik

pg_stat_archiver view má jeden řádek, který poskytuje informace o archivátoru wal. Uchovávání snímku tohoto řádku v pravidelných intervalech vám umožní vypočítat velikost provozu WAL mezi těmito intervaly. Také poskytuje informace o selháních při archivaci souborů WAL.

pg_stat_bgwriter view poskytuje velmi důležité informace o chování:

• Kontrolní ukazatel
• Autor v pozadí
• Backendy (obsluhování klientů)

Protože toto zobrazení poskytuje kumulativní data od posledního resetování, je velmi užitečné vytvořit další tabulku s časovým razítkem s pravidelnými snímky pg_stat_bgwriter , takže bude snadné získat přírůstkovou perspektivu mezi dvěma snímky. Ladění je věda (nebo magie) a vyžaduje rozsáhlé protokolování a monitorování, stejně jako jasné pochopení základních konceptů a vnitřních prvků PostgreSQL, aby bylo možné dosáhnout dobrých výsledků, a tento pohled je místem, kde začít, hledat věci jako:

• Jsou checkpoints_timed drtivá většina z celkového počtu kontrolních bodů? Pokud ne, je třeba přijmout opatření, změřit výsledky a celý proces opakovat, dokud nenajdete žádné zlepšení.
• Jsou kontrolním bodem vyrovnávacích pamětí dobrá většina oproti ostatním dvěma druhům (buffers_clean ale hlavně buffers_backend ) ? Pokud jsou buffers_backend vysoké, pak je opět nutné změnit určité konfigurační parametry, provést nová měření a přehodnotit.

Pg_stat_[user|sys|all]_tables

Nejzákladnějším použitím těchto pohledů je ověřit, že naše vakuová strategie funguje podle očekávání. Velké hodnoty mrtvých n-tic ve srovnání s živými n-ticemi znamenají neefektivní vysávání. Tyto pohledy také poskytují informace o prohledávání a načítání seq vs indexu, informace o počtu vložených, aktualizovaných, odstraněných a také HOT aktualizací. Měli byste se snažit udržovat počet HOT aktualizací co nejvyšší, abyste zlepšili výkon.

Pg_stat_[user|sys|všechny]_indexy

Zde systém ukládá a zobrazuje informace o použití jednotlivých indexů. Jedna věc, kterou je třeba mít na paměti, je, že idx_tup_read je přesnější než idx_tup_fetch. Jiné než PK/nejedinečné indexy s nízkým idx_scan by se mělo zvážit odstranění, protože brání pouze HOT aktualizacím. Jak bylo zmíněno v předchozím blogu, přeindexování je třeba se vyhnout, indexování něco stojí.

Pg_statio_[user|sys|all]_tables

V těchto pohledech můžeme najít informace o výkonu mezipaměti, pokud jde o čtení haldy tabulky, čtení indexu a čtení TOAST. Jednoduchý dotaz pro výpočet procenta požadavků a rozložení požadavků v tabulkách by bylo:

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

To nám říká, že alespoň 50 % tabulek má míru návštěvnosti vyšší než 96,93 % a 83,5 % tabulek má míru návštěvnosti lepší než 59,4 %

Pg_statio_[user|sys|všechny]_indexy

Toto zobrazení obsahuje informace o čtení/požadavcích na bloky pro indexy.

Pg_stat_database

Toto zobrazení obsahuje jeden řádek na databázi. Zobrazuje některé informace z předchozích pohledů agregované do celé databáze (čtení bloků, zásah bloků, informace o tupsech), některé informace relevantní pro celou databázi (celkové xakce, dočasné soubory, konflikty, mrtvé hodiny, doba čtení/zápisu) a nakonec počet aktuálních backendů.

Zde je třeba hledat poměr blks_hit/(blks_hit + blks_read) :čím vyšší hodnota, tím lepší pro I/O systému. Chyby by však neměly být nutně zahrnuty do čtení disku, protože je mohla velmi dobře obsloužit mezipaměť filesys operačního systému.

Podobně jako u jiných shromážděných statistických zobrazení uvedených výše, je třeba vytvořit verzi pg_stat_database s časovým razítkem zobrazit a mít přehled o rozdílech mezi dvěma po sobě jdoucími snímky:

• Zvyšuje se počet vrácení zpět?
• Nebo počet potvrzených xakcí?
• Dostáváme mnohem více konfliktů než včera (to platí pro pohotovostní režimy)?
• Máme abnormálně vysoký počet zablokování?

To vše jsou velmi důležitá data. První dva mohou znamenat určitou změnu v určitém vzoru používání, což je třeba vysvětlit. Vysoký počet konfliktů může znamenat, že replikace vyžaduje určité ladění. Vysoký počet uváznutí je špatný z mnoha důvodů. Nejenom, že výkon je nízký, protože transakce jsou vráceny zpět, ale také pokud aplikace trpí uváznutím v jediné hlavní topologii, problémy se jen zesílí, pokud přejdeme na multi-master. V tomto případě musí oddělení softwarového inženýrství přepsat části kódu, které způsobují uváznutí.

Zámky

Zamykání je v PostgreSQL velmi důležité téma a zaslouží si vlastní blog(y). Nicméně základní monitorování zámků musí být provedeno stejným způsobem jako ostatní aspekty monitorování uvedené výše. pg_locks zobrazení poskytuje informace v reálném čase o aktuálních zámcích v systému. Nastavením log_lock_waits můžeme zachytit dlouhé čekání , pak budou informace o dlouhém čekání zaznamenány do protokolu PgSQL. Pokud zaznamenáme nezvykle vysoké zamykání, které má za následek dlouhé čekání, pak znovu, jako v případě výše zmíněných zablokování, musí softwaroví inženýři zkontrolovat všechny části kódu, které by mohly způsobit dlouhé zablokování, např. explicitní uzamčení v aplikaci (LOCK TABLE nebo SELECT … FOR UPDATE).

Podobně jako v případě uváznutí se systém s krátkými zámky snáze přesune na nastavení s více mastery.