Delen via

Automatisch afstemmen in Azure Database for PostgreSQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Dit artikel bevat een overzicht van de functie autovacuum voor flexibele Azure Database for PostgreSQL-server en de handleidingen voor het oplossen van problemen met functies die beschikbaar zijn voor het bewaken van de database-bloat, autovacuum-blockers. Het biedt ook informatie over hoe ver de database zich bevindt van de situatie in noodgevallen of terugloop.

Wat is autovacuum?

Autovacuum is een PostgreSQL-achtergrondproces waarmee dode tuples automatisch worden opgeschoond en statistieken worden bijgewerkt. Hiermee kunt u de databaseprestaties behouden door automatisch twee belangrijke onderhoudstaken uit te voeren:

  • VACUUM : maakt schijfruimte vrij door dode tuples te verwijderen.
  • ANALYZE - Verzamelt statistieken om de PostgreSQL Optimizer te helpen de beste uitvoeringspaden voor query's te kiezen.

Om ervoor te zorgen dat autovacuum correct werkt, moet de parameter van de autovacuum-server altijd worden ingesteld op AAN. Wanneer deze functie is ingeschakeld, bepaalt PostgreSQL automatisch wanneer u VACUUM of ANALYZE wilt uitvoeren op een tabel, zodat de database efficiënt en geoptimaliseerd blijft.

Autovacuum internals

Autovacuum leest pagina's die zoeken naar dode tuples en als er geen worden gevonden, wordt de pagina verwijderd door Autovacuum. Wanneer autovacuum dode tuples vindt, worden ze verwijderd. De kosten zijn gebaseerd op:

Parameter Description
vacuum_cost_page_hit Kosten voor het lezen van een pagina die zich al in gedeelde buffers bevindt en waarvoor geen schijf is gelezen. De standaardwaarde is ingesteld op 1.
vacuum_cost_page_miss Kosten voor het ophalen van een pagina die zich niet in gedeelde buffers bevindt. De standaardwaarde is ingesteld op 10.
vacuum_cost_page_dirty De kosten van het schrijven naar een pagina wanneer er dode tuples in worden gevonden. De standaardwaarde is ingesteld op 20.

De hoeveelheid werk die autovacuum uitvoert, is afhankelijk van twee parameters:

Parameter Description
autovacuum_vacuum_cost_limit De hoeveelheid werk die autovacuum in één gebruik doet.
autovacuum_vacuum_cost_delay Het aantal milliseconden dat autovacuum in slaap staat nadat de kostenlimiet is bereikt die is opgegeven door de autovacuum_vacuum_cost_limit parameter.

In alle momenteel ondersteunde versies van Postgres is de standaardwaarde autovacuum_vacuum_cost_limit 200 (in feite ingesteld op -1, waardoor deze gelijk is aan de waarde van de reguliere vacuum_cost_limitwaarde, die standaard 200 is).

Wat betreft autovacuum_vacuum_cost_delay, in Postgres versie 11 wordt het standaard ingesteld op 20 milliseconden, terwijl in Postgres-versies 12 en hoger standaard 2 milliseconden worden gebruikt.

Autovacuum wordt elke seconde 50 keer wakker (50*20 ms=1000 ms). Telkens wanneer het wakker wordt, leest autovacuum 200 pagina's.

