Dela via

Autovacuumoptimering i Azure Database för PostgreSQL

Den här artikeln innehåller en översikt över funktionen autovacuum för Azure Database for PostgreSQL och de felsökningsguider för funktioner som är tillgängliga för att övervaka databasens uppsvälldhet och autovacuum-blockerare. Den innehåller också information om hur långt databasen är från en nödsituation eller omslutande situation.

Kommentar

Den här artikeln beskriver autovacuumjustering för alla PostgreSQL-versioner som stöds i Azure Database for PostgreSQL – flexibel server. Vissa funktioner som nämns är versionsspecifika (till exempel vacuum_buffer_usage_limit för PostgreSQL 16 och senare och autovacuum_vacuum_max_threshold för PostgreSQL 18 och senare).

Vad är autovacuum?

Autovacuum är en PostgreSQL-bakgrundsprocess som automatiskt rensar upp döda tupplar och uppdaterar statistik. Det hjälper till att upprätthålla databasens prestanda genom att automatiskt köra två viktiga underhållsaktiviteter:

  • VACUUM – Frigör utrymme i databasens filer genom att ta bort döda tupplar och markera utrymmet som återanvändbart av PostgreSQL. Det minskar inte nödvändigtvis den fysiska storleken på databasfilerna på disken. Om du vill returnera utrymme till operativsystemet använder du åtgärder som skriver om tabellen (till exempel VACUUM FULL eller pg_repack), som har ytterligare överväganden, till exempel exklusiva lås eller underhållsfönster.
  • ANALYSERA – Samlar in tabell- och indexstatistik som PostgreSQL-frågeplaneraren använder för att välja effektiva exekveringsplaner.

För att säkerställa att autovacuum fungerar korrekt ställer du in autovacuum-serverparametern på ON. När det är aktiverat bestämmer PostgreSQL automatiskt när vacuum eller ANALYZE ska köras på en tabell, vilket säkerställer att databasen förblir effektiv och optimerad.

Automatisk dammsugarens inre funktioner

Autovacuum läser sidor för att hitta döda tupplar. Om den inte hittar några döda tupplar tar autovacuum bort sidan. När autovacuum hittar döda tupplar tar det bort dem. Kostnaden baseras på följande parametrar:

Parameter Beskrivning
vacuum_cost_page_hit Kostnaden för att läsa en sida som redan finns i delade buffertar och som inte behöver en diskläsning. Standardvärdet är 1.
vacuum_cost_page_miss Kostnad för att hämta en sida som inte finns i delade buffertar. Standardvärdet är 10.
vacuum_cost_page_dirty Kostnaden för att skriva till en sida när döda tupplar hittas i den. Standardvärdet är 20.

Mängden arbete som autovacuum utför beror på två parametrar:

Parameter Beskrivning
autovacuum_vacuum_cost_limit Mängden arbete autovacuum gör på en go.
autovacuum_vacuum_cost_delay Antal millisekunder som autovacuum ligger i viloläge när den når den kostnadsgräns som anges av parametern autovacuum_vacuum_cost_limit .

I alla versioner av PostgreSQL som stöds för närvarande är standardvärdet för autovacuum_vacuum_cost_limit 200 (i själva verket är det inställt på -1, vilket gör det lika med värdet för den vanliga vacuum_cost_limit, som är 200 som standard).

Standardvärdet för autovacuum_vacuum_cost_delay är 2 millisekunder i PostgreSQL version 12 och senare (det var 20 millisekunder i version 11).

Gräns för buffertanvändning (PostgreSQL 16+)

Från och med PostgreSQL version 16 kan du använda parametern vacuum_buffer_usage_limit för att styra minnesanvändningen under åtgärderna VACUUM, ANALYZE och autovacuum.

Parameter Beskrivning
vacuum_buffer_usage_limit Anger buffertpoolens storlek för vacuum-, ANALYZE- och autovacuum-åtgärder. Den här parametern begränsar mängden delad buffertcache som de här åtgärderna kan använda, vilket hindrar dem från att förbruka överdrivna minnesresurser.

