¿Por qué mi instancia de base de datos MySQL muestra un número elevado de sesiones activas que esperan los eventos de espera SYNCH en Información de rendimiento?

Descripción corta

Los eventos de espera SYNCH de MySQL en Información de rendimiento se producen cuando varias sesiones de bases de datos acceden a los mismos objetos o estructuras de memoria protegidos. Los siguientes objetos están protegidos en Amazon Relational Database Service (Amazon RDS) para MySQL, Amazon RDS para MariaDB y Amazon Aurora MySQL Compatible Edition:

• El archivo de registro binario activo en una instancia de origen del archivo binario que contiene un mutex que solo permite que una sesión lo lea o escriba en él cada vez.
• El diccionario de datos que está protegido para las escrituras de instrucciones del lenguaje de control de datos (DCL) o el lenguaje de definición de datos (DDL).
• El índice hash adaptativo que contiene un mutex que solo permite que una sesión lo lea o escriba en él cada vez.
• La caché de tablas abiertas que permite que solo una sesión añada o elimine una tabla de la caché.
• Cada bloque de base de datos dentro del conjunto de búferes de InnoDB en el que solo una sesión puede modificar el contenido de un bloque en la memoria cada vez.

Resolución

Comprobar que la instancia de base de datos tenga suficientes recursos de CPU para administrar la carga de trabajo

Un número elevado de sesiones que esperan eventos SYNCH provoca un uso elevado de la CPU. Con un uso del 100 %, el número de sesiones de espera aumenta. Para solucionar este problema, aumente el tamaño de la instancia de base de datos para que haya suficiente CPU para procesar la carga de trabajo adicional.

Como los eventos SYNCH no suelen durar mucho, es posible que la métrica CPUUtilization de Amazon CloudWatch no muestre correctamente los picos de uso. Esta métrica solo tiene una granularidad de 60 segundos. Para comprobar los picos de uso, utilice contadores de granularidad de un segundo en Supervisión mejorada en la consola de Amazon RDS.

Aumento de la matriz de espera de mutex o bloqueo de MySQL

MySQL usa una estructura de datos interna para coordinar subprocesos con un tamaño de matriz predeterminado de 1. Esta configuración funciona para máquinas con una sola CPU, pero puede causar problemas en máquinas con varias CPU. Si su carga de trabajo tiene un gran número de subprocesos en espera, aumente el tamaño de la matriz. Modifique el parámetro innodb_sync_array_size de MySQL para que sea igual o superior al número de CPU. Para obtener más información, consulte innodb_sync_array_size en el sitio web de MySQL.

Nota: MySQL solo usa el parámetro innodb_sync_array_size en el arranque de la base de datos.

Reducción de la simultaneidad

Por lo general, el paralelismo mejora el rendimiento. Sin embargo, cuando un gran número de sesiones ejecutan las mismas actividades o actividades similares, las sesiones deben tener acceso a los mismos objetos protegidos. Cuanto mayor sea la cantidad de sesiones, más CPU utilizará mientras espera.

Para resolver este problema, distribuya las actividades a lo largo del tiempo o prográmelas en series. También puede agrupar varias operaciones en una sola instrucción, como inserciones de varias filas.

Solución de problemas en función de los eventos de espera

Realice las siguientes acciones de solución de problemas en función del evento de espera que reciba.

synch/rwlock/innodb/dict sys RW lock o synch/rwlock/innodb/dict_operation_lock

Estos eventos se producen cuando se invoca un número elevado de DCL o DDL simultáneos al mismo tiempo. Para solucionar estos problemas, reduzca la dependencia de la aplicación de las DDL durante la actividad normal de la aplicación.

synch/cond/sql/MDL_context::COND_wait_status

Este evento se produce cuando un número elevado de SQL, incluidos los seleccionados, acceden a una tabla que está modificando una DCL o DDL. Para solucionar este problema, no ejecute instrucciones DDL en tablas con mucho tráfico durante la actividad normal de la aplicación.

synch/mutex/sql/LOCK_open o synch/mutex/sql/LOCK_table_cache

Estos eventos se producen cuando el número de tablas que abren las sesiones supera el tamaño de la caché de definiciones de tablas o de la caché de apertura de tablas. Para solucionar este problema, aumente el tamaño de las cachés. Para obtener más información, consulte 10.4.3.1 Cómo MySQL abre y cierra las tablas en el sitio web de MySQL.

synch/mutex/sql/LOG

Este evento se produce cuando la base de datos ejecuta un gran número de instrucciones que los métodos de registro actuales no admiten. Si utiliza el método de salida TABLE, intente usar FILE en su lugar. Si usa el registro general, utilice la auditoría avanzada en Aurora en su lugar. Si establece el parámetro long_query_time en 0 o en un valor inferior a 1, aumente el valor.

synch/mutex/innodb/buf_pool_mutex, synch/mutex/innodb/aurora_lock_thread_slot_futex o synch/rwlock/innodb/index_tree_rw_lock

Estos eventos se producen cuando un gran número de instrucciones de lenguaje de manipulación de datos (DML) similares acceden al mismo objeto de base de datos al mismo tiempo. Para resolver este problema, utilice instrucciones y particiones de varias filas para distribuir la carga de trabajo entre los diferentes objetos de la base de datos.

synch/mutex/innodb/aurora_lock_thread_slot_futex

Este evento se produce cuando una sesión bloquea una fila para actualizarla y, a continuación, otra sesión intenta actualizar la fila. Solucione este problema en función de los demás eventos de espera que reciba. Busque las instrucciones de SQL responsables de este evento de espera y responda a ellas o busque la sesión de bloqueo y responda a ella.

synch/cond/sql/MYSQL_BIN_LOG::COND_done, synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit o synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

Estos eventos se producen cuando se activa el registro binario y hay un gran volumen de rendimiento de confirmaciones, transacciones de confirmación o réplicas que leen los registros binarios. Para solucionar este problema, utilice instrucciones de varias filas o agrupe varias instrucciones en una sola transacción.

Para obtener más información sobre los eventos de espera compatibles con Aurora MySQL, consulte Ajuste de Aurora MySQL con eventos de espera y Eventos de espera de Aurora MySQL.

Se recomienda actualizar la base de datos a una versión principal que sea compatible con la versión 8.0 o posterior. Cuando sea posible, utilice instrucciones de varias filas o agrupe varias instrucciones en una sola transacción. En Aurora, utilice bases de datos globales de Aurora en lugar de la replicación de registros binarios o utilice los parámetros aurora_binlog.

Información relacionada

Supervisión de la carga de bases de datos con Información de rendimiento en Amazon RDS

Grupos de parámetros para Amazon RDS