Mejores prácticas de Vacuum

Un vacuum saludable es invisible hasta que falla. Sigue esta lista de verificación para adelantarte a la hinchazón (bloat), el wraparound y las regresiones de escaneo solo con índices en PostgreSQL 18.4.

Cómo usar esta lista

• Revisa mensualmente las 20 tablas principales por tasa de actualización.
• Alerta sobre age(datfrozenxid) y altas proporciones de n_dead_tup.
• Nunca implementes migraciones que desactiven autovacuum sin un plan de expiración.

A - Política de Autovacuum

• Mantén autovacuum habilitado globalmente y por tabla. No desactives silenciosamente en tablas de hechos (facts).
• Reduce autovacuum_vacuum_scale_factor en tablas grandes y activas (hot tables). El 20% por defecto es demasiado lento a escala.
• Aumenta los workers/IOPS disponibles antes de subir autovacuum_max_workers. Evita conflictos entre vacuum y OLTP.
• Registra las ejecuciones de autovacuum que superen el umbral de duración. Encuentra las lentas.
• Ejecuta VACUUM ANALYZE manualmente después de eliminaciones masivas o COPY. Antes de reabrir BI.

B - Higiene de Transacciones

• Establece idle_in_transaction_session_timeout en los roles de la aplicación. Las transacciones largas bloquean el congelamiento (freeze).
• Monitoriza las ranuras de replicación y el lag de decodificación lógica. Las ranuras retienen xmin en el primario.
• Termina las sesiones huérfanas del pool de aplicaciones atascadas en una transacción. PgBouncer no puede solucionar inactividad del lado del servidor.
• Evita transacciones abiertas durante todo el día en herramientas de administración. Incluidas las pestañas SQL del dashboard.
• Rastrea pg_stat_activity.xact_start en incidentes. Para correlacionar el lag de vacuum.

C - Respuesta a la Hinchazón (Bloat)

• Mide la proporción de tuplas muertas y el tamaño de TOAST antes de VACUUM FULL. Prefiere primero el vacuum in-place.
• Usa pg_repack o el intercambio de particiones para reducir a nivel de SO. Cuando las filas en vivo sean mucho menores que el tamaño del archivo.
• Ejecuta REINDEX CONCURRENTLY cuando se demuestre hinchazón de índice. Después de ajustar el vacuum.
• Considera fillfactor en tablas con actualizaciones extremas. Planifica para actualizaciones HOT.
• Proyecta columnas en las APIs; evita SELECT * en tablas con TOAST extenso. Reduce la E/S en el origen.

D - Monitorización

• Monitoriza en el dashboard age(datfrozenxid) y las principales age(relfrozenxid). Alerta temprana de wraparound.
• Alerta cuando una tabla activa (hot table) no ha tenido autovacuum en 24h a pesar de la rotación (churn). Señal de inanición de workers.
• Incluye métricas de vacuum en las revisiones post-incidente. No solo el ajuste de consultas.
• Documenta las anulaciones de autovacuum por tabla en una hoja de cálculo del catálogo. Para claridad del personal de guardia.
• Prueba el comportamiento de vacuum después de actualizaciones de versión importantes. El planificador (planner) y los cambios de vacuum se publican juntos.

Preguntas Frecuentes

Relacionados

• Conceptos básicos de Vacuum - Mecánica
• Ajuste de Autovacuum - Parámetros
• Transaction ID Wraparound - Alertas de congelamiento
• Hinchazón de Tablas e Índices - Remediación

Versiones de pila: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.