Den här parametern hjälper till att förhindra att VACUUM och autovacuum avlägsnar för många användbara sidor från delade buffertar, vilket kan förbättra databasens övergripande prestanda under underhållsåtgärder. Standardvärdet anges vanligtvis baserat på shared_buffers, och du kan konfigurera det för att balansera vakuumprestanda med behovet av regelbundna databasåtgärder.

Högsta tröskelvärde för autovacuum (PostgreSQL 18+)

Från och med PostgreSQL version 18 kan du använda parametern autovacuum_vacuum_max_threshold för att ange en övre gräns för antalet tuppeluppdateringar eller borttagningar som utlöser autovacuum.

Parameter Beskrivning
autovacuum_vacuum_max_threshold Anger ett maxantal av tupler som uppdateras eller tas bort före vakuum. När det är inställt på -1inaktiveras det maximala tröskelvärdet. Använd den här parametern för finjusterad kontroll över autovacuum-utlösare på mycket stora tabeller.

Den här parametern är särskilt användbar för stora tabeller där standardskalningsfaktorbaserad utlösare kan leda till att autovacuum väntar för länge innan den körs.

Autovacuum vaknar 50 gånger (50*20 ms=1 000 ms) varje sekund. Varje gång den vaknar läser autovacuum 200 sidor.

Det innebär att i en sekund autovacuum kan göra:

  • ~80 MB/s [ (200 sidor/vacuum_cost_page_hit) * 50 * 8 KB per sida] om alla sidor med döda tupplar finns i delade buffertar.
  • ~8 MB/s [ (200 sidor/vacuum_cost_page_miss) * 50 * 8 KB per sida] om alla sidor med döda tupplar läses från disken.
  • ~4 MB/s [ (200 sidor/vacuum_cost_page_dirty) * 50 * 8 KB per sida] autovacuum kan skriva upp till 4 MB/s.

Övervaka autovacuum

Azure Database for PostgreSQL innehåller följande mått för övervakning av autovacuum.

Autovacuum-mått kan användas för att övervaka och finjustera autovacuums prestanda för Azure Database for PostgreSQL – flexibel server. Varje mått genereras med ett intervall på 30 minuter och har upp till 93 dagars kvarhållning. Du kan skapa aviseringar för specifika mått och du kan dela upp och filtrera måttdata med hjälp av dimensionen DatabaseName .

Så här aktiverar du autovacuum-metrik

  • Autovacuum-mått är inaktiverade som standard.
  • Om du vill aktivera dessa mått anger du serverparametern metrics.autovacuum_diagnostics till ON.
  • Den här parametern är dynamisk, så det krävs ingen omstart av instansen.

Lista över autovacuum-mått

