Viktiga saker att övervaka i PostgreSQL - Analysera din arbetsbelastning

Nyckelsaker att övervaka i PostgreSQL - Analysera din arbetsbelastning

I datorsystem är övervakning processen att samla in mätvärden, analysera, beräkna statistik och generera sammanfattningar och grafer angående prestanda eller kapacitet hos ett system, samt generera varningar vid oväntade problem eller misslyckanden som kräver omedelbar uppmärksamhet eller åtgärd. Därför har övervakning två användningsområden:en för historisk dataanalys och presentation som hjälper oss att identifiera trender på medellång och lång sikt inom vårt system och därmed hjälpa oss att planera för uppgraderingar, och en andra för omedelbara åtgärder vid problem.

Övervakning hjälper oss att identifiera problem och reagera på dessa problem som rör ett brett spektrum av områden som:

Infrastruktur/hårdvara (fysisk eller virtuell)
Nätverk
Lagring
Systemprogramvara
Programvara
Säkerhet

Övervakning är en stor del av arbetet på en DBA. PostgreSQL har traditionellt sett varit känt för att vara "lågt underhåll" tack vare sin sofistikerade design och detta betyder att systemet kan leva med låg närvaro jämfört med andra alternativ. Men för seriösa installationer där hög tillgänglighet och prestanda är av avgörande betydelse, måste databassystemet övervakas regelbundet.

Rollen för PostgreSQL DBA kan öka till högre nivåer inom företagets hierarki förutom strikt teknisk:förutom grundläggande övervakning och prestandaanalys, måste kan upptäcka förändringar i användningsmönster, identifiera möjliga orsaker, verifiera antaganden och slutligen översätta resultat i affärsmässiga termer. Som ett exempel måste DBA kunna identifiera någon plötslig förändring i en viss aktivitet som kan vara kopplad till ett möjligt säkerhetshot. Så rollen som PostgreSQL DBA är en nyckelroll inom företaget och måste arbeta nära andra avdelningschefer för att identifiera och lösa problem som uppstår. Övervakning är en stor del av detta ansvar.

PostgreSQL tillhandahåller många färdiga verktyg som hjälper oss att samla in och analysera data. På grund av dess utbyggbarhet ger den dessutom möjlighet att utveckla nya moduler i kärnsystemet.

PostgreSQL är starkt beroende av systemet (hårdvara och mjukvara) den körs på. Vi kan inte förvänta oss att en PostgreSQL-server ska fungera bra om det finns problem i någon av de vitala komponenterna i resten av systemet. Så rollen för PostgreSQL DBA överlappar rollen som sysadmin. Nedan, när vi undersöker vad vi ska titta på i PostgreSQL-övervakning, kommer vi att stöta på både systemberoende variabler och mätvärden såväl som PostgreSQL:s specifika siffror.

Övervakning är inte gratis. En bra investering måste göras av företaget/organisationen med ett åtagande att hantera och underhålla hela övervakningsprocessen. Det lägger också till en liten belastning på PostgreSQL-servern också. Detta är lite att oroa sig för om allt är korrekt konfigurerat, men vi måste komma ihåg att detta kan vara ytterligare ett sätt att missbruka systemet.

Grundläggande systemövervakning

Viktiga variabler i systemövervakning är:

CPU-användning
Nätverksanvändning
Diskutrymme / Diskutnyttjande
RAM-användning
Disk IOPS
Byt utrymmesanvändning
Nätverksfel

Här är ett exempel på ClusterControl som visar grafer för några kritiska PostgreSQL-variabler som kommer från pg_stat_database och pg_stat_bgwriter (som vi kommer att ta upp i följande stycken) medan du kör pgbench -c 64 -t 1000 pgbench två gånger:

Vi märker att vi har en topp på block-read i den första körningen, men vi kommer nära noll under den andra körningen eftersom alla block finns i shared_buffers.

Andra variabler av intresse är personsökningsaktivitet, avbrott, kontextväxlingar, bland annat. Det finns en uppsjö av verktyg att använda i Linux/BSD och unix eller unix-liknande system. Några av dem är:

ps:för en lista över de processer som körs
top/htop/systat:för övervakning av systemanvändning (CPU/minne)
vmstat:för allmän systemaktivitet (inklusive virtuellt minne) övervakning
iostat/iotop/top -mio:för IO-övervakning
ntop:för nätverksövervakning

Här är ett exempel på vmstat på en FreeBSD-box under en fråga som kräver en del diskläsning och även en del beräkning:

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

Om vi upprepade frågan skulle vi inte märka någon ny burst i diskaktivitet eftersom dessa skivblock redan skulle finnas i operativsystemets cache. Även om PostgreSQL DBA helt måste kunna förstå vad som händer i den underliggande infrastrukturen där databasen körs, är mer komplex systemövervakning vanligtvis ett jobb för systemadministratören, eftersom detta är ett stort ämne i sig.