Dat betekent dat in autovacuum van één seconde het volgende kan doen:

  • ~80 MB per seconde [ (200 pagina's/vacuum_cost_page_hit) * 50 * 8 kB per pagina] als alle pagina's met dode tuples worden gevonden in gedeelde buffers.
  • ~8 MB per seconde [ (200 pagina's/vacuum_cost_page_miss) * 50 * 8 kB per pagina] als alle pagina's met dode tuples van schijf worden gelezen.
  • ~4 MB per seconde [ (200 pagina's/vacuum_cost_page_dirty) * 50 * 8 kB per pagina] autovacuum kan maximaal 4 MB per seconde schrijven.

Autovacuum bewaken

Gebruik de volgende query's om autovacuum te bewaken:

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;

De volgende kolommen helpen bepalen of autovacuum de tabelactiviteit inhaalt:

Parameter Description
dead_pct Percentage dode tuples in vergelijking met levende tuples.
last_autovacuum De datum van de laatste keer dat de tabel automatisch werd afgevvacueerd.
last_autoanalyze De datum van de laatste keer dat de tabel automatisch is geanalyseerd.

Automatischvacuum activeren

Een automatischevacuum-actie ( ANALYZE of VACUUM) wordt geactiveerd wanneer het aantal dode tuples een bepaald aantal overschrijdt dat afhankelijk is van twee factoren: het totale aantal rijen in een tabel, plus een vaste drempelwaarde. ANALYSEREN wordt standaard geactiveerd wanneer 10% van de tabel plus 50 rijen verandert, terwijl VACUUM wordt geactiveerd wanneer 20% van de tabel plus 50 rijen verandert. Omdat de DREMPELWAARDE VACUUM twee keer zo hoog is als de DREMPELWAARDE ANALYSEREN , wordt ANALYZE eerder geactiveerd dan VACUUM. Voor PG-versies >=13; ANALYSEREN wordt standaard geactiveerd wanneer 20% van de tabel plus 1000 rijen wordt ingevoegd.

De exacte vergelijkingen voor elke actie zijn:

  • Autoanalyze = autovacuum_analyze_scale_factor * tuples + autovacuum_analyze_threshold of autovacuum_vacuum_insert_scale_factor * tuples + autovacuum_vacuum_insert_threshold (voor PG-versies >= 13)
  • Autovacuum = autovacuum_vacuum_scale_factor * tuples + autovacuum_vacuum_threshold

Als we bijvoorbeeld een tabel met 100 rijen hebben. De volgende vergelijking geeft vervolgens de informatie over wanneer de triggers analyseren en vacuüm activeren:

Voor updates/verwijderingen: Autoanalyze = 0.1 * 100 + 50 = 60
Autovacuum = 0.2 * 100 + 50 = 70

Analyseer triggers na 60 rijen in een tabel en vacuümtriggers wanneer er 70 rijen in een tabel worden gewijzigd.

Voor invoegingen: Autoanalyze = 0.2 * 100 + 1000 = 1020

Triggers analyseren na 1020 rijen worden ingevoegd in een tabel

Hier volgt de beschrijving van de parameters die in de vergelijking worden gebruikt:

Parameter Description
autovacuum_analyze_scale_factor Percentage invoegingen/updates/verwijderingen waarmee ANALYSEREN in de tabel wordt geactiveerd.
autovacuum_analyze_threshold Hiermee geeft u het minimum aantal tuples ingevoegd/bijgewerkt/verwijderd om een tabel te analyseren.
autovacuum_vacuum_insert_scale_factor Percentage invoegingen waarmee ANLYZE in de tabel wordt geactiveerd.
autovacuum_vacuum_insert_threshold Hiermee geeft u het minimum aantal tuples op dat is ingevoegd om een tabel te analyseren.
autovacuum_vacuum_scale_factor Percentage updates/verwijderingen waarmee VACUUM op de tabel wordt geactiveerd.

Gebruik de volgende query om de tabellen in een database weer te geven en de tabellen te identificeren die in aanmerking komen voor het autovacuum-proces:

 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;

Notitie

De query houdt er niet rekening mee dat autovacuum per tabel kan worden geconfigureerd met behulp van de DDL-opdracht 'tabel wijzigen'.

Veelvoorkomende problemen met autovacuum

Bekijk de volgende lijst met mogelijke veelvoorkomende problemen met het autovacuum-proces.

Niet bijhouden met bezet server

Het autovacuum-proces schat de kosten van elke I/O-bewerking, verzamelt een totaal voor elke bewerking die wordt uitgevoerd en onderbreekt zodra de bovengrens van de kosten is bereikt. autovacuum_vacuum_cost_delay en autovacuum_vacuum_cost_limit zijn de twee serverparameters die in het proces worden gebruikt.

autovacuum_vacuum_cost_limit Standaard is ingesteld op –1, wat betekent dat de limiet voor autovacuumkosten dezelfde waarde is als de parametervacuum_cost_limit, die standaard 200 is. vacuum_cost_limit is de kosten van een handmatig vacuüm.

Als autovacuum_vacuum_cost_limit dit is ingesteld -1op , gebruikt Autovacuum de vacuum_cost_limit parameter, maar als autovacuum_vacuum_cost_limit zichzelf is ingesteld op groter dan -1 dan dan de autovacuum_vacuum_cost_limit parameter wordt beschouwd.

Als de autovacuum niet bijhoudt, kunnen de volgende parameters worden gewijzigd:

Parameter Description
autovacuum_vacuum_cost_limit Standaard: 200. De kostenlimiet kan worden verhoogd. CPU- en I/O-gebruik op de database moeten worden bewaakt voor en na het aanbrengen van wijzigingen.
autovacuum_vacuum_cost_delay Postgres versie 11 - Standaard: 20 ms. De parameter kan worden verlaagd tot 2-10 ms.
Postgres-versies 12 en hoger - Standaard: 2 ms.

Notitie

  • De autovacuum_vacuum_cost_limit waarde wordt proportioneel verdeeld over de actieve autovacuum-werkrollen, zodat als er meer dan één werkrol is, de som van de limieten voor elke werkrol niet groter is dan de waarde van de autovacuum_vacuum_cost_limit parameter.
  • autovacuum_vacuum_scale_factor is een andere parameter die vacuüm op een tabel kan activeren op basis van dode tuple accumulatie. Standaard: 0.2, Toegestaan bereik: 0.05 - 0.1. De schaalfactor is workloadspecifiek en moet worden ingesteld, afhankelijk van de hoeveelheid gegevens in de tabellen. Voordat u de waarde wijzigt, onderzoekt u de werkbelasting en afzonderlijke tabelvolumes.

Autovacuum voortdurend actief

Continu uitvoeren van autovacuum kan van invloed zijn op het CPU- en IO-gebruik op de server. Hier volgen enkele mogelijke redenen:

maintenance_work_mem

Autovacuum-daemon die autovacuum_work_mem standaard is ingesteld op -1 betekenis autovacuum_work_mem , heeft dezelfde waarde als de parameter maintenance_work_mem. In dit document wordt ervan uitgegaan dat autovacuum_work_mem deze is ingesteld -1 op en maintenance_work_mem wordt gebruikt door de autovacuum-daemon.

Als maintenance_work_mem deze laag is, kan deze worden verhoogd tot maximaal 2 GB op een flexibele Server van Azure Database for PostgreSQL. Een algemene vuistregel is om 50 MB toe te wijzen aan maintenance_work_mem elke 1 GB RAM-geheugen.

Groot aantal databases

Autovacuum probeert elke autovacuum_naptime seconden een werkrol op elke database te starten.

Als een server bijvoorbeeld 60 databases heeft en autovacuum_naptime is ingesteld op 60 seconden, wordt de autovacuum-werkrol elke seconde gestart [autovacuum_naptime/aantal databases].

Het is een goed idee om te verhogen autovacuum_naptime als er meer databases in een cluster zijn. Tegelijkertijd kan het autovacuumproces agressiever worden gemaakt door de autovacuum_cost_limit parameters te verhogen en te verlagen autovacuum_cost_delay en de autovacuum_max_workers standaardwaarde van 3 tot 4 of 5 te verhogen.

Fouten door onvoldoende geheugen

Te agressieve maintenance_work_mem waarden kunnen periodiek fouten in het geheugen veroorzaken in het systeem. Het is belangrijk om inzicht te hebben in het beschikbare RAM-geheugen op de server voordat er wijzigingen in de maintenance_work_mem parameter worden aangebracht.

Autovacuum is te verstorend

Als autovacuum meer resources verbruikt, kunnen de volgende acties worden uitgevoerd:

Parameters voor autovacuum

Evalueer de parameters autovacuum_vacuum_cost_delay, autovacuum_vacuum_cost_limit, autovacuum_max_workers. Het onjuist instellen van autovacuumparameters kan leiden tot scenario's waarbij autovacuum te verstorend wordt.

Als autovacuum te verstorend is, kunt u de volgende acties overwegen:

  • Verhogen autovacuum_vacuum_cost_delay en verlagen autovacuum_vacuum_cost_limit als deze hoger is dan de standaardwaarde van 200.
  • Beperk het aantal autovacuum_max_workers als deze hoger is dan de standaardwaarde van 3.

Te veel autovacuumwerkers

Het verhogen van het aantal autovacuumwerkers verhoogt niet de snelheid van vacuüm. Het is niet raadzaam om een groot aantal autovacuumwerkers te hebben.

Het verhogen van het aantal autovacuum-werkrollen resulteert in meer geheugenverbruik, en afhankelijk van de waarde van maintenance_work_mem , kan prestatievermindering veroorzaken.

Elk autovacuum-werkproces wordt alleen (1/autovacuum_max_workers) van het totaal autovacuum_cost_limit, dus als u een groot aantal werknemers hebt, wordt elke werkrol langzamer.

Als het aantal werknemers wordt verhoogd, autovacuum_vacuum_cost_limit moet ook worden verhoogd en/of autovacuum_vacuum_cost_delay moet worden verlaagd om het vacuümproces sneller te maken.

Als we echter de parameter op tabelniveau autovacuum_vacuum_cost_delay of autovacuum_vacuum_cost_limit parameters instellen, worden de werkrollen die op deze tabellen worden uitgevoerd, uitgesloten van overweging in het taakverdelingsalgoritmen [autovacuum_cost_limit/autovacuum_max_workers].

Autovacuum transaction ID (TXID) wraparound-beveiliging

Wanneer een database wordt uitgevoerd op transactie-id wraparound-beveiliging, kan een foutbericht zoals de volgende fout worden waargenomen:

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

Notitie

Dit foutbericht is een langdurig overzicht. U hoeft doorgaans niet over te schakelen naar de modus voor één gebruiker. In plaats daarvan kunt u de vereiste VACUUM-opdrachten uitvoeren en afstemmen om VACUUM snel te laten werken. Hoewel u geen DML (Data Manipulat Language) kunt uitvoeren, kunt u nog steeds VACUUM uitvoeren.

Het probleem met terugloop treedt op wanneer de database niet is opgezogen of er te veel dode tuples zijn die niet door autovacuum worden verwijderd.

Mogelijke redenen voor dit probleem kunnen een van de volgende oorzaken hebben:

Zware werkbelasting

De workload kan in een korte periode te veel dode tuples veroorzaken, waardoor het voor autovacuum lastig is om in te halen. De dode tuples in het systeem vormen een periode die leidt tot een verslechtering van de queryprestaties en leiden tot een terugloopsituatie. Een van de redenen waarom deze situatie zich voordoet, kan zijn dat autovacuum-parameters niet voldoende zijn ingesteld en de server niet bezet blijft.

Langlopende transacties

Bij langdurige transacties in het systeem kunnen dode tuples niet worden verwijderd terwijl autovacuum wordt uitgevoerd. Ze zijn een obstakel voor het vacuümproces. Als u de langlopende transacties verwijdert, worden dode tuples vrijgemaakt voor verwijdering wanneer autovacuum wordt uitgevoerd.

Langlopende transacties kunnen worden gedetecteerd met behulp van de volgende query:

    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;

Voorbereide instructies

Als er voorbereide instructies zijn die niet worden doorgevoerd, zouden ze voorkomen dat dode tuples worden verwijderd.
Met de volgende query kunt u niet-gegenereerde voorbereide instructies vinden:

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

Gebruik COMMIT PREPARED of ROLLBACK VOORBEREID om deze instructies door te voeren of terug te draaien.

Ongebruikte replicatiesites

Ongebruikte replicatiesites voorkomen dat autovacuum dode tuples claimt. Met de volgende query kunt u ongebruikte replicatiesites identificeren:

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

Gebruik pg_drop_replication_slot() dit om ongebruikte replicatiesites te verwijderen.

Wanneer de database wordt uitgevoerd op transactie-id wraparound-beveiliging, controleert u op eventuele blokkeringen zoals eerder vermeld en verwijdert u de obstakels handmatig om automatisch door te gaan en te voltooien. U kunt ook de snelheid van autovacuum verhogen door in te stellen autovacuum_cost_delay op 0 en de autovacuum_cost_limit waarde groter dan 200 te verhogen. Wijzigingen in deze parameters zijn echter niet van toepassing op bestaande autovacuum-werkrollen. Start de database opnieuw op of beëindig bestaande werkrollen handmatig om parameterwijzigingen toe te passen.

Tabelspecifieke vereisten

Autovacuum-parameters kunnen worden ingesteld voor afzonderlijke tabellen. Het is vooral belangrijk voor kleine en grote tabellen. Voor een kleine tabel die slechts 100 rijen bevat, activeert autovacuum bijvoorbeeld de vacuümbewerking wanneer 70 rijen worden gewijzigd (zoals eerder is berekend). Als deze tabel regelmatig wordt bijgewerkt, ziet u mogelijk honderden autovacuumbewerkingen per dag, waardoor autovacuum geen andere tabellen kan onderhouden waarop het percentage wijzigingen niet zo belangrijk is. Een tabel met een miljard rijen moet ook 200 miljoen rijen wijzigen om automatischevacuum-bewerkingen te activeren. Als u autovacuumparameters instelt, voorkomt u dergelijke scenario's op de juiste manier.

Als u de instelling voor automatischevacuum per tabel wilt instellen, wijzigt u de serverparameters als de volgende voorbeelden:

    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);

Alleen-invoegen workloads

In versies van PostgreSQL <= 13 wordt autovacuum niet uitgevoerd op tabellen met een alleen-invoegworkload, omdat er geen dode tuples zijn en geen vrije ruimte die moet worden vrijgemaakt. Autoanalyze wordt echter uitgevoerd voor werkbelastingen die alleen invoegen, omdat er nieuwe gegevens zijn. De nadelen hiervan zijn:

  • De zichtbaarheidskaart van de tabellen wordt niet bijgewerkt, waardoor queryprestaties, met name wanneer er alleen indexscans zijn, na verloop van tijd last krijgen van queryprestaties.
  • De database kan worden uitgevoerd op transactie-id wraparound-beveiliging.
  • Hint-bits zijn niet ingesteld.

Oplossingen

Postgres-versies <= 13

Met behulp van de pg_cron-extensie kan een cron-taak worden ingesteld om een periodieke vacuümanalyse op de tabel te plannen. De frequentie van de cron-taak is afhankelijk van de werkbelasting.

Zie speciale overwegingen voor het gebruik van pg_cron in Azure Database for PostgreSQL Flexible Server voor hulp.

Postgres 13 en hogere versies

Autovacuum wordt uitgevoerd op tabellen met een alleen-invoegworkload. Twee nieuwe serverparameters autovacuum_vacuum_insert_threshold en autovacuum_vacuum_insert_scale_factor helpen bepalen wanneer autovacuum kan worden geactiveerd voor tabellen met alleen-invoegen.

Handleidingen voor probleemoplossing

Met behulp van de handleidingen voor het oplossen van problemen met functies die beschikbaar zijn in de flexibele Server-portal van Azure Database for PostgreSQL, is het mogelijk om bloat op database- of afzonderlijk schemaniveau te bewaken, samen met het identificeren van potentiële obstakels voor het automatischvacuumproces. Er zijn eerst twee handleidingen voor probleemoplossing beschikbaar: automatischevacuum-bewaking die kan worden gebruikt voor het bewaken van bloat op database- of afzonderlijk schemaniveau. De tweede gids voor probleemoplossing is autovacuum-blockers en wraparound, waarmee potentiële autovacuum-blokkers kunnen worden geïdentificeerd. Het biedt ook informatie over de mate waarin de databases op de server zich inpakken of noodsituaties bevinden. De handleidingen voor probleemoplossing delen ook aanbevelingen om potentiële problemen te beperken. De handleidingen voor probleemoplossing instellen om ze te gebruiken, volgen de handleidingen voor het oplossen van problemen met setups.

Proces voor automatischvacuum beëindigen - pg_signal_autovacuum_worker rol

Autovacuum is een zeer belangrijk achtergrondproces omdat het helpt bij efficiënte opslag- en prestatieonderhoud in de database. In het normale autovacuumproces annuleert het zichzelf na de deadlock_timeout. Als een gebruiker DDL-instructie uitvoert in een tabel, moet een gebruiker mogelijk wachten tot het deadlock_timeout interval. Dit staat ook niet toe dat lees-/schrijfbewerkingen worden uitgevoerd in de tabel die is aangevraagd door verschillende verbindingsaanvragen, waardoor de latentie in de transactie wordt toegevoegd.

We hebben een rol 'pg_signal_autovacuum_worker' geïntroduceerd waarmee niet-superuserleden een doorlopende autovacuum-taak kunnen beëindigen. Dit helpt gebruikers om veilige en gecontroleerde toegang te krijgen tot het autovacuum-proces. Niet-supergebruikers kunnen het autovacuumproces annuleren zodra ze de pg_signal_autovacuum_worker rol krijgen met behulp van pg_terminate_backend opdracht. We hebben de pg_signal_autovacuum_worker-rol teruggezet naar Azure Database for PostgreSQL Flexibele server in PostgreSQL-versies 15 en hoger.

Notitie

We raden u niet aan om een doorlopend autovacuum-proces te beëindigen, omdat het beëindigen van het autovacuumproces kan leiden tot tabel- en databasesbloat, wat verder kan leiden tot regressies van peformance. In gevallen waarin er echter een bedrijfskritieke vereiste is met betrekking tot de geplande uitvoering van een DDL-instructie die overeenkomt met het autovacuum-proces, kunnen we toestaan dat niet-supergebruikers de autovacuum op een gecontroleerde en veilige manier beëindigen met behulp van pg_signal_autovacuum_worker rol.

Aanbevelingen van Advisor

Aanbevelingen van Azure Advisor zijn een proactieve manier om te identificeren of een server een hoge bloatverhouding heeft of dat de server een transactieterugloopscenario nadert. U kunt ook Azure Advisor-waarschuwingen maken voor de aanbevelingen.

De aanbevelingen zijn:

  • Hoge bloatverhouding: Een hoge bloatverhouding kan de serverprestaties op verschillende manieren beïnvloeden. Een belangrijk probleem is dat de PostgreSQL Engine Optimizer moeite kan hebben om het beste uitvoeringsplan te selecteren, wat leidt tot verminderde queryprestaties. Daarom wordt een aanbeveling geactiveerd wanneer het bloatpercentage op een server een bepaalde drempelwaarde bereikt om dergelijke prestatieproblemen te voorkomen.

  • Transactieterugloop: dit scenario is een van de ernstigste problemen die een server kan tegenkomen. Zodra uw server zich in deze status bevindt, kan het accepteren van eventuele transacties stoppen, waardoor de server alleen-lezen wordt. Daarom wordt een aanbeveling geactiveerd wanneer de server de drempelwaarde voor 1 miljard transacties overschrijdt.

Gerelateerde inhoud