Visningsnamn Mätvärdes-ID Enhet Beskrivning Mått Standard aktiverat
Analysera användartabeller för räknare analyze_count_user_tables Räkna Antal gånger användartabeller enbart har analyserats manuellt i den här databasen. Databasnamn Nej
Autoanalysera användartabeller för räknaren autoanalyze_count_user_tables Räkna Antal gånger användartabeller har analyserats av autovacuum-daemonen i den här databasen. Databasnamn Nej
Användartabeller för autovacuumräknare autovacuum_count_user_tables Räkna Antal gånger som endast användartabeller har dammsugits av autovacuum-daemonen i den här databasen. Databasnamn Nej
Svällnadsprocent (förhandsvisning) bloat_percent Procent Uppskattad uppsvälld procentsats för endast användartabeller. Databasnamn Nej
Beräknade döda rader i användartabeller n_dead_tup_user_tables Räkna Uppskattat antal döda rader för tabeller med endast användare i den här databasen. Databasnamn Nej
Uppskattat antal liverader i användartabeller n_live_tup_user_tables Räkna Uppskattat antal aktiva rader för tabeller med endast användare i den här databasen. Databasnamn Nej
Användartabeller för uppskattade ändringar n_mod_since_analyze_user_tables Räkna Uppskattat antal rader som har ändrats sedan tabeller med endast användare senast analyserades. Databasnamn Nej
Användartabeller analyserade tables_analyzed_user_tables Räkna Antal tabeller med endast användare som har analyserats i den här databasen. Databasnamn Nej
Användartabeller automatisktanalyserade tables_autoanalyzed_user_tables Räkna Antal tabeller endast för användare som har analyserats av daemonen autovacuum i den här databasen. Databasnamn Nej
Användartabeller automatiskt rensade tables_autovacuumed_user_tables Räkna Antal endast användartabeller som har dammsugats av autovacuum-daemonen i den här databasen. Databasnamn Nej
Användartabellräknare tables_counter_user_tables Räkna Antal endast användartabeller i den här databasen. Databasnamn Nej
Användartabeller rensade tables_vacuumed_user_tables Räkna Antal tabeller med endast användare som har dammsugats i den här databasen. Databasnamn Nej
Användartabeller för vakuumräknare vacuum_count_user_tables Räkna Antal gånger som endast användartabeller har dammsugits manuellt i den här databasen (utan att räkna med VACUUM FULL). Databasnamn Nej

Faktorer att tänka på vid användning av autovacuum-mått

  • Autovacuum-mått som använder dimensionen DatabaseName har en gräns på 30 databaser .
  • På SKU:n Burstable är gränsen 10 databaser för mått som använder Dimension DatabaseName.
  • Dimensionsgränsen för DatabaseName tillämpas på OID-kolumnen, vilket återspeglar ordningen för att skapa databasen.

Mer information finns i Autovacuum Metrics(Autovacuum Metrics).

Använd följande frågor för att övervaka autovacuum:

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

Följande kolumner hjälper dig att avgöra om autovacuum kommer ikapp tabellaktiviteten:

Parameter Beskrivning
dead_pct Procentandel döda tupplar jämfört med levande tupplar.
last_autovacuum Datumet för den senaste gången tabellen var autovacuumed.
last_autoanalyze Datumet för den senaste gången tabellen analyserades automatiskt.

Utlösa autovacuum

En autovacuum-åtgärd (ANALYZE eller VACUUM) utlöses när antalet döda tupplar överskrider ett visst tal. Det här talet beror på två faktorer: det totala antalet rader i en tabell plus ett fast tröskelvärde. ANALYZE utlöser som standard när 10% i tabellen plus 50 radändringar inträffar, medan VACUUM utlöses när 20% i tabellen plus 50 radändringar sker. Eftersom VAKUUM-tröskelvärdet är dubbelt så högt som TRÖSKELVÄRDET ANALYSERA utlöses ANALYZE tidigare än VACUUM.

För PostgreSQL-version 13 och senare utlöses ANALYZE som standard när 20% av tabellen plus 1 000 radinfogningar inträffar.

De exakta ekvationerna för varje åtgärd är:

  • Autoanalyze = autovacuum_analyze_scale_factor * tupplar + autovacuum_analyze_threshold eller autovacuum_vacuum_insert_scale_factor * tupplar + autovacuum_vacuum_insert_threshold (för PostgreSQL-versioner 13 och senare)
  • Autovacuum = autovacuum_vacuum_scale_factor * tupplar + autovacuum_vacuum_threshold

Om du till exempel har en tabell med 100 rader visas följande ekvationer när åtgärden analysera och vakuum utlöses:

För uppdateringar och borttagningar: Autoanalyze = 0.1 * 100 + 50 = 60Autovacuum = 0.2 * 100 + 50 = 70

ANALYSERA triggas efter att 60 rader har ändrats i en tabell, och VACUUM triggas när 70 rader ändras i en tabell.

