Viktig PostgreSQL-övervakning - Del 3

Vilka mätvärden för din PostgreSQL-distribution bör du övervaka? Denna serie av blogginlägg syftar till att tillhandahålla en minimal startuppsättning av viktiga övervakningsåtgärder som du bör implementera för att säkerställa hälsan och stabiliteten hos dina Postgres-servrar.

Detta är den tredje och sista delen av en bloggserie och täcker mätvärden på tabell-, index- och systemnivå. Den första entäckta klusternivåmåtten och den andra encovered databasnivåmätningen.

Tabellnivå

Vanligtvis följer data i en databas 80-20-regeln. 20 % av tabellerna innehåller det mesta av data och nås eller muteras mest. Att ställa in extra övervakning enbart för dessa tabeller kan ge insikter som är viktiga men ändå med låg volym.

Här är några mätvärden på tabellnivå som är värda att titta på:

1. Tabellstorlek

Den faktiska diskstorleken som används av tabellen måste övervakas. I de flesta fall fortsätter tabellen att växa, så det är tillväxttakten som är mer intressant.

Det är ofta så att tillväxttakten ändras efter lanseringen av en ny version av applikationen, eller en grundförändring i trafik/belastning/inmatningsmönster för själva applikationen. Sådana ändringar måste undersökas, åtminstone för att verifiera att den nya hastigheten är hållbar av den tillhandahållna hårdvaran.

Åtgärd:Övervaka ökningen av tabellens storlek under varje vecka/månad, undersök plötsliga förändringar.

Så här gör du:

-- returns the size for each table
SELECT schemaname || '.' || relname,
       pg_size_pretty(pg_table_size(schemaname || '.' || relname))
  FROM pg_stat_user_tables;

2. Bordsvällning

På grund av Postgres MVCC-arkitektur ligger äldre versioner av rader i de fysiska datafilerna för varje tabell och kallas bloat . Åtgärden för att rensa bort föråldrade radversioner kallas vakuum . Postgres kör en bakgrundsprocess som heter autovacuum , som plockar upp kandidattabeller (baserat på konfigurerbara parametrar) och dammsuger dem åt dig.

Bloat saktar ner bordsoperationer och slösar bort diskutrymme och kan springa iväg även med autovakuum. Övervakning av uppblåsthet, som ett absolut antal byte såväl som en procentandel (av döda data till totala data), krävs.

Detta mått kan övervakas antingen på individuell tabellnivå, eller som aggregerad över valda tabeller, eller på databasnivå.

Åtgärd:Övervaka kontinuerligt tabelluppblåsning som byte och procent, varna om värdena överstiger en inställd tröskel, VAKUUM vid behov.

Så här gör du:

Använd check_postgres orpgmetrics för att få uppslagsuppskattningar. Se wikin för mer information.

3. Sekventiella skanningar

När frågor exekveras som inte optimalt använder de tillgängliga indexen, eller om den statistiska informationen förknippad med en tabell är för inaktuell, kan Postgres i slutändan behöva gå igenom varje rad i tabellen. Detta kallas en sekventiell genomsökning , och är inte särskilt önskvärt i det allmänna fallet. Det som skulle vara bättre att ha är en indexskanning , där raderna i en tabell nås indirekt via indexsökning.

PostgreSQL kan berätta hur många gånger en tabell skannades sekventiellt och hur många gånger ett index användes. Du kan använda detta för att övervaka antingen antalet sekventiella skanningar (om du vill undvika dem helt) eller som en procentandel av det totala antalet skanningar.

Åtgärd:Övervaka kontinuerligt efterföljande. skannar antal eller procent, varnar om värdet överstiger en inställd tröskel.

Så här gör du:

-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
        seq_scan,
        round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
 FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;

Indexnivå

1. Indexstorlek

Index kan ta upp mycket diskutrymme. Varje index i en tabell kan potentiellt ha lika mycket diskfotavtryck som själva tabellen. Det är användbart att hålla ett öga på den totala storleken på index i en databas, eller indexen för viktiga tabeller, särskilt i distributioner där index kan skapas genom automatiska processer.

Orimligt stora index kan bero på uppblåsthet, eller bara ett dåligt designat index. I båda fallen kan åtgärda orsaken (antingen genom att bygga om indexet eller genom att omfaktorisera frågan/indexet) ge snabbare frågetider, så det är värt att undersöka stora index.

Åtgärd:Övervaka den totala storleken på intressanta index över varje vecka/månad, undersök när de är orimligt stora.

Så här gör du:

-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
       pg_size_pretty(pg_total_relation_size(indexrelid))
  FROM pg_stat_user_indexes;

2. Indexbloat

Index kan också bli uppsvällda. Det är alldeles för många faktorer, inklusive bordsbelastning, indextyp, Postgres-version och mer, som avgör hur uppsvälld anindex blir. Uppsvällda index kan sakta ner skärningar och minska utseendets prestanda. Övervaka uppsvällningen av index som både ett absolut värde (antal byte) och som en procentandel. Index kommer att behöva byggas om när de blir för uppsvällda.

Åtgärd:Övervaka kontinuerligt indexuppsvällning som byte och procent, varna om värdena överstiger en inställd tröskel.

Så här gör du:

Använd check_postgres orpgmetrics för att få uppslagsuppskattningar. Se wikin för mer information.

3. Cache-träffförhållande

PostgreSQL cachar ofta åtkomliga regioner av index (och även tabeller) i minnet. Om du har ställt in dina frågor så att de inte rör tabellerna utom för att hämta rader, är nästa steg att säkerställa maximal cache-residency för de viktiga indexen som verkligen påskyndar dina frågor.

