Resolución de problemas de rendimiento de vaciado en RDS para PostgreSQL

En esta sección se analizan los factores que suelen contribuir a reducir el rendimiento del vaciado y cómo abordar estos problemas.

Vaciado de índices grandes

El proceso VACUUM consta de varias etapas: inicialización, análisis de montón, vaciado de índices y el montón, limpieza de los índices, truncado del montón y realización de la limpieza final. Durante el análisis, las páginas se recortan, desfragmentan y congelan. Una vez analizada la totalidad del montón, se limpian los índices, se devuelven las páginas vacías al sistema operativo y se completan las tareas finales de limpieza, como el vaciado del mapa del espacio libre y la actualización de las estadísticas.

Al vaciar índices, es posible que sea necesario realizar varias pasadas si la maintenance_work_mem disponible (o autovacuum_work_mem) no es suficiente para procesar el índice. En las versiones 16 y anteriores de PostgreSQL, un límite de 1 GB en la asignación de memoria para almacenar los ID de tuplas inactivas a menudo requería varias pasadas, especialmente para índices grandes. La versión 17 de PostgreSQL resuelve esta limitación al introducir TidStore, un sistema de asignación dinámica de memoria que sustituye a la matriz de asignación única. Esto elimina la restricción de 1 GB, mejora la eficiencia de la memoria y reduce la probabilidad de que se realicen varios análisis por cada índice.

Sin embargo, incluso en PostgreSQL 17, es posible que se necesiten varias pasadas para índices grandes si la memoria disponible no es suficiente para procesar todo el índice de una sola vez. Por lo general, los índices grandes suelen contener más tuplas inactivas que requieren varias pasadas.

La función postgres_get_av_diag() detecta una operación de vaciado lenta calculando la memoria necesaria para vaciar los índices. Si la memoria disponible no es suficiente para completar el vaciado de índices en una sola pasada, emite la siguiente recomendación:

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_work_mem is "XXX MB" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory. Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).

nota

La función postgres_get_av_diag() se basa en pg_stat_all_tables.n_dead_tup para estimar la cantidad de memoria necesaria para el vaciado de índices.

Indicaciones

Puede aplicar las siguientes soluciones alternativas utilizando manualmente VACUUM FREEZE para acelerar la congelación de la tabla.

Aumentar la memoria de vaciado

Como sugiere la función postgres_get_av_diag(), se recomienda aumentar el parámetro autovacuum_work_mem para abordar las posibles restricciones de memoria en cada instancia. Aunque autovacuum_work_mem es un parámetro dinámico, es importante tener en cuenta que, para que la nueva configuración de memoria surta efecto, el daemon de autovacuum debe reiniciar sus procesos de trabajo. Para lograrlo:

1. Confirme que la nueva configuración esté establecida.

2. Finalice los procesos que actualmente estén ejecutando el autovacuum.

Este enfoque garantiza que la asignación de memoria ajustada se aplique a las nuevas operaciones de autovacuum.

Para obtener resultados más inmediatos, considere la posibilidad de realizar manualmente una operación VACUUM FREEZE con una configuración de maintenance_work_mem mayor durante la sesión:

SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;

Si utiliza Amazon RDS y descubre que necesita memoria adicional para poder utilizar valores más altos para maintenance_work_mem o autovacuum_work_mem, plantéese la posibilidad de actualizar a una clase de instancia con más memoria. Esto puede proporcionarle los recursos necesarios para mejorar las operaciones de vaciado manuales y automáticas, lo que se traduce en una mejora del rendimiento general de vaciado y del de las bases de datos.

Desactivar INDEX_CLEANUP

El VACUUM manual de la versión 12 y posteriores de PostgreSQL permite omitir la fase de limpieza de índices, mientras que el autovacuum de emergencia en la versión 14 y posteriores de PostgreSQL lo hace automáticamente en función del parámetro vacuum_failsafe_age.

aviso

Omitir la limpieza de índices puede provocar una sobrecarga de índices y perjudicar el rendimiento de las consultas. Para mitigar esta situación, considere la posibilidad de volver a indexar o vaciar los índices afectados durante un período de mantenimiento.

Para obtener más información sobre cómo gestionar índices grandes, consulte la documentación en Administración de autovacuum con índices de gran tamaño .

Vaciado de índices en paralelo

A partir de PostgreSQL 13, los índices se pueden vaciar y limpiar en paralelo de forma predeterminada utilizando VACUUM de forma manual, con un proceso de trabajo de vaciado asignado a cada índice. Sin embargo, para que PostgreSQL determine si una operación de vaciado es apta para su ejecución en paralelo, se deben cumplir criterios específicos:

• Debe haber al menos dos índices.

• El parámetro max_parallel_maintenance_workers debe estar establecido al menos en 2.

• El tamaño del índice debe superar el límite min_parallel_index_scan_size, que de forma predeterminada es de 512 KB.

