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 andra delen av en bloggserie och täcker parametrar på databasnivå. Den första täcks av parametrar på klusternivå.
Del 2:Databasnivå
I den här delen tittar vi på mätvärden och information som bör övervakas för varje viktig databas som du använder.
De flesta av SQL-frågorna nedan bör köras medan de är anslutna till databasen i fråga.
1. Anslutna klienter
Anslutna klienter tar upp OS och systemresurser. Postgres har en process-per-klient-arkitektur, och för många klienter kan sakta ner svarstider för frågor för alla. Överväg att använda PgBouncer orpgpool för att minska antalet anslutningar som Postgres-servern måste betjäna.
Håll ett öga på förändringar i baslinjen efter programuppdateringar och överspänningsanslutningar på grund av ökad trafik.
Åtgärd:Övervaka det maximala antalet anslutna klienter varje dag/vecka, undersök trendförändringar.
Så här gör du:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Storlek
Den faktiska diskstorleken som används av databasen måste övervakas. I de flesta fall fortsätter databasstorleken att växa, så det är tillväxttakten som är mer intressant. Återigen, var försiktig med ökad tillväxthastighet efter nya applikationssläpp.
Åtgärd:Övervaka tillväxten av databasens storlek under varje vecka/månad, undersök trender, omtilldelning.
Så här gör du:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Bordsvällning över alla bord
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 kan göras på databasnivå som en total över alla tabeller, med möjligheten att gå ner i de "mest uppsvällda tabellerna".
Åtgärd:Övervaka kontinuerligt den totala uppsvällningen 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.
4. Indexuppsvällning över alla index
Uppsvällda index kan bromsa insättningar och minska uppslagsprestanda. Övervaka uppsvällningen av index som både ett absolut värde (antal byte) och i procent. Index kommer att behöva byggas om när de blir för uppsvällda.
Åtgärd:Övervaka kontinuerligt den totala uppsvällningen 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.
5. Långa transaktioner
Transaktioner som är öppna för länge är inte goda nyheter för PostgreSQL. Långa transaktioner kan orsaka kvarhållande av WAL-filer, kan hänga på lås och förhindra vakuum. Applikationer bör utformas för att hålla transaktionstiden så kort som möjligt.
En backend som kör en långvarig transaktion kan dödas med pg_cancel_backend() och pg_terminate_backend() funktioner.
Åtgärd:Övervaka kontinuerligt antalet transaktioner som har körts i mer än en viss tidsperiod, varna om värdena överstiger en inställd tröskel.
Så här gör du:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. dödlägen
I PostgreSQL placerar backends lås på rader och tabeller implicit när det handlar om att köra frågor som ändrar rader. Frågor kan också placera explicita lås (som VÄLJ .. FÖR UPPDATERING ). Precis som i flertrådsprogrammering kan två transaktioner som placerar lås, antingen implicit eller explicit, i motsatt ordning resultera i ett dödläge.
PostgreSQL kommer att upptäcka dödlägen och kommer att återställa en av de involverade transaktionerna (Alla lås som innehas av en transaktion släpps när den har begåtts eller återställs). Detaljer kommer att loggas i PostgreSQL-loggningsdestinationen.
Applikationer bör utformas för att undvika risken för dödläge. De kan också välja att göra om en transaktion i händelse av dödläge.
Åtgärd:Övervaka antalet dödlägen varje dag/vecka, designa om applikationen för att minska antalet, undersök ändringar.
Så här gör du:
Förekomster av dödlägen, tillsammans med ytterligare information, loggas i PostgreSQL-loggfilen. Använd pgmetrics, pgbadger eller andra PostgreSQL-specifika loggbearbetningsverktyg för att extrahera denna information.
7. Äldsta vakuum
Regelbunden dammsugning av bord, antingen med autovakuum, eller med schemalagda jobb, eller manuellt är ett måste för att hålla bordsarbetet snabbt. Dammsugare kan dock misslyckas av olika anledningar, inklusive långa transaktioner, inaktiva replikeringsplatser etc.
Eftersom regelbunden dammsugning av bord är ganska viktigt i Postgres-världen är det bäst att regelbundet kontrollera om alla bord har dammsugits minst en gång under ett visst intervall.
Och även om de tenderar att vara utom synhåll och utom sinnet, bör systemkatalogerna också dammsugas.
Åtgärd:Kontrollera kontinuerligt om något bord inte har dammsugits under det senaste antalet timmar/dagar, varna om något.
Så här gör du:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Äldsta analys
För att utföra dina SELECT-frågor, frågeplaneraren utarbetar enutförandeplan som beskriver vilka index och tabeller som måste läsas och hur. För att komma fram till en effektiv genomförandeplan behöver planeraren ha statistik om fördelningen av värden, storlekar på tupler och så vidare. Sådan statistisk information om data i en tabell samlas in och underhålls genom analys operationer. Tabeller med uppdaterad statistik resulterar i snabbare frågor och mindre I/O.
Autovakuumprocessen som nämns ovan kör vanligtvis också ANALYS på bordet dammsuger den för att hålla denna information uppdaterad. Men bara detta ger kanske inte tillräcklig analystäckning för dina tabeller. Du vill komplettera genom att köra ANALYSE som schemalagda jobb eller efter betydande tabellmutationer.
För frågeprestanda är det bäst att kontinuerligt kontrollera om alla tabeller har analyserats minst en gång i ett visst intervall.
Åtgärd:Kontrollera kontinuerligt om någon tabell inte har analyserats under det senaste antalet timmar/dagar, varna om någon.
Så här gör du:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;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.
Nästa upp
Nästa del i den här serien kommer att täcka mätvärden på tabellnivå, indexnivå och systemnivå. Håll utkik!