Optimiza, supervisa y soluciona problemas de operaciones de VACUUM en PostgreSQL
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se describen los aspectos básicos de la operación VACUUM en las bases de datos de PostgreSQL. También se describen los mecanismos para supervisar y ajustar el motor de la base de datos que mantiene el estado de las instancias de la base de datos.
PostgreSQL usa un protocolo de simultaneidad basado en instantáneas que crea varias versiones de filas de datos, a la vez que modifica los datos. Estas versiones de filas de datos se usan para leer una versión visible de los datos mediante una instantánea calculada sin adquirir el bloqueo de lectura en la fila de datos. PostgreSQL mantiene los ID de transacción (los ID de transacción insertados y borrados) para cada fila de datos y usa los ID de transacción junto con la instantánea calculada a fin de determinar la visibilidad de la fila. A medida que los datos crecen debido a las versiones anteriores de los datos, el tiempo necesario para analizar los datos (análisis de tablas o análisis de índices) aumenta. A fin de optimizar el tiempo de respuesta de la operación de análisis y usar el espacio de manera eficiente, debes reclamar las versiones y los metadatos (por ejemplo, ID de transacción) que se usan para mantener las versiones.
La operación VACUUM reclama las versiones borradas (recolección de elementos no utilizados) y los ID de transacción (ID de transacción inmovilizados). La operación VACUUM opera en datos en modos diferentes y con distintos niveles de disponibilidad de datos. Inmovilizar los ID de transacción es fundamental para el estado del sistema de base de datos, ya que el sistema bloquea a los escritores cada vez que el espacio de ID de transacción que se usa entra en un espacio reservado.
Los trabajos autovacuum que configuras intentan reclamar el ID de transacción de forma constante, pero pueden fallar. Este error se debe a una configuración insuficiente o a que la tasa de creación de los ID de transacción es tan alta que el trabajo autovacuum no puede alcanzar a la carga de trabajo. El propósito de este documento es mostrar cómo usar las operaciones VACUUM junto con los mecanismos para ajustar y supervisar diferentes aspectos de las operaciones VACUUM.
Descripción general
En este documento, se abordan los siguientes temas:
Inmovilización de los ID de transacción
Supervisión de los ID de transacción
Reclamo de espacio de almacenamiento
Configuración de alertas automatizadas de Cloud Monitoring
Para leer el informe completo, haz clic en el botón:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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)"]]