Cacheanvändningen av ett index kan mätas med cacheträffförhållandet, vilket är procentandelen av block i indexet som lästes från cachen till det totala antalet lästa block.

Åtgärd:Övervaka kontinuerligt cacheträffförhållandet i procent, varna om värdet faller under en inställd tröskel. Undersök låga värden för viktiga index.

Så här gör du:

-- returns the cache hit ratio as a percentage, for each index
  SELECT schemaname || '.' || indexrelname AS index_name,
           round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 / 
         pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
    FROM pg_stat_user_indexes
   WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;

Systemnivå

Förutom PostgreSQL-mått är det viktigt att hålla reda på några mätvärden för den maskin eller virtuella dator som du kör din Postgres på. Du kan använda vilken populär övervakningslösning som helst för detta, eller till och med ta tag i och spåra dem själv.

1. Användt minne

Moderna Linux-system har komplex minnesredovisning. Vi rekommenderar att du övervakar det "använda minnet", vilket är det minne som finns kvar efter att ha tagit hänsyn till minne markerat somfritt , som buffertar , som cachad , och som platta . Buffertar och cache kommer att släppas under tryck, och det kommer även de flesta (vanligtvis över 95 %) av plattan.

Det använda minnet måste dock mätas under en lämplig lång period. Om du har batchjobb, rapporter, ETL etc. som körs på helger, då skulle perioden vara en vecka. Det verkliga mått du behöver övervaka är det maximala minnet som används under denna period.

Vanligtvis, när din databasstorlek växer, tenderar detta värde att krypa uppåt. Du måste se till att den maximala minnesanvändningen är inom en bekväm gräns för tillgängligt minne, till exempel 60-80 %. Om du försummar detta skulle din analys/OLAP-arbetsbelastning misslyckas på grund av minnesbrist.

Åtgärd:Övervaka det maximalt använda minnet under en vecka/natt, varna om det överskrider en inställd tröskel, omprovision.

Hur gör du :

Det använda minnet ges av MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , där Mem* fälten är från /proc/meminfo . För mer information, se den här RedHat-artikeln.

2. Belastningsmedelvärde

Det enkla belastningsmedelvärdet är fortfarande det enklaste och snabbaste sättet att uppskatta belastningen på en server. Detta gäller särskilt för Postgres-servrar, eftersom varje backend är en separat OS-process, och att ha fler av dem i ett körbart tillstånd kommer att öka belastningens medelvärde.

För en given Postgres-server bör belastningsgenomsnittet hålla sig inom ett rimligt intervall över en affärscykel (som en vecka, inklusive batchjobb).

Åtgärd:Övervaka den maximala belastningsgenomsnittet över varje dag/vecka, undersök ökande trender.

Hur gör du :

Medelvärdena för 1 minut, 5 minuter och 15 minuter är de tre första fälten på den första raden i filen /proc/loadavg .

3. Ledigt diskutrymme

Det sista objektet i vår lista är det mest uppenbara objektet att övervaka:mängden ledigt diskutrymme i varje filsystem som används av din PostgreSQL-server, inklusive tabellutrymmen, WAL-filkataloger, backupkataloger och serverloggfiler. I fall där för många (100-tals miljoner) filer skapas i ett enda filsystem, se till att det fria inodantalet också övervakas. Brist på inoder rapporteras också som lågt diskutrymme.

Åtgärd:Övervaka kontinuerligt ledigt diskutrymme och inodanvändning på alla relevanta filsystem, varna om värdena faller under en inställd tröskel.

Hur gör du :

Ledigt diskutrymme i ett filsystem går inte att hämta direkt genom att läsa någon fil i /proc . Du kan använda stat -f /path/to/mount eller till och med df för att ta reda på det använda, lediga och reserverade diskutrymmet för ett specifikt, monterat filsystem.

Snabbreferens

Här är en fullständig lista över alla mätvärden som vi har diskuterat hittills i den här serien. Kom ihåg att dessa bara är den minimala, mest väsentliga uppsättningen mätvärden som du måste övervaka för att upptäcka när saker och ting är på väg att gå galet med din PostgreSQL-installation.

Klusternivå

• Transaktions-ID-intervall
• Antal backends
• Inaktiva replikeringsplatser
• Backends som väntar på lås
• Backends inaktiv i transaktion
• Replikeringsfördröjning för aktiva anslutningar
• Replikeringsfördröjning för replikeringsplatser
• WAL-filräkning
• Redo-att-arkivera WAL-filer

Databasnivå

• Anslutna klienter
• Storlek
• Bordsvällning över alla tabeller
• Indexuppsvällning över alla index
• Långa transaktioner
• Dödläge
• Äldsta dammsugare
• Äldsta analys

Tabellnivå

• Bordstorlek
• Bordsvällning
• Sekventiella skanningar

Indexnivå

• Indexstorlek
• Indexbloat
• Cacheträffförhållande

Systemnivå

• Använt minne
• Belastningsgenomsnitt
• Fritt diskutrymme

Samla in dessa mätvärden

Avsnitten ovan tillhandahåller SQL-satser för att extrahera nödvändiga mätvärden från en körande Postgres-server. Om du hellre inte vill skriva skripten själv, kolla in open source-verktyget pgmetrics. Den kan samla in mätvärdena ovan och mer och rapportera dem i text- och JSON-format.

Du kan skicka pgmetrics-rapporterna direkt till vårt kommersiella erbjudande, pgDash, som lagrar och bearbetar dessa rapporter för att visa grafer och utföra varningar.