Vigtig PostgreSQL-overvågning - del 3

2. Bordbloat

På grund af Postgres' MVCC-arkitektur ligger ældre versioner af rækker rundt i de fysiske datafiler for hver tabel og kaldes bloat . Operationen for at fjerne forældede rækkeversioner kaldes vakuum . Postgres kører en baggrundsproces kaldet autovacuum , som opfanger kandidattabeller (baseret på konfigurerbare parametre) og støvsuger dem for dig.

Bloat sænker borddriften og spilder diskplads og kan løbe væk selv med autovakuum. Overvågning af oppustethed, som et absolut antal bytes såvel som en procentdel (af døde data i forhold til samlede data), er påkrævet.

Denne metrik kan overvåges enten på individuelt tabelniveau eller som aggregeret på tværs af udvalgte tabeller eller på databaseniveau.

Handling:Overvåg kontinuert tabelbloat som bytes og procent, advars, hvis værdier overstiger en fastsat tærskel, VAKUUM efter behov.

Sådan:

Brug check_postgres orpgmetrics for at få bloat estimater. Se wikien for mere information.

3. Sekventielle scanninger

Når der udføres forespørgsler, som ikke optimalt bruger de tilgængelige indekser, eller hvis de statistiske oplysninger, der er knyttet til en tabel, er for forældede, kan Postgres ende med at skulle gennemgå hver række i tabellen. Dette kaldes en sekventiel scanning , og er ikke særlig ønskværdig i det generelle tilfælde. Det, der ville være bedre at have, er en indeksscanning , hvor rækkerne i en tabel tilgås indirekte via indeksopslag.

PostgreSQL kan fortælle dig, hvor mange gange en tabel blev scannet sekventielt, og hvor mange gange et indeks blev brugt. Du kan bruge dette til at overvåge enten antallet af sekventielle scanninger (hvis du vil undgå dem helt) eller som en procentdel af de samlede scanninger.

Handling:Overvåg løbende den efterfølgende. scanninger tæller eller procent, giver besked hvis værdien overstiger en fastsat tærskel.

Sådan:

-- returnerer nr. af seq. scanninger og procentdelen af ​​seq. scanner for hver tabelSELECT skemanavn || '.' || relname, seq_scan, round(seq_scan::numeric*100/(seq_scan+idx_scan), 1) FROM pg_stat_user_tablesWHERE seq_scan+idx_scan> 0; 

Indeksniveau

1. Indeksstørrelse

Indekser kan optage betydelig diskplads. Hvert indeks i en tabel kan potentielt selv have lige så meget diskaftryk som selve tabellen. Det er nyttigt at holde øje med den samlede størrelse af indekser i en database eller indekser af vigtige tabeller, især i implementeringer, hvor indekser kan oprettes gennem automatiske processer.

Urimeligt store indekser kan være på grund af oppustethed eller bare et dårligt designet indeks. I begge tilfælde kan løsning af årsagen (enten ved at genopbygge indekset eller ved at refaktorisere forespørgslen/indekset) give hurtigere forespørgselstider, så det er værd at undersøge store indekser.

Handling:Overvåg den samlede størrelse af interessante indekser over hver uge/måned, undersøg, når de er urimelige.

Sådan:

-- returnerer størrelsen for hvert indexSELECT skemanavn || '.' || indexrelname, pg_size_pretty(pg_total_relation_size(indexrelid)) FRA pg_stat_user_indexes; 

2. Indeksbloat

Indekser kan også blive oppustede. Der er alt for mange faktorer, herunder tableworkload, indekstype, Postgres-version og mere, der afgør, hvor oppustet anindex bliver. Oppustede indekser kan bremse indsatser og reducere udseendets ydeevne. Overvåg antallet af indekser som både en absolut værdi (antal bytes) og som en procentdel. Indekser skal genopbygges, når de bliver for oppustede.

Handling:Overvåg løbende indeksbloat som bytes og procent, advare, hvis værdier overstiger en fastsat tærskel.

Sådan:

Brug check_postgres orpgmetrics for at få bloat estimater. Se wikien for mere information.

3. Cache-hitforhold

PostgreSQL cacher hyppigt tilgåede områder af indekser (og også tabeller) i hukommelsen. Hvis du har indstillet dine forespørgsler til ikke at røre tabellerne undtagen for at hente rækker, er næste trin at sikre maksimal cache-residency for de vigtige indekser, der virkelig fremskynder dine forespørgsler.

Cache-udnyttelsen af ​​et indeks kan måles ved cache-hitforholdet, som er procentdelen af ​​blokke af indekset, der blev læst fra cachen til det samlede antal læste blokke.

Handling:Overvåg kontinuerligt cache-hitforholdsprocenten, advare, hvis værdien falder under en fastsat tærskel. Undersøg lave værdier for vigtige indekser.

Sådan:

-- returnerer cache hit-forholdet som en procentdel, for hvert indeks SELECT skemanavn || '.' || indexrelname AS index_name, round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 / pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio FRA pg_stat_user_indexes WHERE pg_stat_get_blocks_relider_BY index_0