I linux, en mycket praktisk genväg för toppen verktyget trycker på "C", vilket växlar mellan att visa kommandoraden för processerna. PostgreSQL skriver som standard om kommandoraden för backends med den faktiska SQL-aktivitet som de kör för tillfället och även användaren.

PostgreSQL-övervakningsgrunderna

Viktiga variabler i PostgreSQL-övervakning är:

Prestanda för buffertcache (cacheträffar kontra diskläsning)
Antal åtaganden
Antal anslutningar
Antal sessioner
Checkpoints och bgwriter-statistik
Dammsugare
Lås
Replikering
Och sist men definitivt inte minst, frågor

Generellt finns det två sätt i en övervakningsinställning att utföra datainsamling:

För att hämta data via en logg
För att hämta data genom att fråga PostgreSQL-systemet

Loggfilbaserad datainsamling beror på (korrekt konfigurerad) PostgreSQL-loggen. Vi kan använda denna typ av loggning för "off-line" bearbetning av data. Loggfilbaserad övervakning är bäst lämpad när minimal overhead till PostgreSQL-servern krävs och när vi inte bryr oss om livedata eller om att få live-varningar (även om liveövervakning med loggfildata kan vara möjlig genom att t.ex. dirigera postgresql-loggen till syslog och sedan strömma syslog till en annan server dedikerad för loggbearbetning).

Ladda ner Whitepaper Today PostgreSQL Management &Automation med ClusterControlLäs om vad du behöver veta för att distribuera, övervaka, hantera och skala PostgreSQLDladda Whitepaper

PostgreSQL-statistiksamlare

PostgreSQL tillhandahåller en rik uppsättning vyer och funktioner som är lätt tillgängliga via undersystemet Statistics Collector. Återigen är dessa uppgifter indelade i två kategorier:

Dynamisk information om vad systemet gör för tillfället.
Statistik ackumulerad sedan undersystemet för statistikinsamling senast återställdes.

Dynamiska statistikvyer ge information om aktuell aktivitet per process (pg_stat_activity), status för fysisk replikering (pg_stat_replikation), status för fysisk standby (pg_stat_wal_receiver) eller logisk (pg_stat_subscription), ssl (pg_stat_ssl) och vakuum (pg_stat_progress_vacuum).

Visningar av samlad statistik tillhandahålla information om viktiga bakgrundsprocesser som wal-arkiveraren, bgwriter och databasobjekt:användar- eller systemtabeller, index, sekvenser och funktioner samt själva databaserna.

Det borde vara ganska uppenbart vid det här laget att det finns flera sätt att kategorisera data relaterade till övervakning:

Efter källa:
- Systemverktyg (ps, top, iotop, etc)
- PgSQL-loggfil
- Databas
  - Dynamisk
  - Insamlat
Genom specifik databasoperation:
- Buffertcache
- Befäster
- Frågor
- Sessioner
- Kontrollpunkter
- Osc

Efter att ha läst den här artikeln och experimenterat med de föreställningar, begrepp och termer som presenteras, bör du kunna göra en 2D-matris med alla möjliga kombinationer. Som ett exempel kan den specifika PostgreSQL-aktiviteten (SQL-kommando) hittas med hjälp av:ps eller top (systemverktyg), PostgreSQL-loggfilerna, pg_stat_activity (dynamisk vy), men även med hjälp av pg_stat_statements, ett tillägg som finns i contrib (vy för samlad statistik) . På samma sätt kan information om lås hittas i PostgreSQL-loggfilerna, pg_locks och pg_stat_activity (presenteras precis nedan) med wait_event och wait_event_type . På grund av detta är det svårt att täcka det stora området av övervakning på ett endimensionellt linjärt sätt, och författaren riskerar att skapa förvirring för läsaren på grund av detta. För att undvika detta kommer vi att täcka övervakning grovt genom att följa den officiella dokumentationen och lägga till relaterad information vid behov.

Dynamiska statistikvyer

Använder pg_stat_activity vi kan se vad som är den aktuella aktiviteten av de olika backend-processerna. Till exempel om vi kör följande fråga på tabelldelar med cirka 3M rader:

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

Och låt oss köra följande fråga, som tar några sekunder att slutföra:

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

Genom att öppna en ny terminal och köra följande fråga, medan den föregående fortfarande körs, 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 worker

Vyn pg_stat_activity ger oss information om backend-processen, användaren, klienten, transaktionen, frågan, tillståndet samt en omfattande information om frågans väntestatus.

