Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi di prestazioni del vuoto in RDS per PostgreSQL

Questa sezione illustra i fattori che spesso contribuiscono a rallentare le prestazioni del vuoto e come risolvere questi problemi.

Aspirare indici di grandi dimensioni

Il VACUUM processo prevede diverse fasi: inizializzazione, scansione dell'heap, eliminazione degli indici e dell'heap, pulizia degli indici, troncamento dell'heap ed esecuzione della pulizia finale. Durante la scansione, le pagine vengono eliminate, deframmentate e congelate. Una volta completata la scansione dell'heap, gli indici vengono puliti, le pagine vuote vengono restituite al sistema operativo e vengono completate le attività di pulizia finali, come la pulizia della mappa dello spazio libero e l'aggiornamento delle statistiche.

Quando si puliscono gli indici, possono essere necessari più passaggi se l'indice disponibile (o) è insufficiente per elaborare l'indice. maintenance_work_mem autovacuum_work_mem Nelle versioni 16 e precedenti di PostgreSQL, un limite di 1 GB all'allocazione di memoria per l'archiviazione di IDs tuple morte richiedeva spesso più passaggi, specialmente per indici di grandi dimensioni. La versione 17 di PostgreSQL affronta questa limitazione TidStore introducendo un sistema di allocazione dinamica della memoria che sostituisce l'array di allocazione singola. Ciò rimuove il vincolo di 1 GB, migliora l'efficienza della memoria e riduce la probabilità di scansioni multiple per ogni indice.

Tuttavia, anche in PostgreSQL 17, potrebbero essere necessari più passaggi per indici di grandi dimensioni se la memoria disponibile è insufficiente per elaborare l'intero indice in una sola volta. In genere, gli indici di grandi dimensioni tendono a contenere più tuple morte che richiedono più passaggi.

Rilevamento di operazioni di vuoto lente

La postgres_get_av_diag() funzione è in grado di rilevare quando le operazioni di aspirazione funzionano lentamente a causa di una memoria insufficiente. Per ulteriori informazioni su questa funzione, vedereInstallazione di strumenti di monitoraggio e diagnostica dell'autovacuum in RDS per PostgreSQL.

La postgres_get_av_diag() funzione emette i seguenti avvisi quando la memoria disponibile non è sufficiente per completare lo svuotamento dell'indice in un solo passaggio.

rds_tools1.8

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory. 
        Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).

rds_tools1.9

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more 
        memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual 
        vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide.

Quando la postgres_get_av_diag() funzione identifica un'operazione di vuoto lenta che richiede più scansioni dell'indice perché insufficienteautovacuum_work_mem, genera il seguente messaggio:

NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming. 
        For more information, see Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide.

Guida

È possibile applicare le seguenti soluzioni alternative utilizzando il manuale VACUUM FREEZE per accelerare il congelamento della tabella.

Aumenta la memoria per l'aspirazione

Come suggerito dalla postgres_get_av_diag() funzione, è consigliabile aumentare il autovacuum_work_mem parametro per risolvere potenziali vincoli di memoria a livello di istanza. Sebbene autovacuum_work_mem sia un parametro dinamico, è importante notare che affinché la nuova impostazione di memoria abbia effetto, il demone autovacuum deve riavviare i suoi worker. Per eseguire questa operazione:

Questo approccio garantisce che l'allocazione di memoria modificata venga applicata alle nuove operazioni di autovacuum.

Per risultati più immediati, prendi in considerazione l'esecuzione manuale di un'VACUUM FREEZEoperazione con un'maintenance_work_memimpostazione maggiore all'interno della sessione:

SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;

Se utilizzi Amazon RDS e ritieni di aver bisogno di memoria aggiuntiva per supportare valori più elevatiautovacuum_work_mem, maintenance_work_mem oppure prendi in considerazione l'aggiornamento a una classe di istanze con più memoria. Ciò può fornire le risorse necessarie per migliorare le operazioni di aspirazione manuali e automatiche, con conseguente miglioramento delle prestazioni complessive del vuoto e del database.

Disattiva INDEX_CLEANUP

Il manuale VACUUM in PostgreSQL versione 12 e successive consente di saltare la fase di pulizia dell'indice, mentre l'autovacuum di emergenza in PostgreSQL versione 14 e successive lo fa automaticamente in base al parametro. vacuum_failsafe_age

Per ulteriori indicazioni sulla gestione di indici di grandi dimensioni, consulta la documentazione su. Gestione di autovacuum con indici di grandi dimensioni

Aspirazione a indice parallelo

A partire da PostgreSQL 13, gli indici possono essere aspirati e puliti in parallelo per impostazione predefinita utilizzando il metodo VACUUM manuale, con un processo vacuum worker assegnato a ciascun indice. Tuttavia, per consentire a PostgreSQL di determinare se un'operazione sotto vuoto è idonea per l'esecuzione parallela, devono essere soddisfatti criteri specifici:

