Lite skötsel och skötsel av din PostgreSQL-distribution räcker långt, vilket garanterar prestanda, undviker obehagliga upptäckter och skapar säker förutsägbarhet. Här är 7 saker som du bör hålla ett öga på.
Table Bloat
PostgreSQL implementerar transaktioner med en teknik som kallas MVCC. MVCC är för lång och involverade ett ämne för att diskutera i detalj, men det finnstre saker du måste vet om det:
- Om du tar bort en rad markeras den bara som "osynlig" för framtida transaktioner.
- Om du uppdaterar en rad skapas en ny version av raden. Den gamla versionen är markerad som osynlig för framtida transaktioner, och den nya versionen är markerad som synlig.
- Med jämna mellanrum måste någon titta på alla transaktioner som körs för närvarande och säga:OK, den äldsta transaktionen här är #42, så varje radversion som är osynlig för #42 kan raderas fysiskt utan att skada datakonsistensen.
Det är så MVCC fungerar (i huvudsak), och innebörden är att uppdateringar kommer öka din fysiska databaslagringsyta, och raderingar kommer inte minska det. MVCC låter som ett lat sätt att göra saker på, men det är populärt eftersom det ger både konsekvens och prestanda.
De oönskade, föråldrade radversionerna i en tabell kallas bloat (eller deadrows ). Processen som kan rensa ut svullnad kallas vakuum . PostgreSQL har en automatiskt utlöst vakuumprocess med inställbara trösklar som kallas autovacuum, och naturligtvis VACUUM-kommandot.
I allmänhet kan bloat också sakta ner frågor på grund av felaktiga synlighetskartor och bortkastad disk I/O.
På grund av detta bör du regelbundet:
- övervaka mängden uppblåsthet i en databas
- kör dammsugare regelbundet
- övervaka om vakuum körs regelbundet för alla tabeller
Det finns några SQL-frågor för att ge uppskattningar per tabell. Verktygsmetriken för öppen källkod ger uppskattningar av uppblåsthet såväl som senaste körtider för manuellt och automatiskt vakuum.
Indexbloat
Index kan också svälla upp. Även om den interna strukturen av index är ogenomskinlig för SQL-användaren och varierar beroende på indextyp (BTree, hash, GIN, GIST, etc.), kvarstår den allmänna idén att när rader som indexet hänvisar till tas bort, upptas utrymmet av den relaterade informationen inuti indexet raderas endast logiskt och släpps inte tillbaka till filsystemet. Det logiskt raderade utrymmet kan återanvändas av indexet senare.
Det finns två sätt att få Postgres att krympa den fysiska storleken på ett index:
- HELA versionen av VACUUM-kommandot
- REINDEX
Indexuppsvällning måste övervakas, så att du åtminstone är medveten om hur mycket utrymme som återstår outnyttjat. I tabeller med hög radavgång är det inte ovanligt att man ställer in vanliga indexombyggnadsjobb.
Indexuppsvällning kan också erhållas genom samma frågor som tidigare, och även via pgmetrics.
Långa transaktioner
Transaktioner bör hållas så korta som möjligt, särskilt i ett MVCC-system.
Föreställ dig att en transaktion startade igår och det blev en vakuumkörning precis efter det. Så länge som denna transaktion är öppen är ytterligare vakuum värdelösa, eftersom vår transaktion per definition kommer att behöva se alla rader i alla tabeller som de var när vår transaktion började igår. Även om vår transaktion är skrivskyddad är detta fortfarande fallet.
Som ett resultat skapar långvariga transaktioner uppblåsthet. De hänger också på systemresurserna, håller oavlåtna lås och ökar chanserna för dödläge.
Det bästa sättet att hålla utkik efter långvariga transaktioner är att ställa in en varning för antalet transaktioner som har pågått under mer än en viss varaktighet. Du kan få detta från statistikvynpg_stat_activity , som så:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;replikeringsfördröjning
När strömmande replikering används för att replikera alla ändringar från en primär PostgreSQL-server till en hot standby (aka read replica), finns det vanligtvis en liten fördröjning mellan det att raduppdateringar sker på den primära och när ändringarna är synliga för applikationer som är anslutna till standby .
Det finns dock fall då denna fördröjning kan öka:
- standbysystemet kan inte ta emot och tillämpa ändringarna från primären tillräckligt snabbt för att hålla jämna steg med det, vanligtvis på grund av hög belastning eller underprovisionering
- ett degraderat nätverk eller disk
- frågekonflikter
Ett standbyläge med en hög eller ännu värre, ökande replikeringsfördröjning kan resultera i förfrågningar på standby som returnerar inaktuella data och ett standbyläge som inte är lämpligt för failover.
Om du har en strömmande replikeringsinställning är övervakning av replikeringsfördröjningar mellan varje primärt standby-par mycket viktigt, och du vill ställa in upalerts för att kontrollera om replikeringsfördröjningar överstiger en minut, eller vilken tröskel som helst som är meningsfull för din installation.
Det här inlägget har mycket mer om hur man mäter och övervakar replikeringsfördröjning från både primär- och standby-slut.
Inaktiva replikeringsplatser
Användningen av replikeringsplatser, introducerad i PostgreSQL 9.4, gör streamingreplikering mer robust och effektiv. I huvudsak rapporterar standby-läget dess replikeringsförlopp till den primära, som lagrar denna information i "replikeringsplatsen".
På grund av detta vet primärledaren nu hela tiden hur långt bakom beredskapen är. Detta gör att den primära kan behålla en tillräcklig eftersläpning av WAL-filer (som behövs för att återuppta replikering) när vänteläget går offline. Så när vänteläget kommer tillbaka, även efter en lång tid, kan den primära fortfarande garantera att replikeringen kan återupptas.
Före replikeringsplatserna kan den primära rensa upp gamla WAL-filer, eftersom den inte visste om den behövde dem eller inte. Om en WAL-fil som behövs av astandby raderas, finns det inget sätt att återuppta replikeringen; det måste konfigureras igen från början.
Men primärens beteende att behålla WAL-filer på obestämd tid leder till ett annat problem. Om ett standby-läge togs bort och den associerade replikeringsplatsen inte togs bort, kommer WAL-filer att behållas för alltid. WAL-filer som behålls av denna anledning är inte föremål för gränserna som anges av max_wal_size och andra konfigurationsalternativ.
Denna situation kommer att kvarstå tills WAL-filer tar upp hela diskutrymmet, utan ens en varning i PostgreSQL-loggfilerna.
Det behöver inte sägas att inaktiva replikeringsplatser måste hanteras när de upptäcks. Hitta dina inaktiva replikeringsplatser med:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analysera status
ANALYSE körs på tabeller för att samla in och uppdatera statistisk information om innehållet i tabellen. Denna information används av frågeplaneraren för att förbereda exekveringsplanen för varje SQL-fråga. Uppdaterad statistik om tabellinnehållet resulterar i en bättre genomförandeplan, vilket i sin tur resulterar i en snabbare fråga.
Autovacuum-demonen kör vanligtvis ANALYSE efter VACUUM. Detta kanske inte är tillräckligt frekvent för ANALYSE dock. Om distributionen av data som går att ändra ofta bör du köra ANALYSE oftare.
Normalt är ANALYZE ganska väluppförd – den behöver bara läsa lås, använder inte för mycket av någon resurs och slutförs inom rimlig tid. Det är säkert att köra den oftare än inte.
Att hålla utkik efter tabeller som inte har analyserats på ett tag är en bra idé. Ta reda på när dina tabeller senast (auto-)analyserades med frågan:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Resursanvändning
Att övervaka CPU-belastningen, minnet och diskanvändningen är en lång väg för att säkerställa att du har tillräckligt med kapacitet till hands för att möta de växande behoven hos applikationerna som använder din databas.
PostgreSQL skapar en process för att hantera en anslutning. Även om detta kanske inte är den mest skalbara arkitekturen nuförtiden, bidrar den mycket på stabilitetsfronten. Det gör också OS-belastningsgenomsnittet mer meningsfullt. Eftersom PostgreSQLboxes vanligtvis endast kör PostgreSQL, betyder ett belastningsmedelvärde på säg 3 vanligtvis att det finns 3 anslutningar som väntar på att CPU-kärnor ska bli tillgängliga för att de kan avskaffas. Att övervaka din maximala belastningsgenomsnitt under en typisk dag eller vecka kan ge en uppskattning av hur över- eller underprovisionerad din låda är på CPU-fronten.
Minne och ledigt diskutrymme är naturligtvis standardsaker att övervaka. Fler anslutningar och längre pågående transaktioner ställer högre krav på minnet. Och medan du övervakar diskutrymme, kom ihåg att spåra det per tabellutrymme.