synch/sxlock/innodb/hash_table_locks
El evento synch/sxlock/innodb/hash_table_locks se produce cuando se deben leer desde el almacenamiento páginas que no se encuentran en el grupo de búferes.
Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones:
-
Aurora MySQL, versiones 2 y 3
Contexto
El evento synch/sxlock/innodb/hash_table_locks indica que una carga de trabajo accede con frecuencia a datos que no se almacenan en el grupo de búferes. Este evento de espera está asociado con adiciones de páginas nuevas y expulsiones de datos antiguos del grupo de búferes. Los datos almacenados en el grupo de búferes antiguos y los datos nuevos deben almacenarse en la caché, de modo que las páginas antiguas se expulsan para permitir el almacenamiento en caché de las nuevas páginas. MySQL utiliza un algoritmo de elementos menos usados recientemente (LRU) para expulsar las páginas del grupo de búferes. La carga de trabajo intenta acceder a los datos que no se han cargado en el grupo de búferes o a los datos que se han expulsado del grupo de búferes.
Este evento de espera se produce cuando la carga de trabajo debe acceder a los datos de los archivos del disco o cuando los bloques se liberan o se agregan a la lista LRU del grupo de búferes. Estas operaciones esperan para obtener un bloqueo excluido compartido (SX-lock). Este bloqueo SX se utiliza para la sincronización a través de la tabla de hash, que es una tabla en memoria diseñada para mejorar el rendimiento del acceso al grupo de búferes.
Para obtener más información, consulte Buffer Pool
Causas probables del aumento de las esperas
Cuando el evento de espera synch/sxlock/innodb/hash_table_locks aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
- Un grupo de búferes de tamaño insuficiente
-
El tamaño del grupo de búferes es demasiado pequeño para mantener en memoria todas las páginas a las que se accede con frecuencia.
- Carga de trabajo pesada
-
La carga de trabajo está provocando expulsiones frecuentes y recargas de páginas de datos en la caché del búfer.
- Errores al leer las páginas
-
Hay errores al leer las páginas del grupo de búferes, lo que podría indicar daños en los datos.
Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
Temas
Aumentar el tamaño del grupo de búferes
Asegúrese de que el grupo de búferes tenga el tamaño adecuado para la carga de trabajo. Para ello, puede verificar la tasa de aciertos de caché del grupo de búferes. Normalmente, si el valor cae por debajo del 95 por ciento, debe considerar la posibilidad de aumentar el tamaño del grupo de búferes. Un grupo de búferes más grande puede mantener en memoria las páginas a las que se accede con frecuencia durante más tiempo. Para aumentar el tamaño del grupo de búferes, modifique el valor del parámetro innodb_buffer_pool_size. El valor predeterminado de este parámetro se basa en el tamaño de clase de la instancia de base de datos. Para obtener más información, consulte Best practices for Amazon Aurora MySQL database configuration
Mejorar los patrones de acceso a datos
Verifique las consultas afectadas por esta espera y sus planes de ejecución. Considere la posibilidad de mejorar los patrones de acceso a datos. Por ejemplo, si está utilizando mysqli_result::fetch_array
Puede utilizar Información sobre rendimiento para mostrar consultas y sesiones que podrían estar provocando el evento de espera synch/sxlock/innodb/hash_table_locks.
Para buscar consultas SQL responsables de cargas elevadas
Inicie sesión en la AWS Management Console y abra la consola de Amazon RDS en https://console.aws.amazon.com/rds/
. -
En el panel de navegación, seleccione Información sobre rendimiento.
-
Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
-
En el cuadro Database load (Carga de base de datos), elija Slice by wait (Corte por espera).
-
En la parte inferior de la página, 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 de AWS Database Analyze Amazon Aurora MySQL Workloads with Performance Insights
Reducir o evitar análisis de tablas completas
Monitoree su carga de trabajo para ver si está ejecutando análisis de tablas completas y, de ser así, reducirlos o evitarlos. Por ejemplo, puede monitorear variables de estado como, por ejemplo, Handler_read_rnd_next. Para obtener más información, consulte Server Status Variables
Verificar los registros de errores para detectar daños en la página
Puede verificar el archivo mysql-error.log en busca de mensajes relacionados con daños que se detectaron cerca del momento en que se produjo el problema. Los mensajes con los que puede trabajar para resolver el problema se encuentran en el registro de errores. Es posible que tenga que volver a crear objetos que se han informado como dañados.
