synch/mutex/innodb/temp_pool_manager_mutex - Amazon Aurora
Versiones del motor admitidasContextoCausas probables del aumento de las esperasAcciones

synch/mutex/innodb/temp_pool_manager_mutex

El evento de espera synch/mutex/innodb/temp_pool_manager_mutex se produce cuando una sesión está esperando para adquirir un mutex para administrar el grupo de espacios de tablas temporales de sesión.

Versiones del motor admitidas

Esta información de evento de espera es compatible con las siguientes versiones del motor:

  • Aurora MySQL versión 3

Contexto

La versión 3.x y posterior de Aurora MySQL utiliza temp_pool_manager_mutex para controlar varias sesiones que acceden al grupo de espacios de tablas temporales al mismo tiempo. Aurora MySQL administra el almacenamiento a través de un volumen de clúster de Aurora para los datos persistentes y el almacenamiento local para los archivos temporales. Se necesita un espacio de tabla temporal cuando una sesión crea una tabla temporal en el volumen del clúster DE Aurora.

Cuando una sesión solicita por primera vez un espacio de tabla temporal, MySQL asigna los espacios de tablas temporales de sesión del grupo compartido. Una sesión puede contener hasta 2 espacios de tablas temporales a la vez para los siguientes tipos de tablas:

  • Tablas temporales creadas por el usuario

  • Tablas temporales internas generadas por el optimizador

El motor de TempTable predeterminado utiliza el siguiente mecanismo de desbordamiento para gestionar las tablas temporales:

  • Almacena las tablas en RAM hasta el límite temptable_max_ram.

  • Se traslada a los archivos asignados a memoria del almacenamiento local cuando la RAM está llena.

  • Usa el volumen del clúster compartido cuando los archivos asignados a memoria alcanzan su límite temptable_max_mmap.

Cuando las tablas temporales superan los límites de RAM y almacenamiento local, MySQL las administra mediante el espacio de tablas del disco.

Cuando una sesión requiere una tabla temporal en disco, MySQL:

  • Busca los espacios de tablas INACTIVE disponibles en el grupo para reutilizarlos.

  • Crea 10 espacios de tabla nuevos si no hay espacios INACTIVE.

Cuando una sesión se desconecta, MySQL:

  • Trunca los espacios de tablas temporales de la sesión.

  • Los marca como INACTIVOS en el grupo para su reutilización.

  • Mantiene el tamaño actual del grupo hasta que se reinicie el servidor.

  • Vuelve al tamaño de grupo predeterminado (10 espacios de tabla) tras el reinicio.

Causas probables del aumento de las esperas

Situaciones comunes que provocan este evento de espera:

  • Sesiones simultáneas que crean tablas temporales internas en el volumen del clúster.

  • Sesiones simultáneas que crean tablas temporales de usuario en el volumen del clúster.

  • Terminación repentina de las sesiones mediante espacios de tabla activos.

  • Expansión del grupo de espacios de tabla durante cargas de trabajo de escritura intensivas.

  • Consultas simultáneas mediante el acceso a INFORMATION_SCHEMA.

Acciones

Recomendamos diferentes acciones en función de las causas del evento de espera.

Supervisión y optimización del uso de las tablas temporales

Para supervisar y optimizar el uso temporal de las tablas, utilice uno de estos métodos:

  • Consulte el contador de Created_tmp_disk_tables en la información de rendimiento para realizar un seguimiento de la creación de tablas temporales en disco en todo el clúster de Aurora.

  • Ejecute este comando en la base de datos para supervisar directamente la creación de tablas temporales: mysql> show status like '%created_tmp_disk%'.

nota

El comportamiento de las tablas temporales difiere entre los nodos de lectura y escritura de Aurora MySQL. Para obtener más información, consulte Nuevo comportamiento de tabla temporal en Aurora MySQL versión 3.

Tras identificar las consultas mediante la creación de tablas temporales, siga estos pasos de optimización:

  • Use EXPLAIN para examinar los planes de ejecución de consultas e identificar dónde y por qué se crean las tablas temporales.

  • Modifique las consultas para reducir el uso temporal de las tablas siempre que sea posible.

Si la optimización de consultas por sí sola no resuelve los problemas de rendimiento, considere la posibilidad de ajustar estos parámetros de configuración:

  • temptable_max_ram: controla el uso máximo de RAM para las tablas temporales.

  • temptable_max_mmap: establece el límite de almacenamiento de archivos asignados en memoria.

  • tmp_table_size: se aplica cuando aurora_tmptable_enable_per_table_limit está habilitado (desactivado de forma predeterminada).

importante

Tenga en cuenta que determinadas condiciones de consulta siempre requerirán tablas temporales en disco, independientemente de los ajustes de configuración. Para obtener más información sobre el motor de almacenamiento de TempTable, consulte Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL.

Revisión de las consultas mediante INFORMATION_SCHEMA

Al consultar tablas de INFORMATION_SCHEMA, MySQL crea tablas temporales de InnoDB en el volumen del clúster. Cada sesión necesita un espacio de tablas temporal para estas tablas, lo que puede provocar problemas de rendimiento si el acceso simultáneo es elevado.

Para mejorar el desempeño:

  • Use PERFORMANCE_SCHEMA en lugar de INFORMATION_SCHEMA cuando sea posible.

  • Si debe utilizar INFORMATION_SCHEMA, reduzca la frecuencia con la que ejecuta estas consultas.

Aumento del parámetro innodb_sync_array_size

El parámetro innodb_sync_array_size controla el tamaño de la matriz de espera mutex/lock en MySQL. El valor predeterminado de 1 funciona para cargas de trabajo generales, pero aumentarlo puede reducir la contención de subprocesos en situaciones de alta concurrencia.

Cuando la carga de trabajo muestra un número creciente de subprocesos en espera:

  • Supervise la cantidad de subprocesos de espera de la carga de trabajo.

  • Establezca un innodb_sync_array_size igual o superior al de la vCPU de la instancia para dividir la estructura de coordinación de subprocesos y reducir la contención.

nota

Para determinar la cantidad de vCPU disponibles en la instancia de RDS, consulte las especificaciones de las vCPU en los tipos de instancias de Amazon RDS.

Implementar la agrupación de conexiones

MySQL asigna un espacio de tabla dedicado a cada sesión que crea una tabla temporal. Este espacio de tabla permanece activo hasta que finalice la conexión a la base de datos. Para administrar los recursos de manera más eficiente:

  • Implemente la agrupación de conexiones para limitar el número de espacios de tabla temporales activos.

  • Reutilice las conexiones existentes en lugar de crear nuevas para cada operación.