Nøgle ting at overvåge i PostgreSQL - Analyse af din arbejdsbyrde
I computersystemer er overvågning processen med at indsamle målinger, analysere, beregne statistikker og generere oversigter og grafer vedrørende et systems ydeevne eller kapacitet, samt generere advarsler i tilfælde af uventede problemer eller fejl, som kræver øjeblikkelig opmærksomhed eller handling. Derfor har overvågning to anvendelser:en til historisk dataanalyse og præsentation, som hjælper os med at identificere mellem- og langsigtede tendenser i vores system og dermed hjælper os med at planlægge opgraderinger, og en anden til øjeblikkelig handling i tilfælde af problemer.
Overvågning hjælper os med at identificere problemer og reagere på disse problemer vedrørende en lang række områder såsom:
- Infrastruktur/hardware (fysisk eller virtuel)
- Netværk
- Opbevaring
- Systemsoftware
- Applikationssoftware
- Sikkerhed
Overvågning er en stor del af DBA's arbejde. PostgreSQL har traditionelt været kendt for at være "lav vedligeholdelse" takket være dets sofistikerede design, og det betyder, at systemet kan leve med lavt fremmøde sammenlignet med andre alternativer. Men for seriøse installationer, hvor høj tilgængelighed og ydeevne er af afgørende betydning, skal databasesystemet overvåges regelmæssigt.
PostgreSQL DBA'ens rolle kan stige op til højere niveauer inden for virksomhedens hierarki udover strengt teknisk:Udover grundlæggende overvågning og præstationsanalyse skal være i stand til at spotte ændringer i brugsmønstre, identificere de mulige årsager, verificere antagelserne og til sidst oversætte resultater i forretningsmæssig henseende. Som et eksempel skal DBA være i stand til at identificere en pludselig ændring i en bestemt aktivitet, der kan være forbundet med en mulig sikkerhedstrussel. Så rollen som PostgreSQL DBA er en nøglerolle i virksomheden, og skal arbejde tæt sammen med andre afdelingschefer for at identificere og løse problemer, der opstår. Overvågning er en stor del af dette ansvar.
PostgreSQL giver mange ud af boksen værktøjer til at hjælpe os med at indsamle og analysere data. På grund af dets udvidelsesmuligheder giver det desuden mulighed for at udvikle nye moduler i kernesystemet.
PostgreSQL er meget afhængig af det system (hardware og software), det kører på. Vi kan ikke forvente, at en PostgreSQL-server fungerer godt, hvis der er problemer i nogen af de vitale komponenter i resten af systemet. Så rollen som PostgreSQL DBA overlapper med rollen som sysadmin. Nedenfor, når vi undersøger, hvad vi skal se i PostgreSQL-overvågning, vil vi støde på både systemafhængige variabler og målinger samt PostgreSQLs specifikke tal.
Overvågning er ikke gratis. En god investering skal lægges i det af virksomheden/organisationen med en forpligtelse til at styre og vedligeholde hele overvågningsprocessen. Det tilføjer også en lille belastning på PostgreSQL-serveren. Dette er lidt at bekymre sig om, hvis alt er konfigureret korrekt, men vi skal huske på, at dette kan være en anden måde at misbruge systemet på.
Grundlæggende oplysninger om systemovervågning
Vigtige variabler i systemovervågning er:
- CPU-brug
- Netværksbrug
- Diskplads / Diskudnyttelse
- RAM-brug
- Disk IOPS
- Skift pladsforbrug
- Netværksfejl
Her er et eksempel på ClusterControl, der viser grafer for nogle kritiske PostgreSQL-variabler, der kommer fra pg_stat_database og pg_stat_bgwriter (som vi vil dække i de følgende afsnit), mens du kører pgbench -c 64 -t 1000 pgbench to gange:
Vi bemærker, at vi har et toppunkt på blokke-læst i den første kørsel, men vi kommer tæt på nul under den anden kørsel, da alle blokke findes i shared_buffers.
Andre variabler af interesse er personsøgningsaktivitet, interrupts, kontekstskift, blandt andre. Der er et væld af værktøjer til brug i Linux/BSD'er og unix eller unix-lignende systemer. Nogle af dem er:
-
ps:for en liste over de processer, der kører
-
top/htop/systat:til overvågning af systemudnyttelse (CPU/hukommelse)
-
vmstat:til generel systemaktivitet (herunder virtuel hukommelse) overvågning
-
iostat/iotop/top -mio:til IO-overvågning
-
ntop:til netværksovervågning
Her er et eksempel på vmstat på en FreeBSD-boks under en forespørgsel, som kræver nogle disklæsninger og også en vis beregning:
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 95Ved at gentage forespørgslen ville vi ikke bemærke nogen ny burst i diskaktivitet, da disse diskblokke allerede ville være i OS's cache. Selvom PostgreSQL DBA fuldt ud skal kunne forstå, hvad der sker i den underliggende infrastruktur, hvor databasen kører, er mere kompleks systemovervågning normalt et job for sysadmin, da dette er et stort emne i sig selv.
I linux, en meget praktisk genvej til toppen værktøjet trykker på "C", som skifter til at vise kommandolinjen for processerne. PostgreSQL omskriver som standard kommandolinjen for backends med den faktiske SQL-aktivitet, de kører i øjeblikket, og også brugeren.
Grundlæggende om PostgreSQL-overvågning
Vigtige variabler i PostgreSQL-overvågning er:
- Buffer-cache-ydeevne (cache-hit vs. disklæsning)
- Antal forpligtelser
- Antal forbindelser
- Antal sessioner
- Tjekpunkter og bgwriter-statistikker
- Støvsugere
- Låse
- Replikering
- Og sidst, men absolut ikke mindst, forespørgsler
Generelt er der to måder i en overvågningsopsætning at udføre dataindsamling på:
- At hente data via en log
- At indhente data ved at forespørge på PostgreSQL-systemet
Logfil-baseret dataopsamling afhænger af den (korrekt konfigurerede) PostgreSQL-log. Vi kan bruge denne form for logning til "off-line" behandling af dataene. Logfil-baseret overvågning er bedst egnet, når minimal overhead til PostgreSQL-serveren er påkrævet, og når vi er ligeglade med live-data eller om at få live-advarsler (selvom live-overvågning ved hjælp af logfildata kan være mulig ved f.eks. at dirigere postgresql-log til syslog og derefter streame syslog til en anden server dedikeret til logbehandling).
Download Whitepaper Today PostgreSQL Management &Automation med ClusterControlFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skalere PostgreSQLDownload WhitepaperPostgreSQL-statistiksamler
PostgreSQL giver et rigt sæt af visninger og funktioner, der er let tilgængelige via undersystemet Statistics Collector. Igen er disse data opdelt i to kategorier:
- Dynamiske oplysninger om, hvad systemet gør i øjeblikket.
- Statistik akkumuleret siden undersystemet til statistikindsamler sidst blev nulstillet.
Dynamiske statistikvisninger give oplysninger om aktuel aktivitet pr. proces (pg_stat_activity), status for fysisk replikering (pg_stat_replikation), status for fysisk standby (pg_stat_wal_receiver) eller logisk (pg_stat_subscription), ssl (pg_stat_ssl) og vakuum (pg_stat_progress_vacuum).
Samlede statistikvisninger give information om vigtige baggrundsprocesser såsom wal-arkiver, bgwriter og databaseobjekter:bruger- eller systemtabeller, indekser, sekvenser og funktioner samt selve databaserne.
Det burde efterhånden være ret indlysende, at der er flere måder at kategorisere data relateret til overvågning på:
- Efter kilde:
- Systemværktøjer (ps, top, iotop osv.)
- PgSQL-logfil
- Database
- Dynamisk
- Indsamlet
- Ved specifik databaseoperation:
- Buffercache
- Forpligter
- Forespørgsler
- Sessioner
- Kontrolposter
- Ov.
Efter at have læst denne artikel og eksperimenteret med de præsenterede forestillinger, begreber og termer, burde du være i stand til at lave en 2D-matrix med alle de mulige kombinationer. Som et eksempel kan den specifikke PostgreSQL-aktivitet (SQL-kommando) findes ved at bruge:ps eller top (systemværktøjer), PostgreSQL-logfilerne, pg_stat_activity (dynamisk visning), men også ved at bruge pg_stat_statements en udvidelse fundet i contrib (visning af indsamlet statistik) . Ligeledes kan oplysninger om låse findes i PostgreSQL-logfilerne, pg_locks og pg_stat_activity (præsenteret lige nedenfor) ved hjælp af wait_event og wait_event_type . På grund af dette er det vanskeligt at dække det store område af overvågning på en endimensionel lineær måde, og forfatteren risikerer at skabe forvirring hos læseren på grund af dette. For at undgå dette vil vi dække overvågning groft ved at følge forløbet af den officielle dokumentation og tilføje relaterede oplysninger efter behov.
Dynamiske statistikvisninger
Bruger pg_stat_activity vi er i stand til at se, hvad der er den aktuelle aktivitet ved de forskellige backend-processer. For eksempel hvis vi kører følgende forespørgsel på tabeldele med omkring 3M rækker:
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 | | |Og lad os køre følgende forespørgsel, som tager nogle sekunder at fuldføre:
testdb=# select avg(age(date_added)) FROM parts;Ved at åbne en ny terminal og køre følgende forespørgsel, mens den forrige stadig kører, får vi:
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 workerVisningen pg_stat_activity giver os information om backend-processen, brugeren, klienten, transaktionen, forespørgslen, tilstanden samt en omfattende info om forespørgslens ventestatus.
Men hvorfor 3 rækker? I versioner>=9.6, hvis en forespørgsel kan køres parallelt, eller dele af den kan køres parallelt, og optimeringsværktøjet mener, at parallel eksekvering er den hurtigste strategi, så opretter den en Gather eller Gather Merge node, og anmoder derefter højst om max_parallel_workers_per_gather baggrundsarbejderprocesser, som som standard er 2, derfor de 3 rækker, vi ser i outputtet ovenfor. Vi kan adskille klientens backend-proces fra baggrundsarbejderen ved at bruge backend_type kolonne. For at visningen pg_stat_activity skal aktiveres, skal du sørge for, at systemkonfigurationsparameteren track_activities er tændt. pg_stat_activity giver rig information for at bestemme blokerede forespørgsler ved brug af wait_event_type og wait_event kolonner.
En mere raffineret måde at overvåge udsagn på er via pg_stat_statements bidrag forlængelse, nævnt tidligere. På et nyligt Linux-system (Ubuntu 17.10, PostgreSQL 9.6) kan dette installeres ret nemt:
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_statementsLad os oprette en tabel med 100.000 rækker, og derefter nulstille pg_stat_statements, genstarte PostgreSQL-serveren, udføre et valg på denne tabel på det (stadig kolde) system, og derefter se indholdet af pg_stat_statements for 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=#Lad os nu udføre select * endnu en gang og derefter se igen i indholdet af pg_stat_statements for denne forespørgsel:
[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)Så anden gang finder select-sætningen alle de nødvendige blokke i PostgreSQL-delte buffere, og pg_stat_statements rapporterer dette via shared_blks_hit . pg_stat_statements giver information om det samlede antal kald af en erklæring, total_time, min_time, max_time og mean_time, hvilket kan være yderst nyttigt, når du prøver at analysere dit systems arbejdsbyrde. En langsom forespørgsel, der køres meget ofte, bør kræve øjeblikkelig opmærksomhed. På samme måde kan konsekvent lave hitrater betyde behovet for at gennemgå shared_buffers indstilling.
pg_stat_replication giver information om den aktuelle status for replikering for hver wal_sender. Lad os antage, at vi har opsat en simpel replikeringstopologi med vores primære og en hot-standby, så kan vi forespørge pg_stat_replikation på den primære (det samme på standby giver ingen resultater, medmindre vi har opsat kaskadereplikering, og denne specifikke standby fungerer som en opstrøms til andre downstream standbys) for at se den aktuelle status for replikering:
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 kolonner sent_lsn , write_lsn , flush_lsn , replay_lsn fortæl os den nøjagtige WAL-position på hvert trin af replikeringsprocessen på fjernstandby. Så skaber vi noget tung trafik på primæren med en kommando som:
testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;Og se på pg_stat_replication igen:
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 ser vi, at vi har en forsinkelse mellem den primære og standbyen afbildet i sent_lsn , write_lsn , flush_lsn , replay_lsn værdier. Siden PgSQL 10.0 viser pg_stat_replication også forsinkelsen mellem en nyligt lokalt tømt WAL og den tid, det tog at blive fjernskrevet, tømt og afspillet henholdsvis. At se nuller i disse 3 kolonner betyder, at den primære og standby er synkroniseret.
Det svarer til pg_stat_replication på standby-siden kaldes: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=#Når der ikke er nogen aktivitet, og standbyen har afspillet alt, så latest_end_lsn skal være lig med sent_lsn på den primære (og alle mellemliggende logsekvensnumre).
På samme måde som fysisk replikering, i tilfælde af logisk replikering, hvor rollen som den primære overtages af udgiveren, og rollen som standby overtages af abonnenten, er det naturligvis rollen som pg_stat_wal_receiver er taget af pg_stat_subscription . Vi kan forespørge pg_stat_subscription som følger:
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+00Bemærk, at på udgiversiden er den tilsvarende visning den samme som i tilfældet med fysisk replikering:pg_stat_replication .
Samlet statistikvisninger
pg_stat_archiver visningen har en række, som giver information om wal-arkiveren. Ved at holde et øjebliksbillede af denne række med regelmæssige intervaller kan du beregne størrelsen af WAL-trafikken mellem disse intervaller. Det giver også information om fejl under arkivering af WAL-filer.
pg_stat_bgwriter view giver meget vigtig information om adfærden af:
- Checkpointeren
- Baggrundsforfatteren
- (klientbetjening) backends
Da denne visning giver akkumulerede data siden sidste nulstilling, er det meget nyttigt at oprette en anden tidsstemplet tabel med periodiske snapshots af pg_stat_bgwriter , så det bliver nemt at få et trinvis perspektiv mellem to snapshots. Tuning er en videnskab (eller magi), og det kræver omfattende logning og overvågning samt en klar forståelse af de underliggende begreber og PostgreSQL-internals for at få gode resultater, og denne visning er, hvor du skal starte, på udkig efter ting som:
- Er de checkpoints_timed langt størstedelen af de samlede kontrolposter? Hvis ikke, skal der tages handlinger, måles resultater og gentage hele processen, indtil der ikke findes nogen forbedringer.
- Er bufferkontrolpunktet et godt flertal i forhold til de to andre typer (buffers_clean men vigtigst af alt buffers_backend ) ? Hvis buffers_backend er høje, så igen, skal visse konfigurationsparametre ændres, nye målinger skal tages og revurderes.
Pg_stat_[bruger|sys|alle]_tabeller
Den mest grundlæggende brug af disse synspunkter er at verificere, at vores vakuumstrategi fungerer som forventet. Store værdier af døde tupler i forhold til levende tupler betyder ineffektiv støvsugning. Disse visninger giver også information om seq vs indeksscanninger og -hentninger, info om antallet af rækker, der er indsat, opdateret, slettet samt HOT opdateringer. Du bør prøve at holde antallet af HOT-opdateringer så højt som muligt for at forbedre ydeevnen.
Pg_stat_[bruger|sys|alle]_indekser
Her gemmer og viser systemet information om individuel indeksbrug. En ting at huske på er, at idx_tup_read er mere nøjagtig end idx_tup_fetch. Ikke PK/ikke unikke indekser med lav idx_scan bør overvejes for fjernelse, da de kun hindrer HOT opdateringer. Som nævnt i den forrige blog, bør overindeksering undgås, indeksering har en pris.
Pg_statio_[bruger|sys|alle]_tabeller
I disse visninger kan vi finde information om cachens ydeevne vedrørende table heap-læsninger, indekslæsninger og TOAST-læsninger. En simpel forespørgsel til at tælle for procentdelen af hits og fordelingen af hits på tværs af tabeller ville væ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.5820895522388Dette fortæller os, at mindst 50 % af tabellerne har hitrate større end 96,93 %, og 83,5 % af tabellerne har en hitrate bedre end 59,4 %
Pg_statio_[bruger|sys|alle]_indekser
Denne visning indeholder bloklæse-/hitoplysninger for indekser.
Pg_stat_database
Denne visning indeholder en række pr. database. Det viser nogle af oplysningerne fra de foregående visninger aggregeret til hele databasen (læste blokke, blokeringer, info om tups), nogle oplysninger, der er relevante for hele databasen (samlede xactions, midlertidige filer, konflikter, dødklokker, læse-/skrivetid) , og endelig antallet af nuværende backends.
Ting du skal kigge efter her er forholdet mellem blks_hit/(blks_hit + blks_read) :Jo højere værdi, jo bedre for systemets I/O. Men mangler skal ikke nødvendigvis tages i betragtning for disklæsninger, da de udmærket kan være blevet serveret af OS's filesys cache.
På samme måde som andre indsamlede statistikvisninger nævnt ovenfor, bør man oprette en tidsstemplet version af pg_stat_database se og få et overblik over forskellene mellem to på hinanden følgende snapshots:
- Stiger antallet af tilbageførsler?
- Eller antallet af forpligtede xhandlinger?
- Får vi langt flere konflikter end i går (dette gælder standbys)?
- Har vi unormalt høje antal dødvande?
Alle disse er meget vigtige data. De to første kan betyde en ændring i et eller andet brugsmønster, som skal forklares. Højt antal konflikter kan betyde, at replikering skal justeres. Højt antal dødvande er dårligt af mange årsager. Ikke kun ydeevnen er lav, fordi transaktioner bliver rullet tilbage, men også hvis en applikation lider af deadlocks i en enkelt mastertopologi, vil problemerne kun blive forstærket, hvis vi går over til multi-master. I dette tilfælde skal softwareingeniørafdelingen omskrive de dele af koden, der forårsager deadlocks.
Låse
Relaterede ressourcer ClusterControl for PostgreSQL Sådan administrerer og overvåger du din eksisterende Postgres-server Sådan benchmarker du PostgreSQL-ydelseLåsning er et meget vigtigt emne i PostgreSQL og fortjener sine egne blog(s). Ikke desto mindre skal grundlæggende låseovervågning udføres på samme måde som de andre aspekter af overvågningen, der er præsenteret ovenfor. pg_locks view giver realtidsinformation om de aktuelle låse i systemet. Vi kan fange lange ventende låse ved at indstille log_lock_waits , så vil oplysninger om lange ventetider blive logget i PgSQL-loggen. Hvis vi bemærker usædvanlig høj låsning, som resulterer i lange ventetider, som i tilfældet med de deadlocks, der er nævnt ovenfor, skal softwareingeniørerne gennemgå alle kodestykker, der kan forårsage langvarige låse, f.eks. eksplicit låsning i applikationen (LÅS TABEL eller VÆLG … FOR OPDATERING).
På samme måde som tilfældet med blokeret låse vil et system med korte låse flytte lettere til en multi-master opsætning.