Puede ajustar la configuración max_parallel_maintenance_workers en función de la cantidad de vCPU disponibles en su instancia de Amazon RDS y la cantidad de índices de la tabla para optimizar el tiempo de respuesta del vaciado.

Para obtener más información, consulte Parallel vacuuming in Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL.

Demasiadas tablas o bases de datos que vaciar

Como se menciona en la documentación de PostgreSQL sobre el daemon autovacuum, este funciona mediante múltiples procesos. Esto incluye un lanzador de autovacuum persistente responsable de iniciar los procesos de trabajo de autovacuum para cada base de datos del sistema. El lanzador programa estos procesos de trabajo para que se inicien aproximadamente cada autovacuum_naptime segundos por cada base de datos.

Con “N” bases de datos, un nuevo proceso de trabajo comienza aproximadamente cada [autovacuum_naptime/N segundos]. Sin embargo, el número total de procesos de trabajo simultáneos está limitado por la configuración autovacuum_max_workers. Si el número de bases de datos o tablas que requieren vaciado supera este límite, la siguiente base de datos o tabla se procesará en cuanto haya un proceso de trabajo disponible.

Cuando muchas tablas o bases de datos grandes requieren un vaciado al mismo tiempo, todos los procesos de trabajo de autovacuum disponibles pueden permanecer ocupados durante un período prolongado, lo que retrasa el mantenimiento de otras tablas y bases de datos. En entornos con altas tasas de transacciones, este cuello de botella puede agravarse rápidamente y provocar posibles problemas de vaciado en su instancia de Amazon RDS.

Cuando postgres_get_av_diag() detecta un número elevado de tablas o bases de datos, proporciona la siguiente recomendación:

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.

NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.

Indicaciones

Aumentar autovacuum_max_workers

Para agilizar el vaciado, recomendamos ajustar el parámetro autovacuum_max_workers para permitir que haya más procesos de trabajo de autovacuum simultáneos. Si persisten los cuellos de botella en el rendimiento, plantéese la posibilidad de escalar verticalmente su instancia de Amazon RDS a una clase con más vCPU, lo que puede mejorar aún más las capacidades de procesamiento en paralelo.

Se está ejecutando un vaciado intensivo (para evitar el reinicio)

La antigüedad de la base de datos (MaximumUsedTransactionIDs) en PostgreSQL solo disminuye cuando se completa correctamente un vaciado intensivo (para evitar el reinicio). Hasta que finalice este vaciado, la antigüedad seguirá aumentando en función de la velocidad de transacciones.

La función postgres_get_av_diag() genera el NOTICE siguiente cuando detecta un vaciado intensivo. Sin embargo, solo activa este resultado después de que el vaciado haya estado activo durante al menos dos minutos.

NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.

Para obtener más información sobre el vaciado intensivo, consulte When an aggressive vacuum is already running.

Puede comprobar si se está realizando un vaciado intensivo con la siguiente consulta:

SELECT
    a.xact_start AS start_time,
    v.datname "database",
    a.query,
    a.wait_event,
    v.pid,
    v.phase,
    v.relid::regclass,
    pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
    (
        SELECT
            string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS index_sizes,
    trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
    v.index_vacuum_count || '/' || (
        SELECT
            count(*)
        FROM
            pg_index i
        WHERE
            i.indrelid = v.relid
    ) AS step2_vacuum_indexes,
    trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
    age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
    pg_stat_activity a
    INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;

Para determinar si se trata de un vaciado intensivo (para evitar el reinicio), compruebe la columna de consulta del resultado. La expresión “para evitar el reinicio” indica que se trata de un vaciado intensivo.

query                  | autovacuum: VACUUM public.t3 (to prevent wraparound)

Por ejemplo, supongamos que hay un bloqueador en el valor de antigüedad de transacciones de 1000 millones y una tabla que requiere un vaciado intensivo para evitar el reinicio a esa misma antigüedad de transacciones. Además, hay otro bloqueador en el valor de antigüedad de transacciones de 750 millones. Tras superar el bloqueador en el valor de antigüedad de transacciones de 1000 millones, la antigüedad no se reducirá inmediatamente a 750 millones. Seguirá siendo alta hasta que se complete la tabla que necesita el vaciado intensivo o cualquier transacción con una antigüedad superior a los 750 millones. Durante este período, la antigüedad de las transacciones de su clúster de PostgreSQL seguirá aumentando. Una vez que se complete el proceso de vaciado, la antigüedad de las transacciones se reducirá a 750 millones, pero volverá a aumentar de nuevo hasta que se finalice todo el vaciado. Este ciclo continuará mientras se mantengan estas condiciones, hasta que la antigüedad de las transacciones finalmente se reduzca hasta el nivel configurado para su instancia de Amazon RDS, especificado por autovacuum_freeze_max_age.