Autovacuum adaptativo en Servidor flexible de Azure Database for PostgreSQL

En este artículo se documentan los parámetros adaptive_autovacuum admitidos por Azure Database for PostgreSQL: servidor flexible:

• adaptive_autovacuum.optimize_configurations: Habilita el ajuste automático de una serie de parámetros de autovacuum.
• adaptive_autovacuum.open_transaction_threshold: establece el umbral de antigüedad en segundos para detectar y mitigar las transacciones preparadas antiguas.

Funcionamiento de cada parámetro

adaptive_autovacuum.optimize_configurations

Cuando se establece este parámetro en on, el servicio de ajuste realiza periódicamente lo siguiente:

1. Recopila y agrega señales de la carga de trabajo y de estadísticas de tablas.
2. Evalúa los flujos de trabajo de reglas.
3. Calcula las posibles actualizaciones de los parámetros de autovacuum.
4. Aplica actualizaciones y recarga la configuración del motor.
5. Escribe entradas de auditoría.

Si no se cumplen las condiciones de ninguna regla, una ejecución puede completarse sin cambios.

Parámetros ajustables actuales:

• autovacuum_vacuum_cost_limit
• autovacuum_vacuum_threshold
• autovacuum_vacuum_scale_factor
• autovacuum_vacuum_cost_delay
• autovacuum_analyze_scale_factor

Visibilidad y comportamiento de sobrescritura de los parámetros ajustados

Cuando esta característica cambia cualquiera de los cinco parámetros de destino (autovacuum_vacuum_cost_limit, autovacuum_vacuum_threshold, autovacuum_vacuum_scale_factor, autovacuum_vacuum_cost_delay, autovacuum_analyze_scale_factor):

• El punto de conexión de configuraciones del plano de control (por ejemplo, la API GET Configurations o el grupo de comandos de la CLI az postgres flexible-server parameter) no muestra estos cambios efectivos en tiempo de ejecución.
• Para ver los valores efectivos, use consultas de plano de datos en el punto de conexión de PostgreSQL (por ejemplo, SHOW <guc_name> o SELECT name, setting FROM pg_settings WHERE name IN (...)).

Semántica de invalidación de usuario:

• Puede establecer cualquiera de estos cinco parámetros directamente a través del portal, la API REST, la CLI o cualquiera de los SDK admitidos.
• Si establece un parámetro con el mismo valor que devuelve actualmente el endpoint Configurations del plano de control, la operación se considera una operación sin efecto y no se aplica ningún cambio efectivo.
• Los valores establecidos por el usuario invalidan los valores aplicados a la característica en el momento en que se aplican.
• Si adaptive_autovacuum.optimize_configurations permanece habilitado, las iteraciones de ajuste posteriores pueden volver a aplicar nuevos valores en función de la evaluación de reglas.

adaptive_autovacuum.open_transaction_threshold

Este parámetro controla la mitigación de transacciones preparadas huérfanas:

• 0 significa deshabilitado.
• Un valor superior a 0 significa que está habilitado, con un umbral en segundos.

Cuando está habilitada, si la transacción preparada más antigua supera el umbral, el controlador de transacciones huérfanas evalúa la idoneidad y puede revertir las transacciones preparadas antiguas. El controlador actualiza su umbral en memoria en los cambios de parámetro, por lo que el comportamiento sigue el valor más reciente.

Detalle importante sobre la temporización:

• La característica determina primero la marca de tiempo de transacción preparada más antigua.
• Esa detección está basada en sondeos, no continua.
• El sondeo se ejecuta cada 1800 segundos (es decir, cada 30 minutos), por lo que la mitigación solo se puede iniciar después de que un sondeo observe una transacción preparada con suficiente antigüedad.

Comportamiento de tiempo de ejecución y programación

• La optimize_configurations frecuencia de ajuste es de 30 minutos.
• Al activar optimize_configurations, desencadena una ejecución de optimización inmediata y, a continuación, las ejecuciones programadas continúan.
• La administración de open_transaction_threshold se basa en eventos a partir de observaciones de transacciones preparadas. La mitigación solo se ejecuta cuando las comprobaciones de edad superan el umbral.
• La observación de transacciones preparadas para open_transaction_threshold se actualiza cada 300 segundos.

¿Cuándo se crea el intelligentperformance esquema después de habilitarlo?

El intelligentperformance esquema se crea en la azure_sys base de datos. Su creación no es inmediata y se controla mediante la funcionalidad que conserva las estadísticas usadas por el vaciado automático adaptable, en lugar de mediante la propia ejecución de ajuste inicial. Normalmente, el esquema se crea en un plazo de 0 a 30 minutos después de habilitar la característica.

