Welke statistieken van uw PostgreSQL-implementatie moet u controleren? Deze reeks blogposts is bedoeld om een minimale, beginnende reeks essentiële monitoringacties te bieden die u moet implementeren om de gezondheid en stabiliteit van uw Postgres-servers te waarborgen.
Dit is het tweede deel van een blogreeks en behandelt parameters op databaseniveau. De eerste omvat parameters op clusterniveau.
Deel 2:Databaseniveau
In dit deel kijken we naar statistieken en informatie die moeten worden gecontroleerd voor elke belangrijke database die u gebruikt.
De meeste van de onderstaande SQL-query's moeten worden uitgevoerd terwijl ze zijn verbonden met de betreffende database.
1. Verbonden klanten
Verbonden clients nemen OS- en systeembronnen in beslag. Postgres heeft een proces-per-client-architectuur, en te veel klanten kunnen de reactietijd van vragen voor iedereen vertragen. Overweeg om PgBouncer orpgpool te gebruiken om het aantal verbindingen dat de Postgres-server moet onderhouden te verminderen.
Houd veranderingen in de baseline in de gaten na applicatie-updates en pieken in verbindingen als gevolg van toegenomen verkeer.
Actie:bewaak het maximale aantal verbonden clients per dag/week, onderzoek trendveranderingen.
Hoe:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Maat
De werkelijke schijfgrootte die door de database wordt gebruikt, moet worden gecontroleerd. In de meeste gevallen blijft de databasegrootte groeien, dus het is de groeisnelheid die interessanter is. Nogmaals, wees op uw hoede voor een verhoogde groeisnelheid na het uitbrengen van nieuwe applicaties.
Actie:controleer de groei van de database gedurende elke week/maand, onderzoek trends, herinrichting.
Hoe:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Tafelopzwellen over alle tafels
Vanwege de MVCC-architectuur van Postgres liggen oudere versies van rijen in de fysieke gegevensbestanden voor elke tabel en worden ze bloat genoemd. . De bewerking om verouderde rijversies te wissen, wordt vacuüm genoemd . Postgres voert een achtergrondproces uit genaamd autovacuum , die kandidaattabellen oppikt (gebaseerd op configureerbare parameters) en ze voor u opzuigt.
Bloat vertraagt tafelbewerkingen en verspilt schijfruimte, en kan zelfs met autovacuüm weglopen. Monitoring van bloat, als een absoluut aantal bytes en een percentage (van dode gegevens tot totale gegevens), is vereist. Dit kan worden gedaan op databaseniveau als een totaal voor alle tabellen, met de mogelijkheid om naar de "meest opgeblazen tabellen" te gaan.
Actie:controleer continu de totale bloat als bytes en percentage, waarschuw als waarden een ingestelde drempel overschrijden.
Hoe:
Gebruik check_postgres orpgmetrics om bloat-schattingen te krijgen. Zie de wiki voor meer info.
4. Indexbloat over alle indexen
Opgeblazen indexen kunnen het invoegen vertragen en de zoekprestaties verminderen. Controleer de opgeblazenheid van indexen als zowel een absolute waarde (aantal bytes) als een percentage. Indexen moeten opnieuw worden opgebouwd als ze te opgeblazen worden.
Actie:controleer continu de totale bloat als bytes en percentage, waarschuw als waarden een ingestelde drempel overschrijden.
Hoe:
Gebruik check_postgres orpgmetrics om bloat-schattingen te krijgen. Zie de wiki voor meer info.
5. Langlopende transacties
Transacties die te lang open staan, zijn geen goed nieuws voor PostgreSQL. Langlopende transacties kunnen leiden tot retentie van WAL-bestanden, kunnen aan sloten blijven hangen en vacuüm voorkomen. Applicaties moeten worden ontworpen om de transactieduur zo laag mogelijk te houden.
Een backend die een langlopende transactie uitvoert, kan worden uitgeschakeld met pg_cancel_backend() en pg_terminate_backend() functies.
Actie:controleer continu het aantal transacties dat langer dan een ingestelde tijdsduur heeft gelopen, waarschuw als waarden een ingestelde drempel overschrijden.
Hoe:
-- 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. Impasses
In PostgreSQL plaatsen backends impliciet vergrendelingen op rijen en tabellen bij het uitvoeren van query's die rijen wijzigen. Query's kunnen ook expliciete vergrendelingen plaatsen (zoals SELECT .. FOR UPDATE ). Net als bij multi-threaded programmeren, kunnen twee transacties waarbij vergrendelingen, impliciet of expliciet, in tegengestelde volgorde worden geplaatst, resulteren in een impasse.
PostgreSQL zal deadlocks detecteren en een van de betrokken transacties terugdraaien (alle vergrendelingen die door een transactie worden vastgehouden, worden vrijgegeven wanneer deze worden vastgelegd of teruggedraaid). Details worden vastgelegd in de PostgreSQL-logbestemming.
Toepassingen moeten zo worden ontworpen dat de mogelijkheid van een impasse wordt vermeden. Ze kunnen er ook voor kiezen om een transactie opnieuw te proberen in geval van een impasse.
Actie:houd het aantal deadlocks per dag/week bij, ontwerp de applicatie opnieuw om het aantal te verminderen, onderzoek wijzigingen.
Hoe:
Het optreden van deadlocks, samen met aanvullende informatie, wordt vastgelegd in het PostgreSQL-logbestand. Gebruik pgmetrics, pgbadger of andere PostgreSQL-specifieke tools voor het verwerken van logbestanden om deze informatie te extraheren.
7. Oudste stofzuiger
Regelmatig stofzuigen van tafels, hetzij met autovacuüm, hetzij met geplande taken, of handmatig, is een must om de tafelwerkzaamheden snel te laten verlopen. Stofzuigers kunnen echter om verschillende redenen mislukken, waaronder langlopende transacties, inactieve replicatieslots, enz.
Aangezien het regelmatig stofzuigen van tafels heel belangrijk is in de Postgres-wereld, is het het beste om regelmatig te controleren of alle tafels minstens één keer per ingestelde interval zijn gestofzuigd.
En hoewel ze meestal uit het zicht en uit het hart zijn, moeten de systeemcatalogustabellen ook worden gestofzuigd.
Actie:controleer continu of een tafel niet is gestofzuigd in het laatste ingestelde aantal uren/dagen, waarschuw indien van toepassing.
Hoe:
-- 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. Oudste analyse
Om uw SELECT-query's uit te voeren, gebruikt de queryplanner stelt eenuitvoeringsplan op die beschrijft welke indexen en tabellen gelezen moeten worden en hoe. Om tot een efficiënt uitvoeringsplan te komen, heeft de planner statistieken nodig over de verdeling van waarden, de grootte van tupels enzovoort. Dergelijke statistische informatie over de gegevens in een tabel wordt verzameld en onderhouden door analyze activiteiten. Tabellen met up-to-date statistieken resulteren in snellere queries en minder I/O.
Het hierboven genoemde autovacuümproces wordt meestal ook uitgevoerd ANALYSE op de tafel stofzuigt het om deze informatie up-to-date te houden. Dit alleen biedt echter mogelijk niet voldoende analysedekking voor uw tabellen. U wilt dit aanvullen door ANALYZE uit te voeren als geplande taken of na aanzienlijke tabelmutaties.
In het belang van de queryprestaties is het het beste om continu te controleren of alle tabellen minstens één keer in een bepaald interval zijn geanalyseerd.
Actie:controleer continu of een tabel niet is geanalyseerd in het laatste ingestelde aantal uren/dagen, waarschuw indien van toepassing.
Hoe:
-- 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;Deze statistieken verzamelen
De bovenstaande secties bieden SQL-instructies om de benodigde metrieken te extraheren uit een draaiende Postgres-server. Als je de scripts liever niet zelf schrijft, bekijk dan de open source tool pgmetrics. Het kan de bovenstaande statistieken en meer verzamelen en deze rapporteren in tekst- en JSON-indeling.
U kunt de pgmetrics-rapporten rechtstreeks naar ons commerciële aanbod, pgDash, sturen, die deze rapporten opslaat en verwerkt om grafieken weer te geven en waarschuwingen uit te voeren.
Volgende Omhoog
Het volgende deel in deze serie gaat over metrische gegevens op tabelniveau, indexniveau en systeemniveau. Blijf op de hoogte!