LWLock:MultiXact - Amazon Aurora

LWLock:MultiXact

Los eventos de espera LWLock:MultiXactMemberBuffer, LWLock:MultiXactOffsetBuffer, LWLock:MultiXactMemberSLRU y LWLock:MultiXactOffsetSLRU indican que una sesión está esperando recuperar una lista de transacciones que modifican la misma fila de una tabla determinada.

  • LWLock:MultiXactMemberBuffer: un proceso está esperando la E/S en un búfer simple de uso menos reciente (SLRU) para un miembro de multixact.

  • LWLock:MultiXactMemberSLRU: un proceso está esperando para acceder a la caché simple de uso menos reciente (SLRU) de un miembro de multixact.

  • LWLock:MultiXactOffsetBuffer: un proceso está esperando la E/S en un búfer simple de uso menos reciente (SLRU) para un desplazamiento de multixact.

  • LWLock:MultiXactOffsetSLRU: un proceso está esperando para acceder a la caché simple de uso menos reciente (SLRU) de un desplazamiento de multixact.

Versiones del motor admitidas

Esta información de eventos de espera es compatible con todas las versiones de Aurora PostgreSQL.

Context

Un multixact es una estructura de datos que almacena una lista de identificadores de transacciones (XID) que modifican la misma fila de la tabla. Cuando una sola transacción hace referencia a una fila de una tabla, el identificador de la transacción se almacena en la fila de encabezados de la tabla. Cuando varias transacciones hacen referencia a la misma fila de una tabla, la lista de identificadores de transacciones se almacena en la estructura de datos multixact. Los eventos de espera multixact indican que una sesión está recuperando de la estructura de datos la lista de transacciones que hacen referencia a una fila determinada de una tabla.

Causas probables del aumento del tiempo de espera

Estas son tres causas comunes del uso de multixact:

  • Subtransacciones desde puntos de guardado explícitos: al crear explícitamente un punto de guardado en sus transacciones, se generan nuevas transacciones para la misma fila. Por ejemplo, usar SELECT FOR UPDATE, luego SAVEPOINT y luego UPDATE.

    Algunos controladores, asignadores relacionales de objetos (ORM) y capas de abstracción tienen opciones de configuración para ajustar automáticamente todas las operaciones con puntos de guardado. Esto puede generar muchos eventos de espera multixact en algunas cargas de trabajo. La opción autosave del controlador JDBC de PostgreSQL es un ejemplo de esto. Para obtener más información, consulte pgJDBC en la documentación de JDBC de PostgreSQL. Otro ejemplo es el controlador ODBC de PostgreSQL y su opción protocol. Para más información, consulte psqlODBC Configuration Options (Opciones de configuración de psqlODBC) en la documentación del controlador ODBC de PostgreSQL.

  • Subtransacciones desde cláusulas PL/pgSQL EXCEPTION: cada cláusula EXCEPTION que escriba en sus funciones o procedimientos PL/pgSQL crea un SAVEPOINT interno.

  • Claves externas: varias transacciones adquieren un bloqueo compartido sobre el registro principal.

Cuando una fila determinada se incluye en una operación de transacciones múltiples, el procesamiento de la fila requiere recuperar los identificadores de transacción de los listados de multixact. Si las búsquedas no pueden obtener el multixact de la memoria caché, la estructura de datos debe leerse desde la capa de almacenamiento de Aurora. Esta E/S desde el almacenamiento significa que las consultas SQL pueden tardar más tiempo. Las pérdidas de memoria caché pueden empezar a producirse cuando hay un uso intensivo debido a la gran cantidad de transacciones múltiples. Todos estos factores contribuyen a un aumento de este evento de espera.

Acciones

Recomendamos diferentes acciones en función de las causas del evento de espera. Algunas de estas acciones pueden ayudar a reducir inmediatamente los eventos de espera. Sin embargo, es posible que otras requieran cierta investigación y corrección para aumentar la carga de trabajo.

Realización de inmovilización por vacuum en tablas con este evento de espera

Si este evento de espera se intensifica repentinamente y afecta a su entorno de producción, puede usar cualquiera de los siguientes métodos temporales para reducir su recuento.

  • Utilice VACUUM FREEZE en la tabla o partición de tabla afectada para resolver el problema inmediatamente. Para obtener más información, consulte VACUUM.

  • Utilice la cláusula VACUUM (FREEZE, INDEX_CLEANUP FALSE) para realizar un vaciado omitiendo los índices. Para obtener más información, consulte Vaciado de una tabla lo más rápido posible.

Aumente la frecuencia del vaciado automático en las tablas con este evento de espera

Tras escanear todas las tablas de todas las bases de datos, VACUUM eliminará finalmente los valores multixact y avanzará los valores multixact más antiguos. Para obtener más información, consulte Multixacts y Wraparound. Para reducir al mínimo los eventos de espera de LWLock:MultiXact, debe ejecutar VACUUM tantas veces como sea necesario. Para ello, asegúrese de que el VACUUM de su clúster de base de datos PostgreSQL de Aurora esté configurado de forma óptima.

Si al utilizar VACUUM FREEZE en la tabla o partición de tabla afectada se resuelve el problema del evento de espera, le recomendamos que utilice un planificador, por ejemplo, pg_cron, para ejecutar el VACUUM en lugar de ajustar el vaciado automático en el nivel de instancia.

Para que el autovacuum se realice con mayor frecuencia, puede reducir el valor del parámetro de almacenamiento autovacuum_multixact_freeze_max_age en la tabla afectada. Para obtener más información, consulte autovacuum_multixact_freeze_max_age.

Aumento de los parámetros de memoria

Puede configurar los siguientes parámetros en el nivel del clúster para que todas las instancias del clúster se mantengan coherentes. Esto ayuda a reducir los eventos de espera en la carga de trabajo. Le recomendamos que no establezca valores demasiado altos, para evitar que se quede sin memoria.

  • multixact_offsets_cache_size a 128

  • multixact_members_cache_size a 256

Debe reiniciar la instancia de base de datos para que el cambio de parámetro tenga efecto. Con estos parámetros, puede utilizar más RAM de la instancia para almacenar la estructura multixact en la memoria antes de transferirla al disco.

Reducción de transacciones de larga duración

Las transacciones de larga duración provocan que vacuum retenga la información hasta que se confirme la transacción o hasta que se cierre la transacción de solo lectura. Le recomendamos que supervise y administre de forma proactiva las transacciones de larga duración. Para obtener más información, consulte La base de datos lleva mucho tiempo inactiva en la conexión de la transacción. Intente modificar la aplicación para evitar o minimizar el uso de transacciones de larga duración.

Acciones a largo plazo

Examine su carga de trabajo para descubrir la causa de la propagación de multixact. Debe solucionar el problema para escalar su carga de trabajo y reducir el evento de espera.

  • Debe analizar el DDL (lenguaje de definición de datos) utilizado para crear las tablas. Asegúrese de que las estructuras y los índices de las tablas estén bien diseñados.

  • Cuando las tablas afectadas tengan claves externas, determine si son necesarias o si hay otra forma de reforzar la integridad referencial.

  • Cuando una tabla tiene índices no utilizados de gran tamaño, es posible que el autovacuum no se adapte a la carga de trabajo y que impida su ejecución. Para evitarlo, compruebe si hay índices no utilizados y elimínelos por completo. Para obtener más información, consulte Administración de autovacuum con índices de gran tamaño.

  • Reduzca el uso de puntos de guardado en sus transacciones.