Puede habilitar el autovacuum adaptativo estableciendo adaptive_autovacuum.optimize_configurations en on o configurando adaptive_autovacuum.open_transaction_threshold con un valor distinto de cero (es decir, > 0). El esquema se crea una vez que la característica se activa y comienza a recopilar las estadísticas necesarias.

La creación puede retrasarse o omitirse si no se cumplen determinados requisitos previos.

Limitaciones y requisitos previos

Ambos controles están sujetos a los siguientes requisitos:

• La instancia debe ser la principal.
• PostgreSQL no está en modo de recuperación.
• La capacidad de cómputo del servidor tiene un mínimo de 4 vCores.
• El servidor es un servidor flexible normal, no un clúster elástico. La característica no se admite en clústeres elásticos.
• adaptive_autovacuum.optimize_configurations es compatible con versiones mayores iguales o superiores a 14.
• adaptive_autovacuum.open_transaction_threshold es compatible con las versiones principales iguales o superiores a la 13.

Auditoría y observabilidad

El sistema registra las acciones de ambos controles en una vista de auditoría denominada intelligentperformance.adaptive_tuning_events.

Esquema de la vista

Forma lógica esperada:

• intelligentperformance.adaptive_tuning_events
  • event_details
  • optimizer_type
  • fecha de solicitud

Consulta de actividad reciente

Para consultar la actividad reciente, use las siguientes consultas:

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
ORDER BY applied_at DESC
LIMIT 100;

SELECT
    optimizer_type,
    COUNT(*) AS events
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
GROUP BY optimizer_type
ORDER BY events DESC;

Tipos de eventos e interpretación

La optimizer_type columna indica el origen de la acción.

adaptive_autovacuum_configuration_changed

Origen:

• Ruta de ajuste optimize_configurations.

Forma de carga:

• Matriz JSON de registros de cambio de parámetros, que normalmente incluyen:
  • server_parameter_name
  • valor_anterior
  • updated_tuned_value

Interpretación:

• Indica que el ajuste de autovacuum ha cambiado la configuración del servidor.
• Positivo cuando las métricas posteriores de la carga de trabajo mejoran (presión de tupla inactiva, cadencia de vacío, latencia, CPU/E/S).
• Potencialmente negativo cuando los cambios son frecuentes y osciladores y van seguidos de regresiones.

SELECT
    applied_at,
    elem->>'server_parameter_name' AS parameter_name,
    elem->>'previous_value' AS previous_value,
    elem->>'updated_tuned_value' AS updated_value
FROM intelligentperformance.adaptive_tuning_events e
CROSS JOIN LATERAL jsonb_array_elements(e.event_details) AS elem
WHERE e.optimizer_type = 'adaptive_autovacuum_configuration_changed'
ORDER BY applied_at DESC;

orphan_transaction_rollback

Origen:

• open_transaction_threshold vía de mitigación.

Forma de carga:

• Objeto JSON con clave por base de datos, con detalles del resultado de la reversión (por ejemplo, información sobre la reversión de GID intentada y realizada correctamente).

{
    "<example-database-name>": {
        "Timestamp": "2026-03-22T18:20:22.0000000Z", 
        "RollbackGids": ["<example-global-identifier-one>", "<example-global-identifier-two>"], 
        "OperationSuccessful": true
    }
}

Interpretación:

• Indica que las transacciones preparadas se revirtieron forzosamente tras superar el umbral.
• Los eventos ocasionales pueden ser un comportamiento de protección correcto.
• Los eventos frecuentes suelen indicar problemas del ciclo de vida de las transacciones de la aplicación que se deben investigar.

SELECT
    applied_at,
    jsonb_pretty(event_details) AS rollback_details
FROM intelligentperformance.adaptive_tuning_events
WHERE optimizer_type = 'orphan_transaction_rollback'
ORDER BY applied_at DESC
LIMIT 50;

Determinar si el impacto es positivo o negativo

Para optimize_configurations:

1. Identifique las marcas de tiempo de cambio de adaptive_autovacuum_configuration_changed.
2. Compare de 30 a 120 minutos las ventanas posteriores al cambio para tuplas inactivas, cadencia de vacío/análisis, latencia, CPU/E/S.

Para open_transaction_threshold:

1. Identificar orphan_transaction_rollback eventos.
2. Valide si la frecuencia de reversión es baja y estabilizada.
3. Investigue el comportamiento de la aplicación si los eventos de reversión son persistentes.

SELECT
    applied_at,
    optimizer_type,
    event_details
FROM intelligentperformance.adaptive_tuning_events
WHERE applied_at >= now() - interval '7 days'
ORDER BY applied_at DESC;

Retención y mantenimiento

El mantenimiento quita los registros más antiguos del almacenamiento de auditoría mediante un período de retención fijo y no configurado de 90 días.

Para el análisis de tendencias a largo plazo, exporte los registros de auditoría a su propio repositorio de observabilidad.

Contenido relacionado

• Ajuste inteligente.