Men varför 3 rader? I versioner>=9.6, om en fråga kan köras parallellt, eller delar av den kan köras parallellt, och optimeraren tycker att parallellkörning är den snabbaste strategin, skapar den en Gather eller Gather Merge nod och begär sedan högst max_parallel_workers_per_gather bakgrundsarbetarprocesser, som som standard är 2, därav de 3 raderna vi ser i utgången ovan. Vi kan skilja klientens backend-process från bakgrundsarbetaren genom att använda backend_type kolumn. För att vyn pg_stat_activity ska aktiveras måste du se till att systemkonfigurationsparametern track_activities är på. Pg_stat_activity tillhandahåller omfattande information för att fastställa blockerade frågor genom att använda kolumnerna wait_event_type och wait_event.

Ett mer förfinat sätt att övervaka uttalanden är via pg_stat_statements bidragsförlängning, som nämnts tidigare. På ett senare Linux-system (Ubuntu 17.10, PostgreSQL 9.6) kan detta installeras ganska enkelt:

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

Låt oss skapa en tabell med 100 000 rader och sedan återställa pg_stat_statements, starta om PostgreSQL-servern, utföra ett urval på den här tabellen på systemet (fortfarande kallt) och sedan se innehållet i pg_stat_statements för 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=#

Låt oss nu utföra select * en gång till och titta sedan igen i innehållet i pg_stat_statements för den här frågan:

