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

Descripción breve

Las estadísticas de rendimiento se activan en cualquiera de los siguientes servicios:

• Amazon Relational Database Service (Amazon RDS) para MySQL.
• Amazon RDS para MariaDB.
• Edición de Amazon Aurora compatible con MySQL.

Si observa eventos de espera SYNCH de MySQL en Información de rendimiento, significa que una gran cantidad de sesiones de la base de datos están intentando acceder a los mismos objetos protegidos o estructuras de memoria. Entre los objetos protegidos en MySQL se incluyen los siguientes:

• El archivo de registro binario activo en una instancia de origen del archivo binario: contiene un mutex que solo permite que una sesión lo lea o escriba en él cada vez.
• El diccionario de datos: para escrituras que normalmente se producen mediante instrucciones en lenguaje de control de datos (DCL) o en lenguaje de definición de datos (DDL).
• El índice hash adaptativo: contiene un mutex que solo permite que una sesión lo lea o escriba en él cada vez.
• La caché de tabla abierta: solo una sesión puede agregar una tabla a la caché o eliminarla.
• Cada bloque de base de datos dentro del conjunto de búferes de InnoDB: 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 gestionar la carga de trabajo

Tener un gran número de sesiones esperando eventos SYNCH comporta un uso elevado de la CPU. Si este uso alcanza el 100 %, el número de sesiones de espera aumenta. Al solucionar problemas, aumente el tamaño de la instancia de base de datos para asegurarse de que hay suficiente CPU para procesar la carga de trabajo adicional.

Como estos eventos suelen ser de corta duración, es posible que la métrica de uso de la CPU de Amazon CloudWatch no muestre correctamente el pico de uso. La mejor forma de comprobarlo es utilizar los contadores de CPU de un segundo en Supervisión mejorada de RDS. Estos contadores son más específicos y detallados.

Aumento de la matriz de espera mutex/lock de MySQL

MySQL usa una estructura de datos interna para coordinar los hilos. De forma predeterminada, el tamaño de esta matriz es uno. Esto es adecuado 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. Establezca el parámetro innodb_sync_array_size de MYSQL en el volumen de CPU (o un valor superior, hasta 1024).

Nota: El parámetro innodb_sync_array_size solo se aplica al arranque de la base de datos.

Reducción de la simultaneidad

En general, el paralelismo ayuda a mejorar el rendimiento. Sin embargo, cuando un gran número de sesiones intentan realizar las mismas actividades o actividades similares, las sesiones necesitan acceder a los mismos objetos protegidos. Cuanto mayor sea el número de sesiones, más CPU utilizará durante la espera.

Distribuya estas 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.

Análisis de eventos de espera específicos

Utilice los siguientes ejemplos para solucionar un evento de espera específico. Para obtener más información sobre los eventos de espera de Aurora MySQL, consulte Ajuste de Aurora MySQL con eventos de espera.

• synch/rwlock/innodb/dict sys RW lock O
  synch/rwlock/innodb/dict_operation_lock: indica que se activa un gran número de DCL simultáneas con DDL al mismo tiempo. Reduzca la dependencia de la aplicación del uso de DDL durante la actividad normal de la aplicación.
• synch/cond/sql/MDL_context::COND_wait_status: indica que hay un gran número de SQL (incluidas las selecciones) que intentan acceder a una tabla que una DCL o DDL está modificando. Evite ejecutar 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: indica que el número de tablas que abren las sesiones supera el tamaño de la caché de definiciones de tablas o de la caché abierta de tablas. Aumente el tamaño de estas cachés.
• synch/mutex/sql/LOG: es posible que su base de datos esté ejecutando una gran cantidad de instrucciones y los métodos de registro actuales no lo admitan. Si utiliza el método de salida TABLE, intente usar FILE en su lugar. Si utiliza el registro general, utilice la auditoría avanzada de Amazon Aurora en su lugar. Si usa 0 o menos de 1 para el parámetro long_query_time, intente aumentar ese valor.
• synch/mutex/innodb/buf_pool_mutex O synch/mutex/innodb/aurora_lock_thread_slot_futex O synch/rwlock/innodb/index_tree_rw_lock: hay un gran número de DML similares que acceden al mismo objeto de base de datos al mismo tiempo. Utilice instrucciones de varias filas y haga particiones para distribuir la carga de trabajo entre los diferentes objetos de la base de datos.
• synch/mutex/innodb/aurora_lock_thread_slot_futex: esto ocurre cuando una sesión bloquea una fila para su actualización y, a continuación, otra sesión intenta actualizar la misma fila. Su acción depende de los demás eventos de espera que vea. 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 O
  synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit O
  synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log: ha activado el registro binario y puede que se presente una de las siguientes situaciones:

                         - Un alto rendimiento de confirmaciones.

                         - Una gran cantidad de transacciones confirmadas.

                         - Réplicas que leen registros binarios.

                         - Una combinación de estos elementos.

Plantéese la posibilidad de actualizar la base de datos a una versión principal compatible con la versión 5.7 o versiones superiores. Además, utilice instrucciones de varias filas o agrupe varias instrucciones en una sola transacción. En Amazon Aurora, utilice bases de datos globales en lugar de la replicación de registros binarios o utilice los parámetros aurora_binlog.

---

Información relacionada

Uso de Información de rendimiento de Amazon RDS

Trabajo con los grupos de parámetros de base de datos

Referencia de Amazon Aurora MySQL