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à.
Utilizzo della funzione di autovacuum di PostgreSQL in Amazon RDS for PostgreSQL
Consigliamo vivamente di usare la caratteristica di autovacuum per mantenere l'integrità dell'istanza database di PostgreSQL. La funzione di autovaacuum automatizza l'esecuzione del comando VACUUM e ANALYZE. Verifica la presenza di tabelle con un numero elevato di tuple inserite, aggiornate o eliminate. Dopo questa verifica, recupera lo storage rimuovendo i dati obsoleti o le tuple da database PostgreSQL.
Per impostazione predefinita, la funzione di autovacuum è attivata per le istanze database di Amazon RDS for PostgreSQL create utilizzando uno dei gruppi parametri del database PostgreSQL di default. Queste includono default.postgres10, default.postgres11 e così via. Tutti i gruppi parametri del database PostgreSQL di default hanno un parametro rds.adaptive_autovacuum impostato su 1, in questo modo viene quindi attivata la caratteristica. Per impostazione predefinita vengono impostati anche altri parametri di configurazione associati alla caratteristica di autovacuum. Poiché questi valori di default sono in qualche modo generici, è possibile trarre vantaggio dalla regolazione di alcuni parametri associati alla caratteristica di autovacuum per il carico di lavoro specifico.
Di seguito, puoi trovare ulteriori informazioni sulla funzione di autovacuum e su come regolare alcuni dei relativi parametri sulla tua istanza database di RDS for PostgreSQL. Per informazioni generali, consulta Best practice per l'utilizzo di PostgreSQL.
Argomenti
- Allocazione di memoria per il vacuum
- Riduzione della probabilità che si verifichi il wraparound dell’ID delle transazioni
- Determinare se le tabelle nel database devono essere sottoposte a vacuum
- Determinare quali tabelle sono attualmente idonee per l'Autovacuum
- Determinare se l'Auotvacuum è attualmente in esecuzione e per quanto tempo
- Esecuzione di un congelamento manuale del vacuum
- Indicizzare di nuovo una tabella quando l'autovacuum è in esecuzione
- Gestione di autovacuum con indici di grandi dimensioni
- Altri parametri che influenzano l'autovacuum
- Impostazione dei parametri di autovacuum a livello tabella
- Registrazione delle attività di autovacuum e vacuum
Allocazione di memoria per il vacuum
Uno dei parametri più importanti che influenzano le prestazioni della funzione di autovacuum è il parametro maintenance_work_memmaintenance_work_mem troppo basso, il processo di vacuum potrebbe dover eseguire la scansione della tabella più volte per completare il lavoro. Queste scansioni multiple possono avere un impatto negativo sulle prestazioni
Quando si eseguono i calcoli per determinare il valore del parametro maintenance_work_mem tenere a mente due cose:
L'unità predefinita per questo parametro è il kilobyte (KB).
-
Il parametro
maintenance_work_memfunziona insieme al parametroautovacuum_max_workers. Se si dispone di molte tabelle di piccole dimensioni, assegna più autovacuum_max_workerse menomaintenance_work_mem. Se si dispone di tabelle di grandi dimensioni (ad esempio, maggiori di 100 GB), allocare più memoria e meno processi di lavoro. Si deve avere abbastanza memoria allocata affinché si abbia esito positivo sulle tabelle più grandi. Ogniautovacuum_max_workerspuò utilizzare la memoria allocata. Quindi assicurati che la combinazione processi dei dipendenti e della memoria sia uguale alla memoria totale che si desidera allocare.
In termini generali, per gli host di grandi dimensioni, impostare il parametro maintenance_work_mem su un valore compreso tra uno e due gigabyte (tra 1.048.576 e 2.097.152 KB). Per gli host di dimensioni estremamente grandi, impostare il parametro su un valore compreso tra due e quattro gigabyte (tra 2.097.152 e 4.194.304 KB). Il valore impostato per questo parametro dipende dal carico di lavoro. Amazon RDS ha aggiornato il valore di default per questo parametro in kilobyte come segue.
GREATEST({DBInstanceClassMemory/63963136*1024},65536).
Riduzione della probabilità che si verifichi il wraparound dell’ID delle transazioni
In alcuni casi, le impostazioni del gruppo di parametri correlate all'autovacuum potrebbero non essere abbastanza aggressive da prevenire il wraparound dell'ID delle transazioni. Per risolvere questo problema, RDS for PostgreSQL offre un meccanismo che adatta automaticamente i valori di parametro autovacuum. Ottimizzazione adattiva del parametro di autovacuum è una caratteristica per RDS for PostgreSQL. Una spiegazione dettagliata di Wraparound della transazione
La regolazione adattiva del parametro autovacuum è attivata per impostazione predefinita per le istanze RDS for PostgreSQL con il parametro dinamico rds.adaptive_autovacuum impostato su ON. Si consiglia di tenere questa opzione attivata. Tuttavia, per disattivare l'ottimizzazione adattiva del parametro di autovacuum, impostare il parametro rds.adaptive_autovacuum su 0 o OFF.
Il wraparound dell'ID delle transazioni è ancora possibile quando Amazon RDS regola i parametri di autovacuum. Ti invitiamo a implementare un CloudWatch allarme Amazon per il wraparound degli ID delle transazioni. Per ulteriori informazioni, consulta il post Implementazione di un sistema di avvisi rapidi per il wraparound degli ID transazione in RDS for PostgreSQL
Con l'ottimizzazione adattiva dei parametri dell'autovacuum attivata, Amazon RDS inizia a regolare i parametri dell'autovacuum quando la CloudWatch metrica MaximumUsedTransactionIDs raggiunge il valore del parametro o 500.000.000, a seconda di quale sia il maggiore. autovacuum_freeze_max_age
Amazon RDS continua ad adattare i parametri per l’autovacuum se una tabella continua a tendere verso i wraparound dell’ID della transazione. Ognuno di questi aggiustamenti dedica più risorse all’autovacuum per evitare il wraparound. Amazon RDS aggiorna i seguenti parametri correlati all’autovacuum:
RDS modifica questi parametri solo se il nuovo valore rende l’autovacuum più aggressivo. I parametri vengono modificati nella memoria sull’istanza database. I valori nel gruppo di parametri non vengono modificati. Per visualizzare le impostazioni in memoria correnti, utilizzare il comando SQL PostgreSQL SHOW
Quando Amazon RDS modifica uno qualsiasi dei parametri autovacuum, genera un evento per l’istanza database interessata. Questo evento è visibile sulla AWS Management Console e tramite l'API Amazon RDS. Dopo che la MaximumUsedTransactionIDs CloudWatch metrica è tornata al di sotto della soglia, Amazon RDS ripristina i parametri relativi all'autovacuum in memoria ai valori specificati nel gruppo di parametri. Quindi genera un altro evento corrispondente a questa modifica.
Determinare se le tabelle nel database devono essere sottoposte a vacuum
La seguente query può essere usata per mostrare il numero di transazioni non sottoposte a vacuum in un database. La colonna datfrozenxid di una riga di database pg_database è il margine inferiore sui normali ID di transazione che appaiono nel database. Questa colonna è il minimo dei valori relfrozenxid per tabella all’interno del database.
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
Ad esempio, i risultati dell'esecuzione della query precedente potrebbero essere i seguenti.
datname | age mydb | 1771757888 template0 | 1721757888 template1 | 1721757888 rdsadmin | 1694008527 postgres | 1693881061 (5 rows)
Quando l'età di un database raggiunge i due miliardi di ID di transazioni, si verifica il wraparound ddell’ID della transazione (XID) e il database entra in modalità di sola lettura. Puoi utilizzare questa query per produrre un parametro ed eseguirla alcune volte al giorno. Per impostazione predefinita, l'autovacuum è impostato per mantenere l'età delle transazioni a non più di 200,000,000 (autovacuum_freeze_max_age
Un esempio di strategia di monitoraggio potrebbe avere questo aspetto:
Impostare il valore
autovacuum_freeze_max_agesu 200 milioni di transazioni.Se una tabella raggiunge 500 milioni di transazioni senza vacuum, viene attivato un allarme a bassa gravità. Questo non è un valore irragionevole, ma può indicare che l'autovacuum non riesce a mantenere il passo.
Se una tabella invecchia a un miliardo, questo dovrebbe essere trattato come un allarme per cui intervenire. In generale, si desidera mantenere le età più vicine a
autovacuum_freeze_max_ageper motivi di prestazioni. Si consiglia di investigare utilizzando le raccomandazioni che seguono.Se una tabella raggiunge 1,5 milioni di transazioni senza vacuum, viene attivato un allarme a gravità elevata. A seconda della velocità con cui il database utilizza gli ID delle transazioni, questo allarme può indicare che il tempo del sistema per eseguire l'autovacuum sta per scadere. In questo caso, consigliamo di risolvere il problema immediatamente.
Se una tabella superando costantemente queste soglie, modifica ulteriormente i parametri dell'autovacuum. Per impostazione predefinita, l’utilizzo manuale di VACUUM (che ha disabilitato i ritardi basati sui costi) è più aggressivo dell'autovacuum predefinito, ma è anche più intrusivo per il sistema nel suo complesso.
Consigliamo quanto segue:
Attiva un meccanismo di monitoraggio in modo da essere consapevole dell'età delle transazioni più vecchie.
Per informazioni sulla creazione di un processo che fornisce avvisi sul wraparound degli ID transazione, consulta il post nel blog di AWS Database Implementazione di un sistema di avvisi rapidi per il wraparound degli ID transazione in Amazon RDS for PostgreSQL
. Per le tabelle più occupate, eseguire regolarmente un congelamento manuale del vacuum durante una finestra di manutenzione, oltre a fare affidamento sull'autovacuum. Per informazioni sull'esecuzione di un congelamento manuale del vacuum, consulta Esecuzione di un congelamento manuale del vacuum.
Determinare quali tabelle sono attualmente idonee per l'Autovacuum
Spesso, una o due tabelle hanno bisogno del vacuum. Le tabelle il cui valore relfrozenxid sia maggiore del numero di transazioni in autovacuum_freeze_max_age sono sempre destinate all’autovacuum. Altrimenti, se il numero di tuple reso obsoleto dall'ultimo VACUUM supera la soglia del vacuum, la tabella viene sottoposta a vacuum.
La autovacuum threshold (soglia di autovacuum)
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
dove è, è e vacuum base threshold èautovacuum_vacuum_threshold. vacuum scale factor autovacuum_vacuum_scale_factor number of tuples pg_class.reltuples
Mentre sei connesso al database, esegui la seguente query per visualizzare un elenco di tabelle che Autovacuum vede come idonee per il vacuuming.
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM pg_settings WHERE name = 'autovacuum_vacuum_threshold'), vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'), fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'), sto AS (select opt_oid, split_part(setting, '=', 1) as param, split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt) SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation, pg_size_pretty(pg_table_size(c.oid)) as table_size, age(relfrozenxid) as xid_age, coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age, (coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples) AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM pg_class c join pg_namespace ns on ns.oid = c.relnamespace join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1) left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid WHERE c.relkind = 'r' and nspname <> 'pg_catalog' AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float) OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples <= n_dead_tup) ORDER BY age(relfrozenxid) DESC LIMIT 50;
Determinare se l'Auotvacuum è attualmente in esecuzione e per quanto tempo
Se è necessario procedere manualmente con il vacuum in una tabella, devi determinare se l'autovacuum è attualmente in esecuzione. In tal caso, potrebbe essere necessario regolare i parametri per farlo eseguire in modo più efficiente oppure disattivare l'autovacuum temporaneamente in modo da poter eseguire manualmente il VACUUM.
Utilizzare la seguente query per determinare se l'autovacuum è in esecuzione, da quanto tempo è in esecuzione e se è in attesa su un'altra sessione.
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;
Dopo l'esecuzione della query, si dovrebbe visualizzare un output simile a quello riportato di seguito.
datname | usename | pid | state | wait_event | xact_runtime | query --------+----------+-------+--------+------------+-------------------------+-------------------------------------------------------------------------------------------------------- mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound) mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound) mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3 mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+ | | | | | | FROM pg_stat_activity + | | | | | | WHERE query like '%VACUUM%' + | | | | | | ORDER BY xact_start; +
Diversi problemi possono provocare sessioni di autovacuum di lunga esecuzione (che durano più giorni). Il problema più comune è che il valore del parametro maintenance_work_mem
Consigliamo di utilizzare la seguente formula per impostare il valore del parametro maintenance_work_mem.
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
Le sessioni autovacuum a breve esecuzioni possono anche indicare dei problemi:
Può indicare che non ci sono abbastanza
autovacuum_max_workersper il carico di lavoro. In questo caso, sarà necessario indicare il numero di lavoratori.Può indicare che esiste un danneggiamento dell'indice (l'autovacuum si blocca e si riavvia sulla stessa relazione ma non ci sono progressi). In questo caso, esegui un
vacuum freeze verbosemanuale per vedere la causa esatta.table
Esecuzione di un congelamento manuale del vacuum
Si potrebbe voler eseguire un vacuum manuale su una tabella che ha già un processo di vacuum in esecuzione. Ciò è utile se hai identificato una tabella con un'età che si avvicina a 2 miliardi (o al di sopra di qualsiasi soglia monitorata).
I seguenti passaggi sono delle linea guida, con diverse varianti del processo. Ad esempio, durante la verifica, supporre che il valore del parametro maintenance_work_memmaintenance_work_mem, ma è necessario anche agire immediatamente ed eseguire il vacuum della tabella in questione. La procedura seguente mostra cosa fare in questa situazione.
Per eseguire manualmente un congelamento del vacuum
Aprire due sessioni nel database che contiene la tabella che si desidera sottoporre a vacuum. Per la seconda sessione, utilizzare "screen" o un'altra utility che mantiene la sessione se la connessione viene interrotta.
Nella sessione uno, ottieni l’ID di processo (PID) della sessione di autovacuum in esecuzione sulla tabella.
Eseguire la query seguente per ottenere il PID della sessione di autovacuum.
SELECT datname, usename, pid, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY xact_start;Nella sessione due, calcoli la quantità di memoria necessaria per questa operazione. In questo esempio, stabiliamo che è possibile permettersi di utilizzare fino a 2 GB di memoria per questa operazione, pertanto abbiamo impostato
maintenance_work_memper la sessione corrente su 2 GB. SET maintenance_work_mem='2 GB';SETNella sessione 2, inviare un comando
vacuum freeze verboseper la tabella. L'impostazione di verbose è utile perché, anche se al momento non vi è alcun rapporto sullo stato di avanzamento in PostgreSQL, è possibile visualizzare l'attività.\timing onTiming is on.vacuum freeze verbose pgbench_branches;INFO: vacuuming "public.pgbench_branches" INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions in 43 out of 43 pages DETAIL: 0 dead row versions cannot be removed yet. There were 9347 unused item pointers. 0 pages are entirely empty. CPU 0.00s/0.00u sec elapsed 0.00 sec. VACUUM Time: 2.765 ms-
Nella sessione uno, se l'autovacuum bloccava la sessione di vacuum, in
pg_stat_activityvedi che l'attesa è "T" per la sessione di vacuum. In questo caso, è necessario terminare il processo di autovacuum come segue.SELECT pg_terminate_backend('the_pid');In questo momento, inizia la sessione. È importante notare che l'autovacuum si riavvia immediatamente poiché questa tabella è probabilmente la più alta nella lista di lavori.
-
Avvia il comando
vacuum freeze verbosenella sessione due, quindi termina il processo di autovacuum nella sessione uno.
Indicizzare di nuovo una tabella quando l'autovacuum è in esecuzione
Se un indice diventa corrotto, l'autovacuum continua a elaborare la tabella e avrà esito negativo. Setenti di eseguire un vacuum manuale in questa situazione, riceverai un messaggio di errore come il seguente.
postgres=>vacuum freeze pgbench_branches;ERROR: index "pgbench_branches_test_index" contains unexpected zero page at block 30521 HINT: Please REINDEX it.
Quando l'indice è corrotto e l'autovacuum sta tentando l'esecuzione sulla tabella, ci sarà una contesa con una sessione di autovacuum già in esecuzione. Quando si immette un comando REINDEX
Per indicizzare di nuovo una tabella quando l'autovacuum è in esecuzione sulla tabella
Apri due sessioni nel database che contiene la tabella da sottoporre a vacuum. Per la seconda sessione, utilizzare "screen" o un'altra utility che mantiene la sessione se la connessione viene interrotta.
Nella sessione numero uno, ottenere il PID della sessione di autovacuum in esecuzione sulla tabella.
Eseguire la query seguente per ottenere il PID della sessione di autovacuum.
SELECT datname, usename, pid, current_timestamp - xact_start AS xact_runtime, query FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY xact_start;Nella sessione due, rilasciare il comando di reindicizzazione.
\timing onTiming is on.reindex index pgbench_branches_test_index;REINDEX Time: 9.966 msNella sessione uno, se l'autovacuum bloccava il processo, in
pg_stat_activityvedi che l'attesa è "T" per la sessione di vacuum. In questo caso, termina il processo di autovacuum.SELECT pg_terminate_backend('the_pid');In questo momento, inizia la sessione. È importante notare che l'autovacuum si riavvia immediatamente poiché questa tabella è probabilmente la più alta nella lista di lavori.
Avvia il comando nella sessione due, quindi termina il processo di autovacuum nella sessione 1.
Gestione di autovacuum con indici di grandi dimensioni
Come parte del funzionamento, autovacuum esegue diverse fasi di vacuum
Per questo processo, controlla innanzitutto la dimensione complessiva degli indici. Quindi, determina se ci sono indici potenzialmente inutilizzati da rimuovere come mostrato negli esempi seguenti.
Per verificare la dimensione della tabella e dei relativi indici
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));pg_size_pretty 6404 MB (1 row)
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));pg_size_pretty 11 GB (1 row)
In questo esempio, la dimensione degli indici è maggiore della tabella. Questa differenza può causare problemi di prestazioni perché gli indici sono aumentati in dimensioni o inutilizzati, il che influisce sull'autovacuum e sulle operazioni di inserimento.
Per verificare la presenza di indici non utilizzati
Utilizzando la visualizzazione pg_stat_user_indexesidx_scan. Nell'esempio seguente, gli indici non utilizzati hanno idx_scan con il valore 0.
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch -------+------------+------------+------------------+-----------------------+----------+--------------+--------------- 16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0 16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0 16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0 16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0 16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0 16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0 16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0 (7 rows)
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;schemaname | relname | indexrelname | idx_scan ------------+------------------+-----------------------+---------- public | pgbench_accounts | index_f | 6 public | pgbench_accounts | index_b | 3 public | pgbench_accounts | pgbench_accounts_pkey | 0 public | pgbench_accounts | index_d | 0 public | pgbench_accounts | index_e | 0 public | pgbench_accounts | index_c | 0 public | pgbench_accounts | index_a | 0 (7 rows)
Nota
Queste statistiche sono incrementali dal momento in cui vengono ripristinate. Supponi di avere un indice utilizzato solo alla fine di un trimestre lavorativo o solo per un report specifico. È possibile che questo indice non sia stato utilizzato da quando le statistiche sono state ripristinate. Per ulteriori informazioni, consulta Funzioni statistiche
Per verificare quando le statistiche sono state ripristinate l'ultima volta per un database, usa pg_stat_database
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';datname | stats_reset ----------+------------------------------- postgres | 2022-11-17 08:58:11.427224+00 (1 row)
Vacuum di una tabella il più rapidamente possibile
RDS per PostgreSQL 12 e versioni successive
Se sono presenti troppi indici in una tabella di grandi dimensioni, l'istanza database potrebbe essere vicina al wraparound dell'ID di transazione (XID), ovvero quando il contatore XID arriva a zero. Se non controllata, questa situazione potrebbe causare la perdita di dati. Tuttavia, è possibile eseguire rapidamente il vacuum della tabella senza ripulire gli indici. In RDS per PostgreSQL 12 e versioni successive, puoi usare VACUUM con la clausola INDEX_CLEANUP
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;INFO: vacuuming "public.pgbench_accounts" INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517 Skipped 0 pages due to buffer pins, 0 frozen pages. CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
Se è già in esecuzione una sessione di autovacuum, è necessario interromperla per iniziare il VACUUM manuale. Per informazioni sull'esecuzione di un congelamento manuale del vacuum, consulta Esecuzione di un congelamento manuale del vacuum.
Nota
Se si evita di eseguire regolarmente la pulizia, le dimensioni dell'indice potrebbero aumentare, con ripercussioni sulle prestazioni complessive dell'analisi. Come best practice, utilizza la procedura precedente solo per evitare il wraparound dell'ID di transazione.
RDS per PostgreSQL 11 e versioni precedenti
Tuttavia, in RDS per PostgreSQL 11 e versioni precedenti, l'unico modo per eseguire il vacuum più rapidamente è riducendo il numero di indici su una tabella. L'eliminazione di un indice può influire sui piani di query. Ti consigliamo di eliminare prima gli indici inutilizzati, quindi quelli che hanno il wraparound XID molto vicino. Una volta completato il processo di vacuum, è possibile ricreare questi indici.
Altri parametri che influenzano l'autovacuum
La query seguente mostra i valori di alcuni dei parametri che influenzano direttamente l'autovacuum e il suo comportamento. I parametri di autovacuum
SELECT name, setting, unit, short_desc FROM pg_settings WHERE name IN ( 'autovacuum_max_workers', 'autovacuum_analyze_scale_factor', 'autovacuum_naptime', 'autovacuum_analyze_threshold', 'autovacuum_analyze_scale_factor', 'autovacuum_vacuum_threshold', 'autovacuum_vacuum_scale_factor', 'autovacuum_vacuum_threshold', 'autovacuum_vacuum_cost_delay', 'autovacuum_vacuum_cost_limit', 'vacuum_cost_limit', 'autovacuum_freeze_max_age', 'maintenance_work_mem', 'vacuum_freeze_min_age');
Mentre questi riguardano tutti l'autovacuum, alcuni dei più importanti sono:
Impostazione dei parametri di autovacuum a livello tabella
Puoi impostare i parametri di archiviazione
La query seguente mostra quali tabelle attualmente dispongono di opzioni a livello di tabella.
SELECT relname, reloptions FROM pg_class WHERE reloptions IS NOT null;
Un esempio in cui ciò potrebbe essere utile è per tabelle che sono molto più grandi rispetto al resto delle tabelle. Supponi di disporre di una tabella da 300 GB e di altre 30 tabelle da meno di un GB. Se disponi di una tabella da 300 GB e di altre 30 tabelle da meno di 1 GB, puoi impostare alcuni parametri specifici per la tabella di grandi dimensioni in modo da non alterare il comportamento dell'intero sistema.
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
In questo modo si disattiva il ritardo dell'autovacuum basato sul costo per questa tabella a spese di un maggiore utilizzo delle risorse sul sistema. Normalmente, l'autovacuum si ferma per autovacuum_vacuum_cost_delay ogni volta che viene raggiunto autovacuum_cost_limit. Per ulteriori dettagli, consulta la documentazione di PostegreSQL relativa al vacuuming basato sul costo
Registrazione delle attività di autovacuum e vacuum
Le informazioni sulle attività dell'autovacuum vengono inviate a postgresql.log in base al livello specificato nel parametro rds.force_autovacuum_logging_level. Di seguito sono riportati i valori consentiti per questo parametro e le versioni di PostgreSQL per le quali tale valore è l'impostazione predefinita:
disabled(PostgreSQL 10, PostgreSQL 9.6)debug5,debug4,debug3,debug2,debug1info(PostgreSQL 12, PostgreSQL 11)noticewarning(PostgreSQL 13 e versioni successive)error, log,fatal,panic
rds.force_autovacuum_logging_level funziona con il parametro log_autovacuum_min_duration. Il valore del parametro log_autovacuum_min_duration è la soglia (in millisecondi) al di sopra della quale vengono registrate le azioni dell'autovacuum. Un ambiente di -1 non registra nulla, mentre un'impostazione di 0 registra tutte le azioni. Come con rds.force_autovacuum_logging_level, i valori predefiniti per log_autovacuum_min_duration dipendono dalla versione, come segue:
10000 ms– PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 e PostgreSQL 11(empty)– Nessun valore predefinito per PostgreSQL 10 e PostgreSQL 9.6
Consigliamo di impostare rds.force_autovacuum_logging_level su WARNING. Consigliamo anche di impostare log_autovacuum_min_duration su un valore compreso tra 1000 e 5000. Un'impostazione di 5000 registri di attività che richiede più di 5000 millisecondi. Qualsiasi impostazione diversa da -1 registra anche i messaggi se l'azione dell'autovacuum viene ignorata a causa di un blocco in conflitto o di relazioni interrotte simultaneamente. Per ulteriori informazioni, consulta la pagina relativa al vacuum automatico
Per risolvere i problemi, è possibile modificare il parametro rds.force_autovacuum_logging_level in uno dei livelli di debug, da debug1 fino a debug5 per le informazioni più dettagliate. Si consiglia di utilizzare le impostazioni di debug per brevi periodi di tempo e solo per la risoluzione dei problemi. Per ulteriori informazioni, consulta Quando registrare
Nota
PostgreSQL consente all'account rds_superuser di visualizzare le sessioni di autovacuum in pg_stat_activity. Ad esempio, è possibile identificare e terminare una sessione di autovacuum che blocca l'esecuzione di un comando o l'esecuzione più lenta di un comando vacuum emesso manualmente.
