# 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.
**Topics**
+ [Versiones del motor admitidas](#apg-waits.xactsync.context.supported)
+ [Contexto](#apg-waits.lwlockmultixact.context)
+ [Causas probables del aumento del tiempo de espera](#apg-waits.lwlockmultixact.causes)
+ [Acciones](#apg-waits.lwlockmultixact.actions)
## Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de Aurora PostgreSQL.
## Contexto
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](https://jdbc.postgresql.org/) 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](https://odbc.postgresql.org/docs/config.html) (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.
**Topics**
+ [Realización de inmovilización por vacuum en tablas con este evento de espera](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [Aumente la frecuencia del vaciado automático en las tablas con este evento de espera](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [Aumento de los parámetros de memoria](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [Reducción de transacciones de larga duración](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [Acciones a largo plazo](#apg-waits.lwlockmultixact.actions.longactions)
### 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](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Utilice la cláusula VACUUM (FREEZE, INDEX\$1CLEANUP 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### 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](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-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\$1multixact\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Aumento de los parámetros de memoria
Puede optimizar el uso de la memoria para las cachés multixact ajustando los siguientes parámetros. Esta configuración controla la cantidad de memoria que se reserva para estas cachés, lo que puede ayudar a reducir los eventos de espera multixact en la carga de trabajo. Recomendamos empezar con los siguientes valores:
Para Aurora PostgreSQL 17 y posteriores:
+ `multixact_offset_buffers` = 128
+ `multixact_member_buffers` = 256
Para Aurora PostgreSQL 16 y anteriores:
+ `multixact_offsets_cache_size` = 128
+ `multixact_members_cache_size` = 256
**nota**
En Aurora PostgreSQL 17, los nombres de los parámetros se cambiaron de `multixact_offsets_cache_size` a `multixact_offset_buffers` y de `multixact_members_cache_size` a `multixact_member_buffers` para alinearse con PostgreSQL 17 de la comunidad.
Puede establecer estos parámetros en el nivel del clúster para que todas las instancias del clúster se mantengan coherentes. Le recomendamos que pruebe y ajuste los valores para que se adapten mejor a los requisitos de carga de trabajo específicos y a la clase de instancia. Debe reiniciar la instancia de escritor para que los cambios de parámetro tengan efecto.
Los parámetros se expresan en términos de entradas de caché multixact. Cada entrada de caché utiliza `8 KB` de memoria. Para calcular la memoria total reservada, multiplique el valor de cada parámetro por `8 KB`. Por ejemplo, si establece un parámetro en 128, la memoria reservada total sería `128 * 8 KB = 1 MB`.
### 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](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Reduzca el uso de puntos de guardado en sus transacciones.