För infogningar: Autoanalyze = 0.2 * 100 + 1000 = 1020

ANALYZE-utlösaren aktiveras efter att 1 020 rader har infogats i en tabell.

Här är beskrivningen av de parametrar som används i ekvationen:

Parameter Beskrivning
autovacuum_analyze_scale_factor Procentandel av infogningar, uppdateringar och borttagningar som utlöser ANALYSERA i tabellen.
autovacuum_analyze_threshold Minsta antal tupplar som infogats, uppdaterats eller tagits bort för att ANALYSERA en tabell.
autovacuum_vacuum_insert_scale_factor Procentandel infogningar som utlöser ANALYSERA i tabellen.
autovacuum_vacuum_insert_threshold Minsta antal tupplar som infogats i ANALYSERA en tabell.
autovacuum_vacuum_scale_factor Procentandel uppdateringar och borttagningar som utlöser VACUUM i tabellen.

Använd följande fråga för att lista tabellerna i en databas och identifiera de tabeller som är kvalificerade för autovacuum-processen:

 SELECT *
      ,n_dead_tup > av_threshold AS av_needed
      ,CASE
        WHEN reltuples > 0
          THEN round(100.0 * n_dead_tup / (reltuples))
        ELSE 0
        END AS pct_dead
    FROM (
      SELECT N.nspname
        ,C.relname
        ,pg_stat_get_tuples_inserted(C.oid) AS n_tup_ins
        ,pg_stat_get_tuples_updated(C.oid) AS n_tup_upd
        ,pg_stat_get_tuples_deleted(C.oid) AS n_tup_del
        ,pg_stat_get_live_tuples(C.oid) AS n_live_tup
        ,pg_stat_get_dead_tuples(C.oid) AS n_dead_tup
        ,C.reltuples AS reltuples
        ,round(current_setting('autovacuum_vacuum_threshold')::INTEGER + current_setting('autovacuum_vacuum_scale_factor')::NUMERIC * C.reltuples) AS av_threshold
        ,date_trunc('minute', greatest(pg_stat_get_last_vacuum_time(C.oid), pg_stat_get_last_autovacuum_time(C.oid))) AS last_vacuum
        ,date_trunc('minute', greatest(pg_stat_get_last_analyze_time(C.oid), pg_stat_get_last_autoanalyze_time(C.oid))) AS last_analyze
      FROM pg_class C
      LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
      WHERE C.relkind IN (
          'r'
          ,'t'
          )
        AND N.nspname NOT IN (
          'pg_catalog'
          ,'information_schema'
          )
        AND N.nspname !~ '^pg_toast'
      ) AS av
    ORDER BY av_needed DESC ,n_dead_tup DESC;

Kommentar

Frågan tar inte hänsyn till att du kan konfigurera autovacuum per tabell med hjälp av DDL-kommandot "alter table".

Vanliga problem med autovacuum

Granska följande lista över vanliga problem med autovacuum-processen.

Inte hålla jämna steg med upptagen server

Autovacuum-processen beräknar kostnaden för varje I/O-åtgärd, ackumulerar en summa för varje åtgärd den utför och pausar när den övre gränsen för kostnaden har nåtts. Processen använder två serverparametrar: autovacuum_vacuum_cost_delay och autovacuum_vacuum_cost_limit.

Som standard autovacuum_vacuum_cost_limit är värdet -1, vilket innebär att autovacuum-kostnadsgränsen använder samma värde som parametern vacuum_cost_limit . Standardvärdet för vacuum_cost_limit är 200. vacuum_cost_limit representerar kostnaden för ett manuellt vakuum.

Om du anger autovacuum_vacuum_cost_limit till -1 använder autovacuum parametern vacuum_cost_limit . Om du anger autovacuum_vacuum_cost_limit ett värde som är större än -1 använder autovacuum parametern autovacuum_vacuum_cost_limit .

Om autovacuum inte håller jämna steg kan du överväga att ändra följande parametrar:

