Lidt pleje og pleje af din PostgreSQL-implementering går langt, hvilket sikrer ydeevne, undgår ubehagelige opdagelser og skaber sikker forudsigelighed. Her er 7 ting, du bør holde øje med.
Tabelbloat
PostgreSQL implementerer transaktioner ved hjælp af en teknik kaldet MVCC. MVCC er for lang og involverede et emne til at diskutere i detaljer, men der ertre ting du skal kender til det:
- Hvis du sletter en række, markeres den kun som "usynlig" for fremtidige transaktioner.
- Opdatering af en række opretter en ny version af rækken. Den gamle version er markeret som usynlig for fremtidige transaktioner, og den nye version er markeret som synlig.
- Periodisk skal nogen se på alle de aktuelt kørende transaktioner og sige:OK, den ældste transaktion her er #42, så hver rækkeversion, der er usynlig for #42, kan slettes fysisk uden at skade datakonsistensen.
Det er sådan MVCC fungerer (i det væsentlige), og implikationen er, at opdateringer vil øge din fysiske databaselagerplads, og sletninger vil ikke reducere det. MVCC lyder som en doven måde at gøre tingene på, men det er populært, fordi det giver både konsistens og ydeevne.
De uønskede, forældede rækkeversioner i en tabel kaldes bloat (eller deadrows ). Processen, der kan fjerne oppustethed, kaldes vakuum . PostgreSQL har en automatisk udløst vakuumproces med justerbare tærskler kaldet autovacuum, og selvfølgelig VACUUM-kommandoen.
Generelt kan bloat også bremse forespørgsler på grund af unøjagtige visibilitymaps og spildt disk I/O.
På grund af dette bør du regelmæssigt:
- overvåg mængden af oppustethed i en database
- kør vakuum regelmæssigt
- overvåg, om der køres vakuum regelmæssigt for alle borde
Der er et par SQL-forespørgsler til at give et estimat for bloat pr. tabel. Open source-værktøjsmetrics giver bloat-estimater såvel som sidste køretider med manuel og automatisk vakuum.
Indeks-bloat
Indekser kan også svulme op. Selvom den interne struktur af indekser er uigennemsigtige for SQL-brugeren og varierer afhængigt af indekstypen (BTree, hash, GIN, GIST osv.), er den generelle idé fortsat, at når rækker, der henvises til af indekset, slettes, optages pladsen af den relaterede information. inde i indekset slettes kun logisk og frigives ikke tilbage til filsystemet. Det logisk slettede mellemrum kan genbruges af indekset senere.
Der er to måder at få Postgres til at formindske den fysiske størrelse af et indeks:
- DEN FULDE version af VACUUM-kommandoen
- REINDEX
Indeksbloat skal overvåges, så du i det mindste er opmærksom på mængden af ubrugt plads. I tabeller med høj rækkeafgang er det ikke ualmindeligt at opsætte regelmæssige indeksgenopbygningsjob.
Index bloat kan også opnås ved de samme forespørgsler som før, og også via pgmetrics.
Langvarige transaktioner
Transaktioner bør holdes så korte som muligt, især i et MVCC-system.
Forestil dig, at en transaktion startede i går, og der var en vakuumkørsel lige efter. Så længe denne transaktion er åben, er yderligere vakuum ubrugelige, da vores transaktion pr. definition skal se alle rækkerne af alle tabeller, som de var, da vores transaktion begyndte i går. Selvom vores transaktion er skrivebeskyttet, er dette stadig tilfældet.
Som et resultat skaber langvarige transaktioner oppustethed. De hænger også på systemressourcer, holder uopgivne låse og øger chancerne for dødvande.
Den bedste måde at holde øje med langvarige transaktioner er at oprette en advarsel for antallet af transaktioner, der har kørt i mere end en vis varighed. Du kan få dette fra statistikvisningenpg_stat_activity , sådan:
-- 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;replikeringsforsinkelse
Når streaming-replikering bruges til at replikere alle ændringer fra en primær PostgreSQL-server til en varm standby (også kaldet read replica), er der normalt en lille forsinkelse mellem det tidspunkt, hvor rækkeopdateringer sker på den primære, og når ændringerne er synlige for applikationer, der er tilsluttet standbyen. .
Der er dog tilfælde, hvor denne forsinkelse kan stige:
- standbysystemet er ikke i stand til at modtage og anvende ændringerne fra den primære hurtig nok til at følge med det, normalt på grund af høj belastning eller underprovisionering
- et forringet netværk eller disk
- forespørgselskonflikter
En standby med en høj eller endnu værre, stigende replikeringsforsinkelse kan resultere i forespørgsler på standbyen, der returnerer forældede data og en standby, der er uegnet til failover.
Hvis du har en streaming-replikeringsopsætning, er overvågning af replikeringsforsinkelser mellem hvert primært standby-par meget vigtigt, og du vil gerne indstille upalerts for at kontrollere, om replikeringsforsinkelser overstiger et minut, eller hvilken tærskel, der giver mening for din opsætning.
Dette indlæg har meget mere om, hvordan man måler og overvåger replikeringsforsinkelse fra både primær og standby-ende.
Inaktive replikeringspladser
Brugen af replikationsslots, introduceret i PostgreSQL 9.4, gør streamingreplikering mere robust og effektiv. I det væsentlige rapporterer standby'en dets replikeringsforløb til den primære, som gemmer disse oplysninger i "replikeringspladsen".
Derfor ved den primære nu til enhver tid, hvor langt efter standbyen er. Dette gør det muligt for den primære at bevare en tilstrækkelig backlog af WAL-filer (som er nødvendige for at genoptage replikering), når standby går offline. Når standby-tilstanden kommer tilbage, selv efter lang tid, kan den primære stadig garantere, at replikeringen kan genoptages.
Før replikeringsslots, kan den primære rydde op i gamle WAL-filer, da den ikke havde nogen mulighed for at vide, om dens standbys havde brug for dem eller ej. Hvis en WAL-fil, der kræves af standby, slettes, er der ingen måde at genoptage replikeringen på. det skal konfigureres igen fra bunden.
Men den primære adfærd med at bevare WAL-filer på ubestemt tid fører til et andet problem. Hvis en standby blev trukket tilbage, og den tilknyttede replikeringsplads ikke blev slettet, vil WAL-filer blive bevaret for evigt. WAL-filer, der opbevares af denne grund, er ikke underlagt grænserne fastsat af max_wal_size og andre konfigurationsmuligheder.
Denne situation vil fortsætte, indtil WAL-filer optager hele diskpladsen, uden engang en advarsel i PostgreSQL-logfilerne.
Det er overflødigt at sige, at inaktive replikationsslots skal håndteres, når de detekteres. Find dine inaktive replikeringspladser ved hjælp af:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analyser status
ANALYSE køres på tabeller for at indsamle og opdatere statistisk information om indholdet af tabellen. Disse oplysninger bruges af forespørgselsplanlæggeren til at udarbejde udførelsesplanen for hver SQL-forespørgsel. Opdateret statistik om tabelindholdet resulterer i en bedre eksekveringsplan, som igen resulterer i en hurtigere forespørgsel.
Autovakuum-dæmonen kører normalt ANALYSE efter VACUUM. Dette er muligvis ikke hyppigt nok til at ANALYSE dog. Hvis distributionen af data, der kan ændres ofte, bør du køre ANALYSE oftere.
ANALYSE opfører sig typisk ret godt - det behøver kun læselåse, bruger ikke for meget af nogen ressource og fuldfører inden for rimelig tid. Det er sikkert at stå ved siden af at køre det oftere end ikke.
At holde øje med tabeller, der ikke er blevet ANALYSERET i et stykke tid, er en god idé. Find ud af sidste gang dine tabeller blev (auto-)analyseret med forespørgslen:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Ressourceforbrug
Overvågning af CPU-belastningen, hukommelsen og diskforbruget sikrer, at du har nok kapacitet ved hånden til at imødekomme de voksende behov for applikationerne, der bruger din database.
PostgreSQL afføder én proces til at håndtere én forbindelse. Selvom dette måske ikke er den mest skalerbare arkitektur i dag, bidrager det meget på stabilitetsfronten. Det gør også OS-belastningsgennemsnittet mere meningsfuldt. Da PostgreSQLboxes normalt kun kører PostgreSQL, betyder et belastningsgennemsnit på f.eks. 3 typisk, at der er 3 forbindelser, der venter på, at CPU-kerner bliver tilgængelige for, at de kan beskyttes. Overvågning af dit maksimale belastningsgennemsnit i løbet af en typisk dag eller uge kan give et skøn over, hvor over- eller underforsyning din boks er på CPU-fronten.
Hukommelse og ledig diskplads er selvfølgelig standard ting at overvåge. Flere forbindelser og længere kørende transaktioner stiller højere krav til hukommelsen. Og mens du overvåger diskfri plads, så husk at spore den pr. tablespace.