Optimiser, surveiller et dépanner les opérations VACUUM dans PostgreSQL
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document décrit les principes de base de l'opération VACUUM dans les bases de données PostgreSQL. Il décrit également les mécanismes permettant de surveiller et d'ajuster le moteur de base de données qui préserve l'état des instances de base de données.
PostgreSQL utilise un protocole de simultanéité basé sur un instantané qui crée plusieurs versions de lignes de données tout en modifiant les données. Ces versions de lignes de données sont utilisées pour lire une version visible des données à l'aide d'un instantané calculé, sans acquérir de verrou en lecture sur la ligne de données. PostgreSQL gère les ID de transaction (insérés et supprimés) pour chaque ligne de données et utilise ces ID, ainsi que l'instantané calculé, pour déterminer la visibilité de la ligne. À mesure que les données augmentent en raison des anciennes versions des données, le temps nécessaire à l'analyse des données (analyse de table ou analyse d'index) augmente. Pour optimiser le temps de réponse de l'opération d'analyse et utiliser efficacement l'espace, vous devez récupérer les versions et les métadonnées (par exemple, l'ID de transaction) utilisées pour gérer les versions.
L'opération VACUUM récupère les versions supprimées (récupération de mémoire) et les ID de transaction (fige l'ID de transaction). L'opération VACUUM fonctionne sur des données dans différents modes avec différents niveaux de disponibilité des données. Le blocage des ID de transaction est essentiel à l'état du système de base de données, car le système bloque les rédacteurs chaque fois que l'espace d'ID de transaction utilisé entre dans l'espace réservé.
Les tâches autovacuum que vous configurez en permanence tentent de récupérer l'ID de transaction, mais elles peuvent échouer. Cet échec est soit dû à une configuration insuffisante, soit au taux de création des ID de transaction si élevé que la tâche autovacuum ne peut pas rattraper la charge de travail. Le but de ce document est de vous montrer comment utiliser les opérations VACUUM, ainsi que les mécanismes permettant d'ajuster et de surveiller différents aspects des opérations VACUUM.
Aperçu
Ce document couvre les points suivants:
Figer des ID de transaction
Surveiller les ID de transaction.
Récupération de l'espace de stockage
Configurer des alertes Cloud Monitoring automatiques
Pour lire le livre blanc en entier, cliquez sur le bouton :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)"]]
