Belangrijkste dingen om te controleren in PostgreSQL - Uw werklast analyseren
In computersystemen is monitoring het proces van het verzamelen van meetgegevens, het analyseren, berekenen van statistieken en het genereren van samenvattingen en grafieken met betrekking tot de prestaties of de capaciteit van een systeem, evenals het genereren van waarschuwingen in geval van onverwachte problemen of storingen die onmiddellijke aandacht of actie vereisen. Daarom heeft monitoring twee toepassingen:een voor analyse en presentatie van historische gegevens die ons helpen trends op middellange en lange termijn binnen ons systeem te identificeren en ons zo te helpen bij het plannen van upgrades, en een tweede voor onmiddellijke actie in geval van problemen.
Monitoring helpt ons bij het identificeren van problemen en het reageren op deze problemen op een groot aantal gebieden, zoals:
- Infrastructuur/Hardware (fysiek of virtueel)
- Netwerk
- Opslag
- Systeemsoftware
- Applicatiesoftware
- Beveiliging
Monitoring is een belangrijk onderdeel van het werk van een DBA. PostgreSQL staat van oudsher bekend als "onderhoudsarm" dankzij het geavanceerde ontwerp en dit betekent dat het systeem kan leven met een lage opkomst in vergelijking met andere alternatieven. Voor serieuze installaties waarbij hoge beschikbaarheid en prestaties van essentieel belang zijn, moet het databasesysteem echter regelmatig worden gecontroleerd.
De rol van de PostgreSQL DBA kan naast strikt technisch ook naar hogere niveaus binnen de hiërarchie van het bedrijf gaan:afgezien van basisbewaking en prestatieanalyse, moet hij in staat zijn om veranderingen in gebruikspatronen te herkennen, de mogelijke oorzaken te identificeren, de aannames te verifiëren en uiteindelijk de bevindingen in zakelijke termen. De DBA moet bijvoorbeeld in staat zijn om een plotselinge verandering in een bepaalde activiteit te identificeren die mogelijk verband houdt met een mogelijke veiligheidsdreiging. De rol van de PostgreSQL DBA is dus een sleutelrol binnen het bedrijf en moet nauw samenwerken met andere afdelingshoofden om problemen die zich voordoen te identificeren en op te lossen. Monitoring is een groot deel van deze verantwoordelijkheid.
PostgreSQL biedt veel kant-en-klare tools waarmee we gegevens kunnen verzamelen en analyseren. Bovendien biedt het vanwege zijn uitbreidbaarheid de middelen om nieuwe modules in het kernsysteem te ontwikkelen.
PostgreSQL is sterk afhankelijk van het systeem (hardware en software) waarop het draait. We kunnen niet verwachten dat een PostgreSQL-server goed presteert als er problemen zijn in een van de vitale componenten in de rest van het systeem. Dus de rol van de PostgreSQL DBA overlapt met de rol van de systeembeheerder. Hieronder, terwijl we onderzoeken wat we moeten bekijken in PostgreSQL-monitoring, zullen we zowel systeemafhankelijke variabelen en statistieken tegenkomen als de specifieke cijfers van PostgreSQL.
Monitoring is niet gratis. Er moet een goede investering in worden gedaan door het bedrijf/de organisatie met een commitment om het hele monitoringproces te beheren en te onderhouden. Het voegt ook een lichte belasting toe aan de PostgreSQL-server. Dit is weinig om je zorgen over te maken als alles correct is geconfigureerd, maar we moeten er rekening mee houden dat dit een andere manier kan zijn om het systeem te misbruiken.
Basisbeginselen van systeembewaking
Belangrijke variabelen in Systeembewaking zijn:
- CPU-gebruik
- Netwerkgebruik
- Schijfruimte/schijfgebruik
- RAM-gebruik
- Schijf-IOPS
- Ruimtegebruik wisselen
- Netwerkfouten
Hier is een voorbeeld van ClusterControl die grafieken toont voor enkele kritieke PostgreSQL-variabelen afkomstig van pg_stat_database en pg_stat_bgwriter (die we in de volgende paragrafen zullen behandelen) terwijl pgbench -c 64 -t 1000 pgbench tweemaal wordt uitgevoerd:
We merken dat we een piek hebben in het aantal gelezen blokken in de eerste run, maar we komen dicht bij nul tijdens de tweede run omdat alle blokken worden gevonden in shared_buffers.
Andere interessante variabelen zijn onder andere paging-activiteit, interrupts, context-switches. Er is een overvloed aan tools om te gebruiken in Linux/BSD's en Unix of Unix-achtige systemen. Sommigen van hen zijn:
-
ps:voor een lijst van de lopende processen
-
top/htop/systat:voor monitoring van systeemgebruik (CPU / geheugen)
-
vmstat:voor algemene systeemactiviteit (inclusief virtueel geheugen) monitoring
-
iostat/iotop/top -mio:voor IO-bewaking
-
ntop:voor netwerkbewaking
Hier is een voorbeeld van vmstat op een FreeBSD-box tijdens een query die enkele schijflezingen en ook enige berekening vereist:
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 95Als we de vraag herhalen, zouden we geen nieuwe burst in schijfactiviteit opmerken, omdat die schijfblokken zich al in de cache van het besturingssysteem zouden bevinden. Hoewel de PostgreSQL DBA volledig moet kunnen begrijpen wat er gebeurt in de onderliggende infrastructuur waar de database draait, is complexere systeembewaking meestal een taak voor de systeembeheerder, aangezien dit een groot onderwerp op zich is.
In linux, een erg handige sneltoets voor de top hulpprogramma drukt op "C", waardoor de opdrachtregel van de processen wordt weergegeven. PostgreSQL herschrijft standaard de opdrachtregel van de backends met de daadwerkelijke SQL-activiteit die ze op dat moment uitvoeren en ook met de gebruiker.
Basisprincipes van PostgreSQL-controle
Belangrijke variabelen in PostgreSQL-monitoring zijn:
- Buffercacheprestaties (cachehits versus schijflezen)
- Aantal toezeggingen
- Aantal verbindingen
- Aantal sessies
- Checkpoints en bgwriter-statistieken
- Stofzuigers
- Sloten
- Replicatie
- En last but not least, vragen
Over het algemeen zijn er twee manieren in een bewakingsconfiguratie om gegevensverzameling uit te voeren:
- Gegevens verkrijgen via een logboek
- Om gegevens te verkrijgen door het PostgreSQL-systeem op te vragen
Op logbestanden gebaseerde data-acquisitie is afhankelijk van het (goed geconfigureerde) PostgreSQL-logboek. Dit soort logging kunnen we gebruiken voor het “offline” verwerken van de gegevens. Op logbestanden gebaseerde monitoring is het meest geschikt wanneer minimale overhead naar de PostgreSQL-server is vereist en wanneer we niet geïnteresseerd zijn in live gegevens of om live waarschuwingen te krijgen (hoewel live monitoring met behulp van logbestandgegevens mogelijk kan zijn door bijvoorbeeld postgresql-log naar syslog te leiden en vervolgens syslog streamen naar een andere server die speciaal is bedoeld voor logverwerking).
Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaperPostgreSQL-statistiekenverzamelaar
PostgreSQL biedt een uitgebreide reeks weergaven en functies die direct beschikbaar zijn via het subsysteem Statistics Collector. Ook deze gegevens zijn weer onderverdeeld in twee categorieën:
- Dynamische informatie over wat het systeem op dit moment doet.
- Statistieken verzameld sinds het subsysteem voor het verzamelen van statistieken voor het laatst is gereset.
Dynamische statistiekenweergaven geef informatie over huidige activiteit per proces (pg_stat_activity), status van fysieke replicatie (pg_stat_replication), status van fysieke standby (pg_stat_wal_receiver) of logisch (pg_stat_subscription), ssl (pg_stat_ssl) en vacuüm (pg_stat_progress_vacuum).
Verzamelde statistiekenweergaven geef informatie over belangrijke achtergrondprocessen zoals de wal-archiver, de bgwriter en database-objecten:gebruikers- of systeemtabellen, indexen, sequenties en functies, evenals de databases zelf.
Het zou inmiddels duidelijk moeten zijn dat er meerdere manieren zijn om gegevens met betrekking tot monitoring te categoriseren:
- Op bron:
- Systeemhulpmiddelen (ps, top, iotop, enz.)
- PgSQL-logbestand
- Database
- Dynamisch
- Verzameld
- Door specifieke databasebewerking:
- Buffercache
- Toezegging
- Vragen
- Sessies
- Checkpoints
- Enz.
Na het lezen van dit artikel en het experimenteren met de gepresenteerde begrippen, concepten en termen, zou je in staat moeten zijn om een 2D-matrix te maken met alle mogelijke combinaties. De specifieke PostgreSQL-activiteit (SQL-opdracht) kan bijvoorbeeld worden gevonden met:ps of top (systeemhulpprogramma's), de PostgreSQL-logbestanden, pg_stat_activity (dynamische weergave), maar ook met behulp van pg_stat_statements een extensie gevonden in contrib (weergave verzamelde statistieken) . Evenzo is informatie over vergrendelingen te vinden in de PostgreSQL-logbestanden, pg_locks en pg_stat_activity (hieronder weergegeven) met wait_event en wait_event_type . Hierdoor is het moeilijk om het enorme gebied van monitoring op een eendimensionale lineaire manier te bestrijken, en de auteur riskeert hierdoor verwarring bij de lezer te creëren. Om dit te voorkomen, behandelen we de monitoring ruwweg door de officiële documentatie te volgen en waar nodig gerelateerde informatie toe te voegen.
Dynamische statistiekenweergaven
pg_stat_activity gebruiken we kunnen zien wat de huidige activiteit is door de verschillende backend-processen. Als we bijvoorbeeld de volgende query uitvoeren op tafeldelen met ongeveer 3M rijen:
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 | | |En laten we de volgende query uitvoeren, die enkele seconden nodig heeft om te voltooien:
testdb=# select avg(age(date_added)) FROM parts;Door een nieuwe terminal te openen en de volgende query uit te voeren, terwijl de vorige nog steeds actief is, krijgen we:
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 workerDe weergave pg_stat_activity geeft ons informatie over het backend-proces, de gebruiker, de klant, de transactie, de query, de status en uitgebreide informatie over de wachtstatus van de query.
Maar waarom 3 rijen? Als in versies>=9.6 een query parallel kan worden uitgevoerd, of delen ervan parallel kunnen worden uitgevoerd, en de optimizer denkt dat parallelle uitvoering de snelste strategie is, wordt een Gather gemaakt of Verzamel samenvoegen node, en verzoekt vervolgens maximaal max_parallel_workers_per_gather achtergrondwerkprocessen, die standaard 2 zijn, vandaar de 3 rijen die we in de bovenstaande uitvoer zien. We kunnen het client-backendproces onderscheiden van de achtergrondwerker door het backend_type . te gebruiken kolom. Om de weergave pg_stat_activity in te schakelen, moet u ervoor zorgen dat de systeemconfiguratieparameter track_activities staat aan. De pg_stat_activity biedt uitgebreide informatie om geblokkeerde zoekopdrachten te bepalen door het gebruik van wait_event_type en wait_event-kolommen.
Een meer verfijnde manier om uitspraken te controleren is via de pg_stat_statements contrib-extensie, eerder genoemd. Op een recent Linux-systeem (Ubuntu 17.10, PostgreSQL 9.6) kan dit vrij eenvoudig worden geïnstalleerd:
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_statementsLaten we een tabel maken met 100000 rijen, en dan pg_stat_statements resetten, de PostgreSQL-server opnieuw opstarten, een selectie uitvoeren op deze tabel op het (nog steeds koude) systeem en dan de inhoud bekijken van pg_stat_statements voor de 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=#Laten we nu de select * nog een keer uitvoeren en dan opnieuw kijken in de inhoud van pg_stat_statements voor deze 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)Dus de tweede keer dat de select-instructie alle vereiste blokken in de gedeelde PostgreSQL-buffers vindt, en pg_stat_statements meldt dit via shared_blks_hit . pg_stat_statements geeft informatie over het totale aantal aanroepen van een statement, de total_time, min_time, max_time en mean_time, wat erg handig kan zijn bij het analyseren van de werklast van je systeem. Een langzame query die zeer vaak wordt uitgevoerd, moet onmiddellijke aandacht vereisen. Evenzo kunnen consistent lage hitrates betekenen dat de shared_buffers moeten worden herzien instelling.
pg_stat_replicatie geeft informatie over de huidige status van replicatie voor elke wal_sender. Laten we aannemen dat we een eenvoudige replicatietopologie hebben ingesteld met onze primaire en een warme stand-by, dan kunnen we pg_stat_replication op de primaire opvragen (hetzelfde doen op de stand-by levert geen resultaten op tenzij we trapsgewijze replicatie hebben ingesteld en deze specifieke stand-by dient als een upstream naar andere downstream standbys) om de huidige status van replicatie te zien:
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 | asyncDe 4 kolommen sent_lsn , write_lsn , flush_lsn , replay_lsn vertel ons de exacte WAL-positie in elke fase van het replicatieproces op de externe stand-by. Dan creëren we wat zwaar verkeer op de primaire met een commando als:
testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;En kijk nog eens naar 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 | asyncNu zien we dat we een vertraging hebben tussen de primaire en de standby weergegeven in de sent_lsn , write_lsn , flush_lsn , replay_lsn waarden. Sinds PgSQL 10.0 toont de pg_stat_replicatie ook de vertraging tussen een recentelijk lokaal gewiste WAL en de tijd die nodig was om respectievelijk op afstand te worden geschreven, te wissen en opnieuw af te spelen. Als u nulls in die 3 kolommen ziet, betekent dit dat de primaire en de stand-by synchroon lopen.
Het equivalent van pg_stat_replication aan de standby-zijde heet: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=#Als er geen activiteit is en de stand-by heeft alles opnieuw afgespeeld, dan latest_end_lsn moet gelijk zijn aan sent_lsn op de primaire (en alle tussenliggende logvolgnummers).
Net als bij fysieke replicatie, in het geval van logische replicatie, waarbij de rol van de primaire wordt genomen door de uitgever, en de rol van de standby wordt genomen door de abonnee, natuurlijk de rol van pg_stat_wal_receiver wordt ingenomen door pg_stat_subscription . We kunnen pg_stat_subscription query opvragen als volgt:
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+00Merk op dat aan de uitgeverskant de corresponderende weergave hetzelfde is als in het geval van fysieke replicatie:pg_stat_replication .
Verzamelde statistiekenweergaven
pg_stat_archiver view heeft één rij die informatie geeft over de wal archiver. Door regelmatig een momentopname van deze rij bij te houden, kunt u de grootte van het WAL-verkeer tussen die intervallen berekenen. Het geeft ook informatie over storingen tijdens het archiveren van WAL-bestanden.
pg_stat_bgwriter weergave geeft zeer belangrijke informatie over het gedrag van:
- De checkpointer
- De achtergrondschrijver
- De (client-serving) backends
Aangezien deze weergave accumulatieve gegevens geeft sinds de laatste reset, is het erg handig om nog een tabel met tijdstempel te maken met periodieke snapshots van pg_stat_bgwriter , zodat het gemakkelijk is om een incrementeel perspectief tussen twee snapshots te krijgen. Tuning is een wetenschap (of magie), en het vereist uitgebreide logging en monitoring, evenals een duidelijk begrip van de onderliggende concepten en PostgreSQL internals om goede resultaten te krijgen, en deze visie is waar te beginnen, op zoek naar dingen zoals:
- Zijn de checkpoints_timed het overgrote deel van het totale aantal checkpoints? Zo niet, dan moeten er acties worden ondernomen, de resultaten worden gemeten en het hele proces worden herhaald totdat er geen verbeteringen worden gevonden.
- Zijn de buffers_checkpoint een goede meerderheid over de andere twee soorten (buffers_clean maar vooral buffers_backend ) ? Als de buffers_backend hoog zijn, moeten bepaalde configuratieparameters worden gewijzigd en moeten nieuwe metingen worden uitgevoerd en opnieuw worden beoordeeld.
Pg_stat_[user|sys|all]_tables
Het meest elementaire gebruik van die weergaven is om te controleren of onze vacuümstrategie werkt zoals verwacht. Grote waarden van dode tupels ten opzichte van levende tupels betekent inefficiënt stofzuigen. Die weergaven bieden ook informatie over seq vs index-scans en ophaalacties, informatie over het aantal ingevoegde, bijgewerkte, verwijderde rijen en HOT-updates. Probeer het aantal HOT-updates zo hoog mogelijk te houden om de prestaties te verbeteren.
Pg_stat_[user|sys|all]_indexes
Hier bewaart en toont het systeem informatie over het individuele indexgebruik. Een ding om in gedachten te houden is dat idx_tup_read nauwkeuriger is dan idx_tup_fetch. Niet PK/ niet-unieke indexen met lage idx_scan moeten worden overwogen voor verwijdering, omdat ze alleen HOT-updates belemmeren. Zoals vermeld in de vorige blog, moet overindexering worden vermeden, indexeren brengt kosten met zich mee.
Pg_statio_[user|sys|all]_tables
In die views kunnen we informatie vinden over de prestaties van de cache met betrekking tot table heap reads, index reads en TOAST reads. Een eenvoudige zoekopdracht om het percentage treffers te tellen, en de verdeling van de treffers over tabellen zou zijn:
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.5820895522388Dit vertelt ons dat ten minste 50% van de tafels een hitrate heeft die hoger is dan 96,93% en dat 83,5% van de tafels een hitrate heeft die hoger is dan 59,4%
Pg_statio_[user|sys|all]_indexes
Deze weergave bevat informatie over bloklezen/treffers voor indexen.
Pg_stat_database
Deze weergave bevat één rij per database. Het toont een deel van de informatie van de voorgaande views geaggregeerd naar de hele database (gelezen blokken, blokken geraakt, info over tups), wat informatie die relevant is voor de hele database (totaal aantal xactions, tijdelijke bestanden, conflicten, deadclocks, lees-/schrijftijd) , en tot slot het aantal huidige backends.
Hier moet u op letten bij de verhouding blks_hit/(blks_hit + blks_read) :hoe hoger de waarde, hoe beter voor de I/O van het systeem. Missers hoeven echter niet per se te worden toegeschreven aan het lezen van de schijf, omdat ze mogelijk goed zijn opgevangen door de filesys-cache van het besturingssysteem.
Net als bij andere verzamelde statistische weergaven die hierboven zijn vermeld, moet men een versie met tijdstempel maken van de pg_stat_database bekijk en bekijk de verschillen tussen twee opeenvolgende snapshots:
- Neemt het aantal terugdraaiingen toe?
- Of het aantal toegewijde xactions?
- Krijgen we veel meer conflicten dan gisteren (dit geldt voor standbys)?
- Hebben we een abnormaal hoog aantal impasses?
Dat zijn allemaal zeer belangrijke gegevens. De eerste twee kunnen enige verandering in een gebruikspatroon betekenen, dat moet worden uitgelegd. Een hoog aantal conflicten kan betekenen dat replicatie enige afstemming nodig heeft. Een hoog aantal deadlocks is om vele redenen slecht. Niet alleen de prestaties zijn laag omdat transacties worden teruggedraaid, maar ook als een applicatie last heeft van deadlocks in een enkele mastertopologie, zullen de problemen alleen maar groter worden als we overstappen op multi-master. In dit geval moet de afdeling software-engineering de stukjes code herschrijven die de impasses veroorzaken.
Vergrendelt
Gerelateerde bronnen ClusterControl voor PostgreSQL Hoe u uw bestaande Postgres-server beheert en controleert Hoe u PostgreSQL-prestaties kunt benchmarkenVergrendelen is een zeer belangrijk onderwerp in PostgreSQL en verdient zijn eigen blog(s). Desalniettemin moet de basisbewaking van sluizen op dezelfde manier worden uitgevoerd als de andere hierboven beschreven aspecten van de bewaking. pg_locks view biedt realtime informatie over de huidige sloten in het systeem. We kunnen lang wachtende sloten opvangen door log_lock_waits in te stellen , dan wordt informatie over lange wachttijden vastgelegd in het PgSQL-logboek. Als we een ongebruikelijk hoge vergrendeling opmerken, wat resulteert in lange wachttijden, zoals in het geval van de hierboven genoemde deadlocks, moeten de software-engineers alle stukjes code beoordelen die langdurige vergrendelingen kunnen veroorzaken, b.v. expliciete vergrendeling in de applicatie (LOCK TABLE of SELECT ... FOR UPDATE).
Net als bij deadlocks, zal een systeem met korte sloten gemakkelijker overstappen op een multi-master setup.