Parameter Beskrivning
autovacuum_vacuum_cost_limit Standard: 200. Du kan öka kostnadsgränsen. Övervaka CPU- och I/O-användning i databasen före och efter ändringar.
autovacuum_vacuum_cost_delay PostgreSQL Version 12 och senare – Standard: 2 ms. Du kan minska det här värdet för mer aggressiv autovacuum.
vacuum_buffer_usage_limit PostgreSQL version 16 och senare – Anger buffertpoolens storlek för vacuum- och autovacuum-åtgärder. Om du justerar den här parametern kan du balansera autovacuum-prestanda med övergripande systemprestanda genom att styra hur mycket delad buffertcache som används under vakuumåtgärder.

Kommentar

  • Värdet autovacuum_vacuum_cost_limit fördelas proportionellt mellan de aktiva autovacuum-arbetarna. Om det finns fler än en arbetare överskrider summan av gränserna för varje arbetare inte värdet för parametern autovacuum_vacuum_cost_limit .
  • autovacuum_vacuum_scale_factor är en annan parameter som kan utlösa vacuum på tabell baserat på död tuple-ackumulering. Standard: 0.2, Tillåtet intervall: 0.05 - 0.1. Skalningsfaktorn är arbetsbelastningsspecifik och bör anges beroende på mängden data i tabellerna. Innan du ändrar värdet undersöker du arbetsbelastningen och enskilda tabellvolymer.

Autovacuum körs hela tiden

Om autovacuum körs kontinuerligt kan det påverka processor- och I/O-användning på servern. Här är några möjliga orsaker:

maintenance_work_mem

Autovacuum-daemonen använder autovacuum_work_mem, vilket är inställt på -1 som standard. Den här standardinställningen innebär att autovacuum_work_mem samma värde används som parametern maintenance_work_mem . Den här artikeln förutsätter autovacuum_work_mem är inställd på -1 och autovacuum daemon använder maintenance_work_mem.

Om maintenance_work_mem är låg kan du öka den upp till 2 GB på en flexibel serverinstans av Azure Database for PostgreSQL. En allmän tumregel är att allokera 50 MB till maintenance_work_mem för varje 1 GB RAM-minne.

Stort antal databaser

Autovacuum försöker starta en arbetare på varje databas varje autovacuum_naptime sekund.

Om en server till exempel har 60 databaser och autovacuum_naptime är inställd på 60 sekunder, startar autovacuum-arbetaren varje sekund [autovacuum_naptime/Antal databaser].

Om det finns fler databaser i klustret bör du öka autovacuum_naptime. Samtidigt gör du autovacuum-processen mer aggressiv genom att öka autovacuum_cost_limit och minska parametrarna autovacuum_cost_delay . Du kan också öka autovacuum_max_workers från standardvärdet 3 till 4 eller 5.

Minnesfel

Alltför aggressiva maintenance_work_mem värden kan regelbundet orsaka minnesfel i systemet. Förstå det tillgängliga RAM-minnet på servern innan du ändrar parametern maintenance_work_mem .

Autovacuum är för störande

Om autovacuum förbrukar för många resurser kan du prova följande åtgärder:

Autovacuum-parametrar

Utvärdera parametrarna autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limitoch autovacuum_max_workers. Felaktig inställning av autovacuum-parametrar kan leda till scenarier där autovacuum blir för störande.

Om autovacuum är för störande bör du överväga följande åtgärder:

  • Öka autovacuum_vacuum_cost_delay och minska autovacuum_vacuum_cost_limit om du anger det högre än standardvärdet 200.
  • Minska antalet autovacuum_max_workers om du anger det högre än standardvärdet 3.

För många autovacuum-arbetare

Att öka antalet autovacuumarbetare ökar inte vakuumhastigheten. Använd inte ett stort antal autovacuum-arbetare.