[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å andra gången hittar select-satsen alla nödvändiga block i PostgreSQL delade buffertar, och pg_stat_statements rapporterar detta via shared_blks_hit . pg_stat_statements ger information om det totala antalet anrop för ett uttalande, total_time, min_time, max_time och mean_time, vilket kan vara extremt användbart när du försöker analysera arbetsbelastningen på ditt system. En långsam fråga som körs mycket ofta bör kräva omedelbar uppmärksamhet. På samma sätt kan konsekvent låga träfffrekvenser betyda behovet av att granska shared_buffers inställning.

pg_stat_replication ger information om aktuell status för replikering för varje wal_sender. Låt oss anta att vi har ställt in en enkel replikeringstopologi med vår primära och en heta standby, då kan vi fråga pg_stat_replikation på den primära (att göra samma sak i vänteläget ger inga resultat om vi inte har ställt in kaskadreplikering och denna specifika standby fungerar som en uppströms till andra nedströms standbylägen) för att se aktuell status för 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       | async

De fyra kolumnerna sent_lsn , write_lsn , flush_lsn , replay_lsn berätta för oss den exakta WAL-positionen i varje steg av replikeringsprocessen i fjärrberedskapsläge. Sedan skapar vi lite tung trafik på primären med ett kommando som:

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

Och titta 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       | async

Nu ser vi att vi har en fördröjning mellan primär och standby som visas i sent_lsn , write_lsn , flush_lsn , replay_lsn värden. Sedan PgSQL 10.0 visar pg_stat_replication också fördröjningen mellan en nyligen lokalt tömd WAL och tiden det tog att fjärrskrivas, tömmas respektive spelas upp igen. Att se nollor i dessa tre kolumner betyder att den primära och vänteläge är synkroniserade.

Motsvarigheten till pg_stat_replication på standbysidan kallas: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 det inte finns någon aktivitet och vänteläget har spelat upp allt sedan latest_end_lsn måste vara lika med sent_lsn på den primära (och alla mellanliggande loggsekvensnummer).

På samma sätt som fysisk replikering, i fallet med logisk replikering, där rollen som den primära tas av utgivaren och rollen som standby tas av abonnenten, naturligtvis rollen som pg_stat_wal_receiver tas av pg_stat_subscription . Vi kan fråga pg_stat_subscription enligt följande:

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

Observera att på utgivarsidan är motsvarande vy densamma som i fallet med fysisk replikering:pg_stat_replication .

Visningar av samlad statistik

pg_stat_archiver view har en rad som ger information om wal-arkivet. Genom att hålla en ögonblicksbild av den här raden med jämna mellanrum kan du beräkna storleken på WAL-trafiken mellan dessa intervall. Det ger också information om fel vid arkivering av WAL-filer.

pg_stat_bgwriter view ger mycket viktig information om beteendet hos:

Kontrollpekaren
Bakgrundsskribenten
(klientbetjäning) backends

Eftersom denna vy ger ackumulerande data sedan den senaste återställningen är det mycket användbart att skapa en annan tidsstämplad tabell med periodiska ögonblicksbilder av pg_stat_bgwriter , så att det blir lätt att få ett inkrementellt perspektiv mellan två ögonblicksbilder. Tuning är en vetenskap (eller magi), och det kräver omfattande loggning och övervakning samt en tydlig förståelse av de underliggande koncepten och PostgreSQL-internerna för att få bra resultat, och den här uppfattningen är var du ska börja, leta efter saker som:

Är de checkpoints_timed den stora majoriteten av de totala kontrollpunkterna? Om inte måste åtgärder vidtas, resultat mätas och upprepa hela processen tills inga förbättringar hittas.
Är buffertkontrollpunkten en god majoritet över de andra två typerna (buffers_clean men viktigast av allt buffers_backend ) ? Om buffers_backend är höga måste vissa konfigurationsparametrar ändras, nya mätningar måste göras och omvärderas.

Pg_stat_[användare|sys|alla]_tabeller

Den mest grundläggande användningen av dessa vyer är att verifiera att vår vakuumstrategi fungerar som förväntat. Stora värden av döda tuplar i förhållande till levande tuplar betyder ineffektiv dammsugning. Dessa vyer ger också information om seq vs index skanningar och hämtningar, information om antalet infogade rader, uppdaterade, raderade samt HETA uppdateringar. Du bör försöka hålla antalet HOT-uppdateringar så högt som möjligt för att förbättra prestandan.

Pg_stat_[användare|sys|alla]_index

Här lagrar och visar systemet information om individuell indexanvändning. En sak att tänka på är att idx_tup_read är mer exakt än idx_tup_fetch. Icke PK/icke unika index med låg idx_scan bör övervägas för borttagning, eftersom de bara hindrar HOT uppdateringar. Som nämndes i förra bloggen bör överindexering undvikas, indexering kostar pengar.

Pg_statio_[användare|sys|alla]_tabeller

I dessa vyer kan vi hitta information om cachens prestanda när det gäller läsning av tabellhögar, indexläsningar och TOAST-läsningar. En enkel fråga för att räkna för procentandelen träffar och fördelningen av träffarna över tabellerna skulle vara:

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

Detta säger oss att minst 50 % av tabellerna har träfffrekvens som är större än 96,93 % och 83,5 % av tabellerna har en träfffrekvens som är bättre än 59,4 %

Pg_statio_[användare|sys|alla]_index

Denna vy innehåller blockläs-/träffinformation för index.

Pg_stat_database

Denna vy innehåller en rad per databas. Den visar en del av informationen från de föregående vyerna aggregerade till hela databasen (lästa block, blockträffar, info om tups), viss information som är relevant för hela databasen (totalt antal åtgärder, temporära filer, konflikter, dödklockor, läs/skrivtid) , och slutligen antalet nuvarande backends.

Saker att leta efter här är förhållandet blks_hit/(blks_hit + blks_read) :Ju högre värde desto bättre för systemets I/O. Men missar bör inte nödvändigtvis redovisas för diskläsningar eftersom de mycket väl kan ha betjänats av operativsystemets filesys cache.

På samma sätt som andra insamlade statistikvyer som nämns ovan, bör man skapa en tidsstämplad version av pg_stat_database visa och se skillnaderna mellan två på varandra följande ögonblicksbilder:

Ökar antalet återställningar?
Eller antalet engagerade xactions?
Får vi mycket fler konflikter än igår (detta gäller beredskapslägen)?
Har vi onormalt höga antal dödlägen?

Alla dessa är mycket viktiga uppgifter. De två första kan innebära en förändring i något användningsmönster, det måste förklaras. Högt antal konflikter kan innebära att replikering behöver finjusteras. Högt antal dödlägen är dåligt av många anledningar. Inte bara prestandan är låg eftersom transaktioner rullas tillbaka, utan även om en applikation lider av dödlägen i en enda mastertopologi kommer problemen bara att förstärkas om vi går över till multi-master. I det här fallet måste programvaruteknikavdelningen skriva om de delar av koden som orsakar låsningarna.

Lås

Relaterade resurser ClusterControl for PostgreSQL Hur man hanterar och övervakar din befintliga Postgres-server Hur man benchmarkar PostgreSQL-prestanda

Låsning är ett mycket viktigt ämne i PostgreSQL och förtjänar sina egna bloggar. Icke desto mindre måste grundläggande låsövervakning göras på samma sätt som de andra aspekterna av övervakningen som presenteras ovan. pg_locks view ger realtidsinformation om de aktuella låsen i systemet. Vi kan fånga långa väntande lås genom att ställa in log_lock_waits , då kommer information om långa väntetider att loggas i PgSQL-loggen. Om vi märker ovanligt hög låsning som resulterar i långa väntetider, som i fallet med blockerade låsningar som nämns ovan, måste mjukvaruingenjörerna granska alla kodbitar som kan orsaka långa låsningar, t.ex. explicit låsning i applikationen (LÅS TABELL eller VÄLJ … FÖR UPPDATERING).

På samma sätt som fallet med blockerat låsläge, kommer ett system med korta lås att flyttas lättare till en multimaster-inställning.