synch/mutex/innodb/buf_pool_mutex

El evento synch/mutex/innodb/buf_pool_mutex se produce cuando un subproceso ha adquirido un bloqueo en el grupo de búferes de InnoDB para acceder a una página de memoria.

Versiones del motor relevantes

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

• Aurora MySQL versión 2

Contexto

El mutex buf_pool es un único mutex que protege las estructuras de datos de control del grupo de búferes.

Para obtener más información, consulte Monitoring InnoDB Mutex Waits Using Performance Schema en la documentación de MySQL.

Causas probables del aumento de las esperas

Se trata de un evento de espera específico de la carga de trabajo. Las causas más comunes para que synch/mutex/innodb/buf_pool_mutex aparezca entre los eventos de espera principales son las siguientes:

• El tamaño del grupo de búferes no es lo suficientemente grande como para almacenar el conjunto de datos de trabajo.

• La carga de trabajo es más específica para determinadas páginas de una tabla específica de la base de datos, lo que genera contención en el grupo de búferes.

Acciones

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

Identificar las sesiones y consultas que provocan los eventos

Normalmente, las bases de datos con una carga de moderada a significativa tienen eventos de espera. Los eventos de espera pueden ser aceptables si el rendimiento es óptimo. Si el rendimiento no es óptimo, examine dónde pasa más tiempo la base de datos. Preste atención a los eventos de espera que contribuyen a la carga más alta y averigüe si puede optimizar la base de datos y la aplicación para reducirlos.

Para ver el gráfico SQL superior en AWS Management Console

1. Abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/.

2. En el panel de navegación, seleccione Performance Insights.

3. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.

4. En el cuadro Database load (Carga de base de datos), elija Slice by wait (Corte por espera).

5. Debajo del cuadro Database load (Carga de base de datos), elija Top SQL (SQL principal).

   El gráfico enumera las consultas SQL responsables de la carga. Las que están en la parte superior de la lista son las más importantes. Para resolver un cuello de botella, céntrese en estas instrucciones.

Para obtener información general útil sobre la solución de problemas mediante Información sobre rendimiento, consulte la entrada de blog Analyze Amazon Aurora MySQL Workloads with Performance Insights.

Utilizar Información sobre rendimiento

Este evento está relacionado con la carga de trabajo. Puede utilizar Información sobre rendimiento para hacer lo siguiente:

• Identificar cuándo comienzan los eventos de espera y verificar si se produce algún cambio en la carga de trabajo en ese momento a partir de los registros de aplicaciones u orígenes relacionados.

• Identificar las instrucciones SQL responsables de este evento de espera. Examine el plan de ejecución de las consultas para asegurarse de que las consultas estén optimizadas y utilicen los índices adecuados.

  Si las principales consultas responsables del evento de espera están relacionadas con el mismo objeto o tabla de base de datos, considere la posibilidad de crear particiones de ese objeto o tabla.

Crear réplicas de Aurora

Puede crear réplicas de Aurora para servir tráfico de solo lectura. También puede utilizar el escalado automático de Aurora para gestionar las sobretensiones en el tráfico de lectura. Asegúrese de ejecutar tareas de solo lectura programadas y copias de seguridad lógicas en las réplicas de Aurora.

Para obtener más información, consulte Uso de Amazon Aurora Auto Scaling con réplicas de Aurora.

Examinar el tamaño del grupo de búferes

Consulte la métrica innodb_buffer_pool_wait_free para verificar si el tamaño del grupo de búferes es suficiente para la carga de trabajo. Si el valor de esta métrica es alto y aumenta continuamente, indica que el tamaño del grupo de búferes no es suficiente para gestionar la carga de trabajo. Si innodb_buffer_pool_size se ha establecido correctamente, el valor de innodb_buffer_pool_wait_free debe ser pequeño. Para obtener más información, consulte Innodb_buffer_pool_wait_free en la documentación de MySQL.

Aumente el tamaño del grupo de búferes si la instancia de base de datos tiene suficiente memoria para búferes de sesión y tareas del sistema operativo. Si no lo hace, cambie la instancia de base de datos a una clase de instancia de base de datos de mayor tamaño para obtener memoria adicional que se pueda asignar al grupo de búferes.

nota

Aurora MySQL ajusta automáticamente el valor de innodb_buffer_pool_instances en función del innodb_buffer_pool_size configurado.

Monitorear el historial de estado global

Al monitorear la velocidad de cambio de las variables de estado, puede detectar problemas de bloqueo o memoria en la instancia de base de datos. Active el historial de estado global (GoSH) si aún no está activado. Para obtener más información sobre GoSH, consulte Administrar el historial de estado global.

También puede crear métricas de Amazon CloudWatch personalizadas para monitorear las variables de estado. Para obtener más información, consulte Publicación de métricas personalizadas.