Att öka antalet autovacuum-arbetare resulterar i mer minnesförbrukning. Beroende på värdet för maintenance_work_memkan det orsaka prestandaförsämring.

Varje autovacuum-arbetsprocess får bara (1/autovacuum_max_workers) av det totala antalet autovacuum_cost_limit, så att ha ett stort antal arbetare gör att var och en går långsammare.

Om du ökar antalet arbetare, öka autovacuum_vacuum_cost_limit och / eller minska autovacuum_vacuum_cost_delay för att göra vakuumprocessen snabbare.

Men om du anger parametern på tabellnivå autovacuum_vacuum_cost_delay eller på autovacuum_vacuum_cost_limit parameternivå undantas de arbetare som körs på dessa tabeller från att beaktas i utjämningsalgoritmen [autovacuum_cost_limit/autovacuum_max_workers].

Autovacuum transaktions-ID (TXID) omslutningsskydd

När en databas stöter på ett omslutande skydd för transaktions-ID visas ett felmeddelande som liknar följande fel:

Database isn't accepting commands to avoid wraparound data loss in database 'xx'
Stop the postmaster and vacuum that database in single-user mode.

Kommentar

Det här felmeddelandet är ett långvarigt förbiseende. Vanligtvis behöver du inte växla till enanvändarläge. Istället kan du köra de nödvändiga VACUUM-kommandona och utföra justering för att VACUUM ska köras snabbt. Även om du inte kan köra något datamanipuleringsspråk (DML) kan du fortfarande köra VACUUM.

Omslutningsproblemet uppstår när databasen inte vakuumiseras eller när autovacuum inte tar bort tillräckligt många döda tupplar.

Möjliga orsaker till det här problemet är följande:

Tung arbetsbelastning

En tung arbetsbelastning orsakar för många döda tupplar under en kort period, vilket gör det svårt för autovacuum att komma ikapp. De döda tupplar i systemet läggs ihop under en period vilket leder till försämrad frågeprestanda och leder till omslutningssituation. En orsak till att den här situationen uppstår kan vara att autovacuum-parametrar inte är tillräckligt inställda och inte håller jämna steg med en upptagen server.

Långvariga transaktioner

En långvarig transaktion i systemet hindrar autovacuum från att ta bort döda tupplar. De blockerar vakuumprocessen. Om du tar bort de långvariga transaktionerna frigörs döda tupplar för borttagning när autovacuum körs.

Långvariga transaktioner kan identifieras med hjälp av följande fråga:

    SELECT pid, age(backend_xid) AS age_in_xids,
    now () - xact_start AS xact_age,
    now () - query_start AS query_age,
    state,
    query
    FROM pg_stat_activity
    WHERE state != 'idle'
    ORDER BY 2 DESC
    LIMIT 10;

Förberedda instruktioner

Om det finns förberedda instruktioner som inte har checkats in förhindrar de att autovacuum tar bort döda tupplar. Följande fråga hjälper dig att hitta obekräftade förberedda instruktioner:

    SELECT gid, prepared, owner, database, transaction
    FROM pg_prepared_xacts
    ORDER BY age(transaction) DESC;

Använd COMMIT PREPARED eller ROLLBACK PREPARED för att föra igenom eller rulla tillbaka dessa instruktioner.

Oanvända replikeringsplatser

Oanvända replikeringsfack förhindrar att autovacuum gör anspråk på döda tupplar. Följande fråga hjälper dig att identifiera oanvända replikeringsplatser:

    SELECT slot_name, slot_type, database, xmin
    FROM pg_replication_slots
    ORDER BY age(xmin) DESC;

Använd pg_drop_replication_slot() för att ta bort oanvända replikeringsplatser.

När databasen stöter på skydd mot transaktions-ID:t söker du efter eventuella blockerare som nämnts tidigare och tar bort blockerarna manuellt för att autovacuum ska fortsätta och slutföras. Du kan också öka hastigheten för autovacuum genom att ange autovacuum_cost_delay till 0 och öka autovacuum_cost_limit till ett värde större än 200. Ändringar i dessa parametrar gäller dock inte för befintliga autovacuum-arbetare. Starta antingen om databasen eller avsluta befintliga arbetare manuellt för att tillämpa parameterändringar.