Puoi modificare l'max_parallel_maintenance_workersimpostazione in base al numero di v CPUs disponibili sulla tua istanza Amazon RDS e al numero di indici sulla tabella per ottimizzare i tempi di consegna dell'aspirapolvere.

Per ulteriori informazioni, consulta Parallel vacuuming in Amazon RDS for PostgreSQL e Amazon Aurora PostgreSQL.

Troppe tabelle o database da archiviare

Come indicato nella documentazione The Autovacuum Daemon di PostgreSQL, il demone autovacuum opera attraverso più processi. Ciò include un programma di avvio automatico persistente responsabile dell'avvio dei processi di lavoro di autovacuum per ogni database all'interno del sistema. Il programma di avvio pianifica l'avvio di questi worker all'incirca ogni secondo per database. autovacuum_naptime

Con i database 'N', un nuovo lavoratore inizia all'incirca ogni [autovacuum_naptime/N secondi]. Tuttavia, il numero totale di lavoratori simultanei è limitato dall'autovacuum_max_workersimpostazione. Se il numero di database o tabelle che richiedono l'aspirazione supera questo limite, il database o la tabella successiva verrà elaborata non appena un lavoratore sarà disponibile.

Quando è necessario pulire contemporaneamente molte tabelle o database di grandi dimensioni, tutti gli aspiratori automatici disponibili possono rimanere occupati per un periodo prolungato, ritardando la manutenzione di altre tabelle e database. In ambienti con tassi di transazione elevati, questo collo di bottiglia può aggravarsi rapidamente e potenzialmente portare a problemi di vuoto all'interno dell'istanza Amazon RDS.

Quando postgres_get_av_diag() rileva un numero elevato di tabelle o database, fornisce la seguente raccomandazione:

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.

Guida

Aumenta autovacuum_max_workers

Per velocizzare l'aspirazione, consigliamo di regolare il parametro per consentire l'utilizzo simultaneo di più aspiratori. autovacuum_max_workers Se i problemi di prestazioni persistono, prendi in considerazione la possibilità di scalare la tua istanza Amazon RDS a una classe con più CPUs v, che può migliorare ulteriormente le capacità di elaborazione parallela.

È in funzione un aspirapolvere aggressivo (per evitare che si avvolga)

L'età del database (MaximumUsedTransactionIDs) in PostgreSQL diminuisce solo quando un vuoto aggressivo (per evitare il wraparound) viene completato con successo. Fino alla fine di questo vuoto, l'età continuerà ad aumentare a seconda del tasso di transazione.

La postgres_get_av_diag() funzione genera quanto segue NOTICE quando rileva un vuoto aggressivo. Tuttavia, attiva questa uscita solo dopo che il vuoto è rimasto attivo per almeno due minuti.

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.

Per ulteriori informazioni sull'aspirapolvere aggressivo, vedere Quando un aspirapolvere aggressivo è già in funzione.

È possibile verificare se è in corso un aspirapolvere aggressivo con la seguente interrogazione:

SELECT
    a.xact_start AS start_time,
    v.datname "database",
    a.query,
    a.wait_event,
    v.pid,
    v.phase,
    v.relid::regclass,
    pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
    (
        SELECT
            string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS index_sizes,
    trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
    v.index_vacuum_count || '/' || (
        SELECT
            count(*)
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS step2_vacuum_indexes,
    trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
    age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
    pg_stat_activity a
    INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;

Puoi determinare se si tratta di un vuoto aggressivo (per evitare che si avvolga) controllando la colonna di interrogazione nell'output. La frase «per prevenire l'avvolgimento» indica che si tratta di un vuoto aggressivo.

query                  | autovacuum: VACUUM public.t3 (to prevent wraparound)

Ad esempio, supponiamo di avere un blocker all'età di 1 miliardo di anni di età delle transazioni e una tabella che richieda un vuoto aggressivo per evitare che la transazione si concluda alla stessa età delle transazioni. Inoltre, esiste un altro blocco all'età di 750 milioni di anni di età delle transazioni. Dopo aver eliminato il blocco all'età di 1 miliardo di anni, l'età delle transazioni non scenderà immediatamente a 750 milioni. Rimarrà elevata fino al completamento della tabella che richiede un vuoto aggressivo o fino al completamento di qualsiasi transazione con un fatturato superiore a 750 milioni. Durante questo periodo, l'età delle transazioni del cluster PostgreSQL continuerà a crescere. Una volta completato il processo di sottovuoto, l'età delle transazioni scenderà a 750 milioni, ma ricomincerà ad aumentare fino al termine di un'ulteriore fase di sottovuoto. Questo ciclo continuerà finché persistono queste condizioni, fino a quando l'età delle transazioni non scenderà al livello configurato per l'istanza Amazon RDS, specificato da. autovacuum_freeze_max_age