Ottimizzazione, monitoraggio e risoluzione dei problemi delle operazioni VACUUM in PostgreSQL
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questo documento descrive le nozioni di base dell'operazione VACUUM nei database PostgreSQL. Descrive inoltre i meccanismi per monitorare e ottimizzare il motore del database che mantiene l'integrità delle istanze di database.
PostgreSQL utilizza un protocollo di concorrenza basato su snapshot che crea più versioni delle righe di dati durante la modifica dei dati. Queste versioni delle righe di dati vengono utilizzate per leggere una versione visibile dei dati utilizzando uno snapshot calcolato senza acquisire il blocco di lettura sulla riga di dati. PostgreSQL gestisce gli ID transazione
(ID transazione inseriti ed eliminati) per ogni riga di dati e li utilizza insieme allo snapshot calcolato per determinare la visibilità della riga. Man mano che i dati continuano a crescere a causa delle versioni precedenti, il tempo necessario per eseguire la scansione dei dati (scansione della tabella o scansione dell'indice) aumenta. Per ottimizzare il tempo di risposta dell'operazione di scansione e utilizzare lo spazio in modo efficiente, devi recuperare le versioni e i metadati (ad esempio l'ID transazione) utilizzati per gestirle.
L'operazione VACUUM recupera le versioni eliminate (garbage collection) e gli ID transazione (blocco ID transazione). L'operazione VACUUM agisce sui dati
in modalità diverse con diversi livelli di disponibilità dei dati. Il blocco degli ID transazione è fondamentale per l'integrità del sistema di database perché il sistema blocca gli autori ogni volta che lo spazio degli ID transazione utilizzati entra nello spazio riservato.
I job autovacuum che configuri tentano costantemente di recuperare l'ID transazione, ma possono non riuscire. Questo errore è dovuto a una configurazione insufficiente o al fatto che il tasso di creazione degli ID transazione è così elevato che il job autovacuum non riesce a stare al passo con il carico di lavoro. Lo scopo di questo documento è mostrare come utilizzare le operazioni VACUUM insieme ai meccanismi per ottimizzare e monitorare diversi aspetti delle operazioni VACUUM.
Panoramica
Questo documento illustra quanto segue:
Blocco degli ID transazione.
Monitoraggio degli ID transazione.
Recuperare spazio di archiviazione.
Configurazione di avvisi automatici di Cloud Monitoring.
Per leggere il white paper completo, fai clic sul pulsante:
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 UTC."],[],[],null,["# Optimizing, monitoring, and troubleshooting VACUUM operations in PostgreSQL\n\nThis document describes the fundamentals of the `VACUUM` operation in\n[PostgreSQL](https://www.postgresql.org/)\ndatabases. It also describes the mechanisms to monitor and tune the database\nengine that maintains the health of database instances.\n\nPostgreSQL uses a snapshot-based concurrency protocol that creates multiple\nversions of data rows while modifying the data. These data row versions are used\nto read a visible version of the data using a computed snapshot without\nacquiring read-lock on the data row. PostgreSQL maintains transaction IDs\n(inserted and deleted transaction IDs) for every row of data and uses the\ntransaction IDs along with the computed snapshot to determine the visibility of\nthe row. As the data keeps growing due to old versions of data, the time taken\nto scan the data (table scan or index scan) increases. To optimize the response\ntime of the scan operation and to use space efficiently, you need to reclaim the\nversions and the metadata (for example, transaction ID) that is used to maintain\nthe versions.\n\nThe `VACUUM` operation reclaims the deleted versions (garbage collection) and\ntransaction IDs (freeze transaction ID). The `VACUUM` operation operates on data\nin different modes with different levels of data availability. Freezing\ntransaction IDs is crucial to the health of the database system because the\nsystem blocks writers whenever the used transaction ID space enters reserved\nspace.\n\nThe `autovacuum` jobs that you configure constantly try to reclaim the\ntransaction ID, but they can fail. This failure is either due to insufficient\nconfiguration or because the creation rate for transaction IDs is so high that\nthe `autovacuum` job cannot catch up with workload. The purpose of this document\nis to show how to use the `VACUUM` operations along with the mechanisms to tune\nand monitor different aspects of `VACUUM` operations.\n\nOverview\n--------\n\nThis document covers the following:\n\n- Freezing transaction IDs.\n- Monitoring transaction IDs.\n- Reclaiming storage space.\n- Configuring automated Cloud Monitoring alerts.\n\nTo read the full white paper, click the button:\n\n[Download the PDF](/static/solutions/optimizing-monitoring-troubleshooting-vacuum-operations-postgresql.pdf)"]]