Tabellspecifika krav

Du kan ange autovacuum-parametrar för enskilda tabeller. De här inställningarna är särskilt viktiga för små och stora tabeller. För en liten tabell som endast innehåller 100 rader utlöser autovacuum till exempel VACUUM-åtgärden när 70 rader ändras (beräknat tidigare). Om du uppdaterar den här tabellen ofta kan du se hundratals autovacuum-åtgärder per dag. Dessa åtgärder förhindrar att autovacuum underhåller andra tabeller där procentandelen ändringar inte är lika betydande. Alternativt måste en tabell som innehåller en miljard rader ändra 200 miljoner rader för att utlösa autovacuum-åtgärder. Om du ställer in autovacuum-parametrar på lämpligt sätt förhindras sådana scenarier.

Om du vill ange autovacuum-inställningar för varje tabell ändrar du serverparametrarna enligt följande exempel:

    ALTER TABLE <table name> SET (autovacuum_analyze_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_analyze_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_delay = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_limit = xx);
    -- For PostgreSQL 16 and later:
    ALTER TABLE <table name> SET (vacuum_buffer_usage_limit = 'xx MB');

Infoga endast arbetsbelastningar

I PostgreSQL version 13 och tidigare körs autovacuum inte på tabeller med endast infogning, eftersom det inte finns några döda tupplar och inget ledigt utrymme som behöver frigöras. Autoanalys körs dock för endast infogningsarbetsbelastningar eftersom det finns nya data. Nackdelarna med det här beteendet är:

  • Synlighetskartan för tabellerna uppdateras inte, och därför börjar frågeprestanda, särskilt där det finns endast indexgenomsökningar, att drabbas över tid.
  • Databasen kan stöta på transaktions-ID:ts omslutande skydd.
  • Tipsbitar har inte angetts.

Lösningar

PostgreSQL version 13 och tidigare

Med hjälp av tillägget pg_cron kan du konfigurera ett cron-jobb för att schemalägga en periodisk vakuumanalys i tabellen. Frekvensen för cron-jobbet beror på arbetsbelastningen.

Mer information finns i särskilda överväganden om hur du använder pg_cron i Azure Database for PostgreSQL.

PostgreSQL 13 och senare versioner

Autovacuum körs på tabeller med en infogningsbaserad arbetsbelastning. Två serverparametrar autovacuum_vacuum_insert_threshold och autovacuum_vacuum_insert_scale_factor, hjälper till att styra när autovacuum kan utlösas i tabeller med endast infogning.

Felsökningsguider

Azure Database for PostgreSQL – flexibel server innehåller felsökningsguider i portalen som hjälper dig att övervaka uppsvälldhet på databas- eller individuell schemanivå och identifiera potentiella blockerare i autovacuum-processen.

Det finns två felsökningsguider:

  • Autovacuum-övervakning – Använd den här guiden för att övervaka uppsvälldhet på databas- eller individuell schemanivå.
  • Autovacuum-blockerare och övergångssituationer – Den här guiden hjälper dig att identifiera potentiella autovacuum-blockerare och ger information om hur långt databaserna på servern är från övergångs- eller akuta situationer.

Felsökningsguiderna delar även rekommendationer för att åtgärda potentiella problem. Information om hur du konfigurerar och använder felsökningsguiderna finns i felsökningsguider för installation.

Avsluta autovacuum-processen: pg_signal_autovacuum_worker funktion

