VACUUM og ANALYSE er de to vigtigste PostgreSQL-databasevedligeholdelsesoperationer.
Et vakuum bruges til at genvinde plads optaget af "døde tupler" i en tabel. En død tuple oprettes, når en post enten slettes eller opdateres (en sletning efterfulgt af en indsættelse). PostgreSQL fjerner ikke fysisk den gamle række fra tabellen, men sætter en "markør" på den, så forespørgsler ikke returnerer denne række. Når en vakuumproces kører, er pladsen optaget af disse døde tupler markeret som genbrugelig af andre tupler.
En "analyse"-operation gør, hvad dens navn siger - den analyserer indholdet af en databases tabeller og indsamler statistik om fordelingen af værdier i hver kolonne i hver tabel. PostgreSQL-forespørgselsmotoren bruger disse statistikker til at finde den bedste forespørgselsplan. Efterhånden som rækker indsættes, slettes og opdateres i en database, ændres kolonnestatistikken også. ANALYSE – enten køre manuelt af DBA eller automatisk af PostgreSQL efter et autovakuum – sikrer, at statistikken er opdateret.
Selvom de lyder relativt ligetil, er bag-kulisserne, støvsugning og analyser to komplekse processer. Heldigvis behøver DBA'er ikke bekymre sig meget om deres interne. Men de er ofte forvirrede over at køre disse processer manuelt eller indstille de optimale værdier for konfigurationsparametrene.
I denne artikel vil vi dele et par bedste fremgangsmåder for VACUUM og ANALYSE.
Tip 1:Kør ikke manuel VAKUUM eller ANALYSER uden grund
PostgreSQL-støvsugning (autovakuum eller manuel vakuum) minimerer bordoppustning og forhindrer transaktions-id-omslutning. Autovacuum genopretter ikke den diskplads, der optages af døde tupler. Kører dog en VACUUM FULL kommando vil gøre det. VACUUM FULL har dog sin præstationsimplikation. Målbordet er udelukkende låst under operationen, hvilket forhindrer jævne aflæsninger på bordet. Processen laver også en fuld kopi af tabellen, hvilket kræver ekstra diskplads, når den kører. Vi anbefaler ikke at køre VACUUM FULL, medmindre der er en meget høj procentdel af oppustethed, og forespørgsler lider hårdt. Vi anbefaler også at bruge perioder med lavest databaseaktivitet til det.
Det er også en god praksis ikke at køre manuelle støvsugere for ofte på hele databasen; måldatabasen kunne allerede være optimalt støvsuget af autovakuumprocessen. Som følge heraf fjerner en manuel støvsuger muligvis ikke nogen døde tuples, men forårsager unødvendige I/O-belastninger eller CPU-spidser. Hvis det er nødvendigt, bør manuelle støvsugere kun køres på en tabel-for-tabel basis, når der er behov for det, såsom lave forhold mellem levende rækker og døde rækker eller store mellemrum mellem autostøvsugere. Manuelle støvsugere bør også køres, når brugeraktivitet er minimum.
Autovacuum holder også en tabels datadistributionsstatistik opdateret (det genopbygger dem ikke). Når den køres manuelt, vil ANALYSE kommando genopbygger faktisk disse statistikker i stedet for at opdatere dem. Igen kan genopbygning af statistikker, når de allerede er optimalt opdateret af en almindelig autovakuum, forårsage unødvendigt pres på systemressourcer.
Det tidspunkt, hvor du skal køre ANALYSE manuelt, er umiddelbart efter masseindlæsning af data i måltabellen. Et stort antal (selv et par hundrede) nye rækker i en eksisterende tabel vil skævvride dens kolonnedatafordeling betydeligt. De nye rækker vil medføre, at alle eksisterende kolonnestatistikker er forældede. Når forespørgselsoptimeringsværktøjet bruger sådanne statistikker, kan forespørgselsydeevnen være meget langsom. I disse tilfælde er det en bedre mulighed at køre kommandoen ANALYSE umiddelbart efter en dataindlæsning for at genopbygge statistikken fuldstændigt end at vente på, at autovakuum starter.
Tip 2:Finjuster Autovacuum Threshold
Det er vigtigt at kontrollere eller justere autovakuum og analysere konfigurationsparametre i postgresql.conf fil eller i individuelle tabelegenskaber for at finde en balance mellem autovakuum og ydeevneforstærkning.
PostgreSQL bruger to konfigurationsparametre til at bestemme, hvornår et autovakuum skal startes:
- autovacuum_vacuum_threshold :dette har en standardværdi på 50
- autovacuum_vacuum_scale_factor :dette har en standardværdi på 0,2
Sammen fortæller disse parametre PostgreSQL at starte et autovakuum, når antallet af døde rækker i en tabel overstiger antallet af rækker i den tabel ganget med skaleringsfaktoren plus vakuumtærsklen. Med andre ord vil PostgreSQL starte autovakuum på et bord, når:
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
For små til mellemstore borde kan dette være tilstrækkeligt. For eksempel, en tabel med 10.000 rækker, skal antallet af døde rækker være over 2.050 ((10.000 x 0,2) + 50), før en autovakuum starter.
Ikke alle tabeller i en database oplever den samme hastighed af dataændringer. Normalt vil nogle få store tabeller opleve hyppige dataændringer og vil som et resultat have et højere antal døde rækker. Standardværdierne virker muligvis ikke for sådanne tabeller. For eksempel, med standardværdierne, skal en tabel med 1 million rækker have mere end 200.050 døde rækker, før en autovakuum starter ((1000.000 x 0,2) + 50). Dette kan betyde længere mellemrum mellem autostøvsugere, stadig længere autovakuumtider og værre, autovakuum kører slet ikke, hvis aktive transaktioner på bordet låser det.
Derfor bør målet være at indstille disse tærskler til optimale værdier, så autovakuum kan ske med regelmæssige intervaller og ikke tager lang tid (og påvirker brugersessioner), samtidig med at antallet af døde rækker holdes relativt lavt.
En tilgang er at bruge den ene eller den anden parameter. Så hvis vi sætter autovacuum_vacuum_scale_factor til 0 og i stedet sætter autovacuum_vacuum_threshold til f.eks. 5.000, vil en tabel blive autostøvsuget, når dens antal døde rækker er mere end 5.000.
Tip 3:Finjuster Autoanalyse-tærskel
I lighed med autovakuum bruger autoanalyse også to parametre, der bestemmer, hvornår autovakuum også udløser en autoanalyse:
- autovacuum_analyze_threshold :dette har en standardværdi på 50
- autovacuum_analyze_scale_factor :dette har en standardværdi på 0,1
Ligesom autovacuum kan parameteren autovacuum_analyze_threshold indstilles til en værdi, der dikterer antallet af indsatte, slettede eller opdaterede tupler i en tabel, før en autoanalyse starter. Vi anbefaler at indstille denne parameter separat på tabeller med store og høje transaktioner. Tabelkonfigurationen vil tilsidesætte postgresql.conf-værdierne.
Kodestykket nedenfor viser SQL-syntaksen til ændring af autovacuum_analyze_threshold-indstillingen for en tabel.
ALTER TABLE <table_name> SET (autovacuum_analyze_threshold = <threshold rows>)
Tip 4:Finjuster autovakuumarbejdere
En anden parameter, der ofte overses af DBA'er, er autovacuum_max_workers , som har en standardværdi på 3. Autovakuum er ikke en enkelt proces, men et antal individuelle vakuumtråde, der kører parallelt. Grunden til at specificere flere arbejdere er for at sikre, at støvsugning af store borde ikke holder op med at støvsuge mindre borde og brugersessioner. Autovacuum_max_workers-parameteren fortæller PostgreSQL at skrue op for antallet af autovacuum-arbejdertråde for at udføre oprydningen.
En almindelig praksis hos PostgreSQL DBA'er er at øge antallet af maksimale arbejdstråde i håb om, at det vil fremskynde autovakuum. Dette virker ikke, da alle trådene deler den samme autovacuum_vacuum_cost_limit , som har en standardværdi på 200. Hver autovakuumgevind er tildelt en omkostningsgrænse ved hjælp af denne formel vist nedenfor:
individual thread’s cost_limit = autovacuum_vacuum_cost_limit / autovacuum_max_workers
Omkostningerne ved arbejde udført af en autovakuumgevind beregnes ved hjælp af tre parametre:
- vacuum_cost_page_hit :dette har en standardværdi på 1
- vacuum_cost_page_miss :dette har en standardværdi på 10
- vacuum_cost_page_dirty :dette har en standardværdi på 20
Hvad disse parametre betyder, er dette:
- Når en vakuumtråd finder den dataside, som den skal rense i den delte buffer, er prisen 1.
- Hvis datasiden ikke er i den delte buffer, men OS-cachen, vil prisen være 10.
- Hvis siden skal markeres snavset, fordi vakuumtråden skulle slette døde rækker, vil prisen være 20.
Et øget antal arbejdstråde vil sænke omkostningsgrænsen for hver tråd. Da hver tråd er tildelt en lavere omkostningsgrænse, vil den gå i dvale oftere, da omkostningstærsklen let nås, hvilket i sidste ende får hele vakuumprocessen til at køre langsomt. Vi anbefaler at øge autovacuum_vacuum_cost_limit til en højere værdi, f.eks. 2000, og derefter justere det maksimale antal arbejdstråde.
En bedre måde er kun at justere disse parametre for individuelle tabeller, når det er nødvendigt. For eksempel, hvis autovakuum af en stor transaktionstabel tager for lang tid, kan tabellen midlertidigt konfigureres til at bruge sin egen vakuumomkostningsgrænse og omkostningsforsinkelser. Omkostningsgrænsen og forsinkelsen vil tilsidesætte de systemdækkende værdier, der er angivet i postgresql.conf.
Kodestykket nedenfor viser, hvordan man konfigurerer individuelle tabeller.
ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_limit = <large_value>) ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_delay = <lower_cost_delay>)
Brug af den første parameter vil sikre, at autovakuumtråden, der er tildelt bordet, udfører mere arbejde, før du går i dvale. Sænkning af autovacuum_vacuum_cost_delay vil også betyde, at tråden sover kortere tid.
Sidste tanker
Som du kan se, er ændring af konfigurationsparametre for vakuum og analyse ligetil, men det kræver omhyggelig observation først. Hver database er forskellig med hensyn til størrelse, trafikmønster og transaktionshastighed. Vi anbefaler, at DBA'er starter med at indsamle nok information om deres database, før de ændrer parametrene eller udruller et manuel vakuum-/analyseregime. Sådanne oplysninger kunne være:
- Antal rækker i hver tabel
- Antal døde tupler i hver tabel
- Tidspunktet for sidste vakuum for hvert bord
- Tidspunktet for sidste analyse for hver tabel
- Hastigheden for dataindsættelse/opdatering/sletning i hver tabel
- Den tid, det tager autovakuum for hvert bord
- Advarsler om, at borde ikke bliver støvsuget
- Aktuel ydeevne for de fleste kritiske forespørgsler og de tabeller, de får adgang til
- Udførelse af de samme forespørgsler efter en manuel vakuum/analyse
Herfra kan DBA'er vælge nogle få "pilot"-tabeller for at begynde at optimere. De kan begynde at ændre vakuum-/analyseegenskaberne for tabellerne og kontrollere ydeevnen. PostgreSQL er en smart databasemotor – DBA'er vil ofte finde ud af, at det nok er bedst at lade PostgreSQL støvsuge og analysere frem for at gøre dem manuelt.