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 derde en laatste deel van een blogreeks en behandelt statistieken op tabel-, index- en systeemniveau. De eerste omvatte metrische gegevens op clusterniveau en de tweede omvatte metrische gegevens op databaseniveau.
Tabelniveau
Gegevens in een database volgen doorgaans de 80-20-regel. 20% van de tabellen bevatten de meeste gegevens en worden het meest benaderd of gemuteerd. Door alleen voor deze tabellen extra monitoring in te stellen, kunnen belangrijke, maar kleine hoeveelheden inzichten worden verkregen.
Hier zijn enkele statistieken op tabelniveau die het bekijken waard zijn:
1. Tafelgrootte
De werkelijke schijfgrootte die door de tabel wordt gebruikt, moet worden gecontroleerd. In de meeste gevallen blijft de tabel groeien, dus het is de groeisnelheid die interessanter is.
Het is vaak zo dat de groeisnelheid verandert na de uitrol van een nieuwe versie van de applicatie, of een baseline verandering in verkeer/laad/invoerpatronen van de applicatie zelf. Dergelijke wijzigingen moeten worden onderzocht, in ieder geval om te verifiëren dat de nieuwe snelheid duurzaam is door de geleverde hardware.
Actie:controleer de toename in grootte van de tabel gedurende elke week/maand, onderzoek abrupte veranderingen.
Hoe:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Tafelzwelling
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.
Deze statistiek kan worden gecontroleerd op individueel tabelniveau, of als een geheel van geselecteerde tabellen, of op databaseniveau.
Actie:controleer continu de opgeblazenheid van de tabel als bytes en percentage, waarschuw als waarden een ingestelde drempel overschrijden, VACUM indien nodig.
Hoe:
Gebruik check_postgres orpgmetrics om bloat-schattingen te krijgen. Zie de wiki voor meer info.
3. Opeenvolgende scans
Wanneer query's worden uitgevoerd die de beschikbare indexen niet optimaal gebruiken, of als de statistische informatie die aan een tabel is gekoppeld te verouderd is, kan het zijn dat Postgres elke rij van de tabel moet doorlopen. Dit heet een sequentiële scan , en is in het algemeen niet erg wenselijk. Wat beter zou zijn, is een indexscan , waar de rijen van een tabel indirect worden benaderd via index opzoeken.
PostgreSQL kan u vertellen hoe vaak een tabel achtereenvolgens is gescand en hoe vaak een index is gebruikt. U kunt dit gebruiken om het aantal opeenvolgende scans bij te houden (als u ze helemaal wilt vermijden) of als percentage van het totale aantal scans.
Actie:controleer continu de seq. aantal scans of percentage, waarschuwing als waarde een ingestelde drempel overschrijdt.
Hoe:
-- 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;Indexniveau
1. Indexgrootte
Indexen kunnen veel schijfruimte in beslag nemen. Elke index van een tabel kan zelf in potentie net zoveel schijfvoetafdruk hebben als de tabel zelf. Het is handig om de totale grootte van indexen in een database of de indexen van belangrijke tabellen in de gaten te houden, vooral in implementaties waar indexen kunnen worden aangemaakt via automatische processen.
Onredelijk grote indexen kunnen het gevolg zijn van een opgeblazen gevoel of gewoon een slecht ontworpen index. In beide gevallen kan het oplossen van de oorzaak (door de index opnieuw op te bouwen of door de query/index te herstructureren) snellere querytijden opleveren, dus het is de moeite waard om grote indexen te onderzoeken.
Actie:controleer de totale omvang van interessante indexen gedurende elke week/maand, onderzoek wanneer deze onredelijk groot zijn.
Hoe:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Indexopgeblazen gevoel
Indexen kunnen ook opgeblazen worden. Er zijn veel te veel factoren, waaronder tableworkload, indextype, Postgres-versie en meer, die bepalen hoe opgeblazen een index wordt. Opgeblazen indexen kunnen het invoegen vertragen en de zoekprestaties verminderen. Controleer de opgeblazenheid van indexen als absolute waarde (aantal bytes) en als percentage. Indexen moeten opnieuw worden opgebouwd als ze te opgeblazen worden.
Actie:controleer continu de indexbloat 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.
3. Cache-hitratio
PostgreSQL slaat vaak bezochte regio's van indexen (en ook tabellen) in het geheugen op. Als u uw zoekopdrachten zo heeft afgestemd dat ze de tabellen niet raken, behalve voor het ophalen van rijen, is de volgende stap om ervoor te zorgen dat de cache maximaal blijft staan voor die belangrijke indexen die uw zoekopdrachten echt versnellen.
Het cachegebruik van een index kan worden gemeten aan de hand van de cachehit-ratio, het percentage blokken van de index dat uit de cache is gelezen ten opzichte van het totale aantal gelezen blokken.
Actie:controleer continu het cache-hitratiopercentage, waarschuw als de waarde onder een ingestelde drempel daalt. Onderzoek lage waarden voor belangrijke indexen.
Hoe:
-- 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;Systeemniveau
Afgezien van PostgreSQL-statistieken, is het belangrijk om een paar statistieken bij te houden van de machine of VM waarop u uw Postgres uitvoert. Je kunt hiervoor elke populaire monitoringoplossing gebruiken, of ze zelfs zelf pakken en volgen.
1. Gebruikt geheugen
Moderne Linux-systemen hebben een complexe geheugenboekhouding. We raden aan om het "gebruikt geheugen" te controleren, dit is het geheugen dat overblijft nadat rekening is gehouden met geheugen dat is gemarkeerd als vrij , als buffers , als in cache , en als plaat . Buffers en cache zullen onder druk bezwijken, en dat geldt ook voor de meeste (meestal meer dan 95%) van de plaat.
Het gebruikte geheugen moet echter over een voldoende lange periode worden gemeten. Als u batchtaken, rapporten, ETL enz. hebt die in het weekend worden uitgevoerd, zou de periode een week zijn. De echte statistiek die u moet controleren, is het maximaal gebruikte geheugen gedurende deze periode.
Naarmate uw database groter wordt, heeft deze waarde de neiging om omhoog te kruipen. U moet ervoor zorgen dat het maximale geheugengebruik binnen een comfortabele limiet van het beschikbare geheugen ligt, bijvoorbeeld 60-80%. Als u dit negeert, zouden uw analyses/OLAP-workloads mislukken vanwege een gebrek aan geheugen.
Actie:controleer het maximaal gebruikte geheugen gedurende een week/per nacht, waarschuw als het een ingestelde drempel overschrijdt, herinrichting.
Hoe :
Het gebruikte geheugen wordt gegeven door MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab ,waar de Mem* velden zijn van /proc/meminfo . Zie dit RedHat-artikel voor meer informatie.
2. Gemiddelde laden
De eenvoudige belastingsgemiddelde waarde is nog steeds de gemakkelijkste en snelste manier om de belasting op een server te schatten. Dit geldt met name voor Postgres-servers, aangezien elke backend een afzonderlijk OS-proces is, en als er meer in een uitvoerbare staat zijn, zal de gemiddelde belastingswaarde toenemen.
Voor een bepaalde Postgres-server moet het belastingsgemiddelde binnen een redelijk bereik blijven gedurende een bedrijfscyclus (zoals een week, inclusief batchverwerkingen).
Actie:bewaak het maximale laadgemiddelde over elke dag/week, onderzoek toenemende trends.
Hoe :
De laadgemiddelden van 1 minuut, 5 minuten en 15 minuten zijn de eerste 3 velden van de eerste regel in het bestand /proc/loadavg .
3. Vrije schijfruimte
Het laatste item in onze lijst is het meest voor de hand liggende item om te controleren:de hoeveelheid vrije schijfruimte in elk bestandssysteem dat wordt gebruikt door uw PostgreSQL-server, inclusief tablespaces, WAL-bestandsdirectory's, back-updirectory's en serverlogbestanden. Als er te veel (honderden miljoenen) bestanden worden aangemaakt in een enkel bestandssysteem, zorg er dan voor dat het aantal gratis inodes ook wordt gecontroleerd. Gebrek aan inodes wordt ook gerapporteerd als weinig schijfruimte.
Actie:controleer continu de vrije schijfruimte en het gebruik van inodes op alle relevante bestandssystemen, waarschuw als waarden onder een ingestelde drempel komen.
Hoe :
Vrije schijfruimte in een bestandssysteem kan niet direct worden opgehaald door een bestand te lezen in /proc . U kunt stat -f /path/to/mount . gebruiken of zelfs df om de gebruikte, vrije en gereserveerde schijfruimte voor een specifiek, aangekoppeld bestandssysteem te achterhalen.
Snelle referentie
Hier is een volledige lijst van alle statistieken die we tot nu toe in deze serie hebben besproken. Houd er rekening mee dat dit slechts de minimale, meest essentiële reeks statistieken is die u moet controleren om te detecteren wanneer er iets mis gaat met uw PostgreSQL-implementatie.
Clusterniveau
- Transactie-ID-bereik
- Aantal backends
- Inactieve replicatieslots
- Backends wachten op sloten
- Backends inactief in transactie
- Replicatievertraging voor actieve verbindingen
- Replicatievertraging voor replicatieslots
- WAL-bestandstelling
- Klaar om te archiveren WAL-bestanden
Databaseniveau
- Verbonden klanten
- Maat
- Tafelgezwel over alle tafels
- Indexbloat over alle indexen
- Langlopende transacties
- Vastgelopen
- Oudste stofzuiger
- Oudste analyse
Tabelniveau
- Tabelgrootte
- Tabelzwelling
- Sequentiële scans
Indexniveau
- Indexgrootte
- Indexbloat
- Cache-hitratio
Systeemniveau
- Gebruikt geheugen
- Gemiddelde laden
- Schijfruimte vrij
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.