Autovacuum är en viktig bakgrundsprocess eftersom den hjälper till med effektivt lagrings- och prestandaunderhåll i databasen. I den normala autovacuum-processen avbryter den sig själv efter deadlock_timeout. Om en användare kör en DDL-instruktion i en tabell kan användaren behöva vänta tills deadlock_timeout intervallet. Autovacuum tillåter inte körning av läsningar eller skrivningar i tabellen som begärs av olika anslutningsbegäranden, vilket lägger till svarstiden i transaktionen.

Vi introducerade en ny roll pg_signal_autovacuum_worker från PostgreSQL, som gör det möjligt för icke-användare att avsluta en pågående autovacuum-uppgift. Den nya rollen hjälper användare att få säker och kontrollerad åtkomst till autovacuum-processen. Icke-superanvändare kan avbryta autovacuum-processen när de har beviljats rollen pg_signal_autovacuum_worker genom att använda kommandot pg_terminate_backend. Rollen pg_signal_autovacuum_worker är tillgänglig i Azure Database for PostgreSQL i PostgreSQL version 15 och senare.

I sällsynta scenarier, till exempel autovacuum med anti-wraparound, kan arbetsprocesser startas omedelbart efter avslutning eftersom de är viktiga för att förhindra utarmning av transaktions-ID. Följ dessa steg för att minimera upprepade konflikter:

  • Placera DDL-åtgärden i kö innan avslutning.

    • Session 1: Förbered och kör DDL-instruktionen.

    • Session 2: Avsluta autovacuum-processen.

      Viktigt!

      Dessa två steg måste köras back-to-back. Om DDL-instruktionen förblir blockerad för länge kan den innehålla lås och blockera andra DML-åtgärder på servern.

  • Avsluta autovacuum och kör DDL: Om DDL måste köras omedelbart:

    • Avsluta autovacuum-processen med hjälp av pg_terminate_backend().
    • Kör DDL-instruktionen direkt efter avslutningen.

Steg för att undvika upprepade konflikter:

  1. Bevilja rollen till användaren

    GRANT pg_signal_autovacuum_worker TO app_user;
    1. Identifiera process-ID för autovacuum
    SELECT pid, query FROM pg_stat_activity WHERE query LIKE '%autovacuum%' and pid!=pg_backend_pid();

  2. Stoppa autovacuum

    SELECT pg_terminate_backend(<pid>);

  3. Kör DDL-instruktionen omedelbart

    ALTER TABLE my_table ADD COLUMN new_col TEXT;

Kommentar

Vi rekommenderar inte att du avslutar pågående autovacuum-processer eftersom det kan leda till att tabellen och databasen blir uppsvälld, vilket ytterligare kan leda till prestandaregressioner. Men i fall där det finns ett affärskritiskt krav som involverar schemalagd körning av en DDL-instruktion som sammanfaller med autovacuum-processen, kan icke-superanvändare avsluta autovacuum på ett kontrollerat och säkert sätt med hjälp pg_signal_autovacuum_worker av rollen.

Azure Advisor-rekommendationer

Azure Advisor-rekommendationer identifierar proaktivt om en server har en hög överbelastningsgrad eller om servern närmar sig ett transaktionsomslagsscenario. Du kan också skapa Azure Advisor-aviseringar för rekommendationerna.

Rekommendationerna är:

  • Förhållande med hög uppblåsningsgrad: Förhållande med hög uppblåsningsgrad kan påverka serverns prestanda på flera sätt. Ett viktigt problem är att PostgreSQL Engine Optimizer kan ha svårt att välja den bästa körningsplanen, vilket leder till försämrade frågeprestanda. Därför utlöses en rekommendation när uppsvälldhetsprocenten på en server når ett visst tröskelvärde för att undvika sådana prestandaproblem.

  • Transaktionsomslutning: Det här scenariot är ett av de allvarligaste problem som en server kan stöta på. När servern är i det här tillståndet kan den sluta acceptera fler transaktioner, vilket gör att servern blir skrivskyddad. Därför utlöses en rekommendation när servern överskrider tröskelvärdet för 1 miljard transaktioner.

Relaterat innehåll

  • Last updated on