# Ajuste de Aurora MySQL con eventos de espera
La siguiente tabla resume los eventos de espera de Aurora MySQL que suelen indicar problemas de rendimiento. Los siguientes eventos de espera son un subconjunto de la lista de [Eventos de espera de Aurora MySQL](AuroraMySQL.Reference.Waitevents.md).
| Evento de espera | Descripción |
| --- | --- |
| [cpu](ams-waits.cpu.md) | Este evento ocurre cuando un subproceso está activo en la CPU o espera por la CPU. |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | Este evento se produce cuando una sesión escribe datos persistentes en el almacenamiento de Aurora. |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | Este evento se produce cuando un subproceso está a la espera de devolver un conjunto de resultados a un cliente. |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | Este evento se produce cuando una sesión escribe datos persistentes en el almacenamiento de Aurora. |
| [io/socket/sql/client\$1connection](ams-waits.client-connection.md) | Este evento se produce cuando un subproceso está controlando una nueva conexión. |
| [io/table/sql/handler](ams-waits.waitio.md) | Este evento se produce cuando el trabajo se ha delegado en un motor de almacenamiento. |
| [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md) | Este evento se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | Este evento se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. |
| [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md) | Este evento se produce cuando hay subprocesos a la espera en un bloqueo de metadatos de tabla. |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | Este evento se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | Este evento 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. |
| [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md) | Este evento se produce cuando una sesión está a la espera para acceder a la memoria caché de memoria del espacio de tabla. |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | Este evento se produce cuando hay una elevada actividad de la base de datos con un gran número de transacciones. |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | Este evento se produce cuando se deben leer desde un archivo páginas que no se encuentran en el grupo de búferes. |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | Este evento se produce cuando una sesión está esperando para adquirir un mutex para administrar el grupo de espacios de tablas temporales de sesión. |
# cpu
El evento de espera de `cpu` ocurre cuando un subproceso se encuentra activo en la CPU o en espera de la misma.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.cpu.context.supported)
+ [Contexto](#ams-waits.cpu.context)
+ [Causas probables del aumento de las esperas](#ams-waits.cpu.causes)
+ [Acciones](#ams-waits.cpu.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL, versiones 2 y 3
## Contexto
Una conexión puede ejecutar trabajos en esta CPU para cada vCPU. En determinadas situaciones, el número de conexiones activas que están listas para ejecutarse es mayor que el número de vCPU. Este desequilibrio provoca conexiones a la espera de recursos de CPU. Si el número de conexiones activas permanece es constantemente superior al número de vCPUs, la instancia experimenta contención de CPU. La contención hace que se produzca el evento de espera `cpu`.
**nota**
La métrica de Información sobre rendimiento para la CPU es `DBLoadCPU`. El valor de `DBLoadCPU` puede diferir del valor de la métrica `CPUUtilization` de CloudWatch. Esta última métrica se recopila del hipervisor para una instancia de base de datos.
Las métricas del sistema operativo de Información sobre rendimiento proporcionan información detallada sobre la utilización de la CPU. Por ejemplo, puede mostrar las siguientes métricas:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
Información sobre rendimiento informa del uso de la CPU por parte del motor de base de datos como `os.cpuUtilization.nice.avg`.
## Causas probables del aumento de las esperas
Cuando este evento se produce más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas suelen ser las siguientes:
+ Consultas analíticas
+ Transacciones altamente concurrentes
+ Transacciones de larga duración
+ Aumento repentino del número de conexiones, conocido como *tormenta de inicios de sesión*
+ Aumento del cambio de contexto
## Acciones
Si el evento de espera de `cpu` domina la actividad de la base de datos, no indica necesariamente un problema de rendimiento. Responda a este evento solo cuando el rendimiento se deteriore.
Dependiendo de la causa del aumento de utilización de la CPU, considere la posibilidad de adoptar las estrategias siguientes:
+ Aumente la capacidad de CPU del host. Por lo general, este enfoque solo proporciona un alivio provisional.
+ Identifique las principales consultas de posible optimización.
+ Redirija algunas de las cargas de trabajo de solo lectura a nodos lectores, si procede.
**Topics**
+ [Identificar las sesiones o consultas que están causando el problema](#ams-waits.cpu.actions.az-vpc-subnet)
+ [Analizar y optimizar la elevada carga de trabajo de la CPU](#ams-waits.cpu.actions.db-instance-class)
### Identificar las sesiones o consultas que están causando el problema
Para encontrar sesiones y consultas, consulte la tabla **SQL principal** en Información sobre rendimiento para obtener información sobre las instrucciones SQL que tienen la mayor carga de CPU. Para obtener más información, consulte [Análisis de métricas mediante el panel de Información sobre rendimiento](USER_PerfInsights.UsingDashboard.md).
Normalmente, una o dos instrucciones SQL consumen la mayoría de los ciclos de CPU. Concentre sus esfuerzos en estas instrucciones. Supongamos que su instancia de base de datos tiene 2 vCPU con una carga media de base de datos de 3,1 sesiones activas (AAS) en el estado de la CPU. En este caso, la instancia está vinculada a la CPU. Consideremos la posibilidad de aplicar las estrategias siguientes:
+ Actualizar a una clase de instancia mayor con más vCPU.
+ Ajustar las consultas para reducir la carga de la CPU.
En este ejemplo, las principales consultas SQL tienen una carga de base de datos de 1,5 AAS, toda en el estado de la CPU. Otra instrucción SQL tiene una carga de 0,1 en el estado de la CPU. En este ejemplo, si detuvo la instrucción SQL de menor carga, no se reduce significativamente la carga de la base de datos. Sin embargo, si optimiza las dos consultas de alta carga para que sean el doble de eficientes, eliminará el cuello de botella de la CPU. Si reduce la carga de CPU de 1,5 AAS en un 50 por ciento, el AAS de cada instrucción se reduce a 0,75. La carga total de la base de datos en la CPU es ahora de 1,6 AAS. Este valor está por debajo del máximo de 2.0 de la vCPU.
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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/). Consulte también el artículo de AWS Support [How can I troubleshoot and resolve high CPU utilization on my Amazon RDS for MySQL instances?](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/) (¿Cómo solucionar y resolver el problema del uso elevado de la CPU en mis instancias de Amazon RDS for MySQL?).
### Analizar y optimizar la elevada carga de trabajo de la CPU
Después de identificar la consulta o las consultas que aumentan el uso de la CPU, puede optimizarlas o finalizar la conexión. En el siguiente ejemplo se muestra cómo finalizar una conexión.
```
CALL mysql.rds_kill(processID);
```
Para obtener más información, consulte [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
Si finaliza una sesión, la acción podría desencadenar una larga restauración.
#### Seguir las directrices para optimizar las consultas
Para optimizar las consultas, tenga en cuenta las directrices siguientes:
+ Ejecute la instrucción `EXPLAIN`.
Este comando muestra los pasos individuales necesarios para la ejecución de una consulta. Para obtener más información, consulte [Optimizing Queries with EXPLAIN](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html) en la documentación de MySQL.
+ Ejecute la instrucción `SHOW PROFILE`.
Utilice esta instrucción para revisar los detalles del perfil que pueden proporcionar información sobre el uso de recursos para las instrucciones que se ejecutan durante la sesión actual. Para obtener más información, consulte [SHOW PROFILE Statement](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html) en la documentación de MySQL.
+ Ejecute la instrucción `ANALYZE TABLE`.
Utilice esta instrucción para actualizar las estadísticas de índice de las tablas a las que accede la consulta de alto consumo de recursos de CPU. Al analizar la instrucción, podrá ayudar al optimizador a elegir un plan de ejecución adecuado. Para obtener más información, consulte [ANALYZE TABLE Statement](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html) en la documentación de MySQL.
#### Siga las directrices para mejorar el uso de la CPU
Para mejorar el uso de la CPU en una instancia de base de datos, siga las directrices siguientes:
+ Asegúrese de que todas las consultas utilicen índices adecuados.
+ Averigüe si puede utilizar consultas paralelas de Aurora. Puede utilizar esta técnica para reducir el uso de la CPU en el nodo director con la reducción del procesamiento de la función, el filtrado de filas y la proyección de columnas para la cláusula `WHERE`.
+ Averigüe si el número de ejecuciones SQL por segundo cumple los umbrales esperados.
+ Averigüe si el mantenimiento del índice o la creación de nuevos índices ocupan los ciclos de CPU que necesita su carga de trabajo de producción. Programe actividades de mantenimiento fuera de los horarios de actividad pico.
+ Averigüe si puede utilizar particiones para ayudar a reducir el conjunto de datos de consulta. Para obtener más información, consulte la entrada de blog [How to plan and optimize Amazon Aurora with MySQL compatibility for consolidated workloads](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/).
#### Verificar si hay tormentas de conexión
Si la métrica `DBLoadCPU` no es muy alta, pero la métrica `CPUUtilization` es alta, la causa del exceso de uso de recursos de la CPU se encuentra fuera del motor de base de datos. Un ejemplo clásico de ello son las tormentas de conexión.
Verifique si se cumplen las condiciones siguientes:
+ Hay un aumento en la métrica `CPUUtilization` de Información sobre rendimiento y la métrica `DatabaseConnections` de Amazon CloudWatch.
+ El número de subprocesos de la CPU es mayor que el número de vCPU.
Si se cumplen las condiciones anteriores, considere la posibilidad de reducir el número de conexiones de la base de datos. Por ejemplo, puede utilizar un grupo de conexiones como proxy RDS. Para obtener información sobre prácticas recomendadas para la administración y el escalado eficaz de conexiones, consulte el documento técnico [Amazon Aurora MySQL DBA Handbook for Connection Management](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
# io/aurora\$1redo\$1log\$1flush
El evento `io/aurora_redo_log_flush` se produce cuando una sesión escribe datos persistentes en el almacenamiento de Amazon Aurora.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.io-auredologflush.context.supported)
+ [Contexto](#ams-waits.io-auredologflush.context)
+ [Causas probables del aumento de las esperas](#ams-waits.io-auredologflush.causes)
+ [Acciones](#ams-waits.io-auredologflush.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 2
## Contexto
El evento `io/aurora_redo_log_flush` es para una operación de entrada/salida de escritura (E/S) en Aurora MySQL.
**nota**
En la versión 3 de Aurora MySQL, este evento de espera se denomina [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
## Causas probables del aumento de las esperas
Para la persistencia de datos, las confirmaciones requieren una escritura duradera en un almacenamiento estable. Si la base de datos está realizando demasiadas confirmaciones, se produce un evento de espera en la operación de E/S de escritura, el evento de espera `io/aurora_redo_log_flush`.
En los ejemplos siguientes, se insertan 50 000 registros en un clúster de base de datos de Aurora MySQL mediante la clase de instancia de base de datos db.r5.xlarge:
+ En el primer ejemplo, cada sesión inserta 10 000 registros fila por fila. De forma predeterminada, si un comando de lenguaje de manipulación de datos (DML) no se encuentra dentro de una transacción, Aurora MySQL utiliza confirmaciones implícitas. La opción Autocommit (Confirmar automáticamente) está activada. Esto significa que para cada inserción de fila hay una confirmación. Información sobre rendimiento indica que las conexiones pasan la mayor parte del tiempo esperando en el evento de espera `io/aurora_redo_log_flush`.
![\[Ejemplo de Información sobre rendimiento del evento de espera\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
Esto se debe al uso de las instrucciones de inserción sencillas.
![\[Insertar instrucciones en SQL principal\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
Los 50 000 registros tardan 3,5 minutos en insertarse.
+ En el segundo ejemplo, las inserciones se realizan en lotes de 1000 lotes, es decir, cada conexión realiza 10 confirmaciones en lugar de 10 000. Información sobre rendimiento indica que las conexiones no pasan la mayor parte del tiempo en el evento de espera `io/aurora_redo_log_flush`.
![\[Ejemplo de Información sobre rendimiento del evento de espera con un menor impacto\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
Los 50 000 registros tardan 4 segundos en insertarse.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Identificar las sesiones y consultas problemáticas](#ams-waits.io-auredologflush.actions.identify-queries)
+ [Agrupar sus operaciones de escritura](#ams-waits.io-auredologflush.actions.action0)
+ [Desactivar la confirmación automática](#ams-waits.io-auredologflush.actions.action1)
+ [Utilizar transacciones](#ams-waits.io-auredologflush.action2)
+ [Utilizar lotes](#ams-waits.io-auredologflush.action3)
### Identificar las sesiones y consultas problemáticas
Si su instancia de base de datos tiene un cuello de botella, la primera tarea que debe realizar es buscar las sesiones y consultas que lo provocan. Para ver una entrada de blog útil sobre AWS Database, consulte [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**Para identificar sesiones y consultas que provocan un cuello de botella**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información de rendimiento**.
1. Seleccione la instancia de base de datos.
1. En **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. En la parte inferior de la página, elija **Top SQL (SQL principal)**.
Las consultas de la parte superior de la lista son las que provocan la mayor carga de la base de datos.
### Agrupar sus operaciones de escritura
Los ejemplos siguientes desencadenan el evento de espera `io/aurora_redo_log_flush`. (La opción Autocommit [Confirmar automáticamente] está activada).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Para reducir el tiempo de espera en el evento de espera `io/aurora_redo_log_flush`, agrupe sus operaciones de escritura de forma lógica en una única confirmación para reducir las llamadas persistentes al almacenamiento.
### Desactivar la confirmación automática
Desactive la confirmación automática antes de realizar grandes cambios que no están dentro de una transacción, tal como se muestra en el ejemplo siguiente.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Utilizar transacciones
Puede utilizar transacciones, tal como se muestra en el ejemplo siguiente.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizar lotes
También puede realizar cambios en lotes, tal como se muestra en el siguiente ejemplo. Sin embargo, el uso de lotes demasiado grandes puede provocar problemas de rendimiento, sobre todo en réplicas de lectura o cuando se realiza una recuperación a un momento dado (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
El evento `io/aurora_respond_to_client` se produce cuando un subproceso está a la espera de devolver un conjunto de resultados a un cliente.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.respond-to-client.context.supported)
+ [Contexto](#ams-waits.respond-to-client.context)
+ [Causas probables del aumento de las esperas](#ams-waits.respond-to-client.causes)
+ [Acciones](#ams-waits.respond-to-client.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 2
## Contexto
El evento `io/aurora_respond_to_client` indica que un subproceso está a la espera de devolver un conjunto de resultados a un cliente.
El procesamiento de consultas se ha completado y los resultados se devuelven al cliente de la aplicación. Sin embargo, dado que no hay suficiente ancho de banda de red en el clúster de base de datos, un subproceso está a la espera para devolver el conjunto de resultados.
## Causas probables del aumento de las esperas
Cuando el evento `io/aurora_respond_to_client` aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
**Instancia de base de datos insuficiente para la carga de trabajo**
La clase de instancia de base de datos que utiliza el clúster de base de datos no tiene el ancho de banda de red necesario para procesar la carga de trabajo de forma eficiente.
**Grandes conjuntos de resultados**
Se ha producido un aumento en el tamaño del conjunto de resultados que se devuelve porque la consulta devuelve un mayor número de filas. El conjunto de resultados de gran tamaño consume más ancho de banda de red.
**Aumento de la carga en el cliente**
Puede haber presión de la CPU, presión de memoria o saturación en el cliente. Un aumento de la carga en el cliente retrasa la recepción de los datos del clúster de la base de datos de Aurora MySQL.
**Aumento de la latencia de la red**
Puede haber un aumento de la latencia de la red entre el clúster de la base de datos de Aurora MySQL y el cliente. Una mayor latencia de la red aumenta el tiempo necesario para que el cliente reciba los datos.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.respond-to-client.actions.identify)
+ [Escalar la clase de instancia de base de datos](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Verificar la carga de trabajo en busca de resultados inesperados](#ams-waits.respond-to-client.actions.workload)
+ [Distribuir la carga de trabajo con instancias de lector](#ams-waits.respond-to-client.actions.balance)
+ [Utilizar el modificador SQL\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### Identificar las sesiones y consultas que provocan los eventos
Puede utilizar Información sobre rendimiento para mostrar las consultas que bloqueó el evento de espera `io/aurora_respond_to_client`. 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 buscar consultas SQL responsables de cargas elevadas**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información sobre rendimiento**.
1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Escalar la clase de instancia de base de datos
Verifique el aumento del valor de las métricas de Amazon CloudWatch relacionadas con el rendimiento de la red, como, por ejemplo, `NetworkReceiveThroughput` y `NetworkTransmitThroughput`. Si se está llegando al límite de ancho de banda de red de la clase de instancia de base de datos, puede escalar la clase de instancia de base de datos que utiliza el clúster de base de datos modificando el clúster de base de datos. Una clase de instancia de base de datos con mayor ancho de banda de red devuelve datos a los clientes de forma más eficiente.
Para obtener más información acerca del monitoreo de métricas de Amazon CloudWatch, consulte [Consulta de métricas en la consola de Amazon RDS](USER_Monitoring.md). Para obtener información acerca de las clases de instancia de base de datos, consulte [Clases de instancia de base de datos de Amazon Aurora](Concepts.DBInstanceClass.md). Para obtener información acerca de la modificación de un clúster de base de datos, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md).
### Verificar la carga de trabajo en busca de resultados inesperados
Verifique la carga de trabajo en el clúster de base de datos y asegúrese de que no produzca resultados inesperados. Por ejemplo, puede haber consultas que devuelvan un mayor número de filas que el esperado. En este caso, puede utilizar las métricas de contador de Información sobre rendimiento, como, por ejemplo, `Innodb_rows_read`. Para obtener más información, consulte [Métricas de contador de Información de rendimiento](USER_PerfInsights_Counters.md).
### Distribuir la carga de trabajo con instancias de lector
Puede distribuir la carga de trabajo de solo lectura con réplicas de Aurora. Puede escalar horizontalmente con la incorporación de más réplicas de Aurora. Si lo hace, se pueden incrementar los límites de limitación controlada del ancho de banda de la red. Para obtener más información, consulte [Clústeres de base de datos de Amazon Aurora](Aurora.Overview.md).
### Utilizar el modificador SQL\$1BUFFER\$1RESULT
Puede agregar el modificador `SQL_BUFFER_RESULT` a las instrucciones `SELECT` para forzar el resultado a una tabla temporal antes de que se devuelva al cliente. Este modificador puede ayudar con problemas de rendimiento cuando los bloqueos InnoDB no se liberan porque las consultas se encuentran en estado de espera `io/aurora_respond_to_client`. Para obtener más información, consulte [SELECT Statement](https://dev.mysql.com/doc/refman/5.7/en/select.html) en la documentación de MySQL.
# io/redo\$1log\$1flush
El evento `io/redo_log_flush` se produce cuando una sesión escribe datos persistentes en el almacenamiento de Amazon Aurora.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.io-redologflush.context.supported)
+ [Contexto](#ams-waits.io-redologflush.context)
+ [Causas probables del aumento de las esperas](#ams-waits.io-redologflush.causes)
+ [Acciones](#ams-waits.io-redologflush.actions)
## 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
El evento `io/redo_log_flush` es para una operación de entrada/salida de escritura (E/S) en Aurora MySQL.
**nota**
En la versión 2 de Aurora MySQL, este evento de espera se denomina [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Causas probables del aumento de las esperas
Para la persistencia de datos, las confirmaciones requieren una escritura duradera en un almacenamiento estable. Si la base de datos está realizando demasiadas confirmaciones, se produce un evento de espera en la operación de E/S de escritura, el evento de espera `io/redo_log_flush`.
Para ver ejemplos del comportamiento de este evento de espera, consulte [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Identificar las sesiones y consultas problemáticas](#ams-waits.io-redologflush.actions.identify-queries)
+ [Agrupar sus operaciones de escritura](#ams-waits.io-redologflush.actions.action0)
+ [Desactivar la confirmación automática](#ams-waits.io-redologflush.actions.action1)
+ [Utilizar transacciones](#ams-waits.io-redologflush.action2)
+ [Utilizar lotes](#ams-waits.io-redologflush.action3)
### Identificar las sesiones y consultas problemáticas
Si su instancia de base de datos tiene un cuello de botella, la primera tarea que debe realizar es buscar las sesiones y consultas que lo provocan. Para ver una entrada de blog útil sobre AWS Database, consulte [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**Para identificar sesiones y consultas que provocan un cuello de botella**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información de rendimiento**.
1. Seleccione la instancia de base de datos.
1. En **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. En la parte inferior de la página, elija **Top SQL (SQL principal)**.
Las consultas de la parte superior de la lista son las que provocan la mayor carga de la base de datos.
### Agrupar sus operaciones de escritura
Los ejemplos siguientes desencadenan el evento de espera `io/redo_log_flush`. (La opción Autocommit [Confirmar automáticamente] está activada).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Para reducir el tiempo de espera en el evento de espera `io/redo_log_flush`, agrupe sus operaciones de escritura de forma lógica en una única confirmación para reducir las llamadas persistentes al almacenamiento.
### Desactivar la confirmación automática
Desactive la confirmación automática antes de realizar grandes cambios que no están dentro de una transacción, tal como se muestra en el ejemplo siguiente.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Utilizar transacciones
Puede utilizar transacciones, tal como se muestra en el ejemplo siguiente.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizar lotes
También puede realizar cambios en lotes, tal como se muestra en el siguiente ejemplo. Sin embargo, el uso de lotes demasiado grandes puede provocar problemas de rendimiento, sobre todo en réplicas de lectura o cuando se realiza una recuperación a un momento dado (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
El evento `io/socket/sql/client_connection` se produce cuando un subproceso está en proceso de controlar una nueva conexión.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.client-connection.context.supported)
+ [Contexto](#ams-waits.client-connection.context)
+ [Causas probables del aumento de las esperas](#ams-waits.client-connection.causes)
+ [Acciones](#ams-waits.client-connection.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL, versiones 2 y 3
## Contexto
El evento `io/socket/sql/client_connection` indica que mysqld está ocupado con la creación de subprocesos para controlar las nuevas conexiones de clientes entrantes. En este escenario, el procesamiento del responder a las nuevas solicitudes de conexión de clientes se ralentiza mientras las conexiones esperan a que se asigne el subproceso. Para obtener más información, consulte [Servidor MySQL (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld).
## Causas probables del aumento de las esperas
Cuando este evento aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
+ Se produce un aumento repentino de las nuevas conexiones de usuario desde la aplicación a la instancia de Amazon RDS.
+ La instancia de base de datos no puede procesar nuevas conexiones porque la red, la CPU o la memoria tienen una limitación controlada.
## Acciones
Si `io/socket/sql/client_connection` domina la actividad de la base de datos, no indica necesariamente un problema de rendimiento. En una base de datos que no está inactiva, siempre hay un evento de espera activo. Actúe solo cuando el rendimiento se vea reducido. Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Identificar las sesiones y consultas problemáticas](#ams-waits.client-connection.actions.identify-queries)
+ [Seguir las prácticas recomendadas de administración de conexiones](#ams-waits.client-connection.actions.manage-connections)
+ [Escalar verticalmente la instancia si se están limitando de forma controlada los recursos](#ams-waits.client-connection.upgrade)
+ [Verificar los principales hosts y usuarios](#ams-waits.client-connection.top-hosts)
+ [Consultar las tablas performance\$1schema](#ams-waits.client-connection.perf-schema)
+ [Verificar los estados de los subprocesos de sus consultas](#ams-waits.client-connection.thread-states)
+ [Auditar las solicitudes y consultas](#ams-waits.client-connection.auditing)
+ [Agrupar las conexiones de base de datos](#ams-waits.client-connection.pooling)
### Identificar las sesiones y consultas problemáticas
Si su instancia de base de datos tiene un cuello de botella, la primera tarea que debe realizar es buscar las sesiones y consultas que lo provocan. Para ver una entrada de blog útil, consulte [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
**Para identificar sesiones y consultas que provocan un cuello de botella**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información de rendimiento**.
1. Seleccione la instancia de base de datos.
1. En **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. En la parte inferior de la página, elija **Top SQL (SQL principal)**.
Las consultas de la parte superior de la lista son las que provocan la mayor carga de la base de datos.
### Seguir las prácticas recomendadas de administración de conexiones
Para administrar sus conexiones, tenga en cuenta las siguientes estrategias:
+ Utilice la agrupación de conexiones.
Puede aumentar gradualmente el número de conexiones según sea necesario. Para obtener más información, consulte el documento técnico [Amazon Aurora MySQL Database Administrator’s Handbook](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Utilice un nodo lector para redistribuir el tráfico de solo lectura.
Para obtener más información, consulte [Réplicas de Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) y [Conexiones de puntos de conexión de Amazon Aurora](Aurora.Overview.Endpoints.md).
### Escalar verticalmente la instancia si se están limitando de forma controlada los recursos
Busque ejemplos de limitación controlada en los siguientes recursos:
+ CPU
Verifique las métricas de Amazon CloudWatch para detectar usos elevados de la CPU.
+ Network
Verifique el aumento del valor de las métricas de CloudWatch `network receive throughput` y `network transmit throughput`. Si la instancia ha alcanzado el límite de ancho de banda de red para la clase de instancia, considere la posibilidad de escalar verticalmente la instancia de RDS a un tipo de clase de instancia superior. Para obtener más información, consulte [Clases de instancia de base de datos de Amazon Aurora](Concepts.DBInstanceClass.md).
+ Memoria que se puede liberar
Verifique si hay una caída en la métrica de CloudWatch `FreeableMemory`. Considere, además, la posibilidad de activar el monitoreo mejorado. Para obtener más información, consulte [Supervisión de las métricas del sistema operativo con Supervisión mejorada](USER_Monitoring.OS.md).
### Verificar los principales hosts y usuarios
Utilice Información sobre rendimiento para verificar los principales hosts y usuarios. Para obtener más información, consulte [Análisis de métricas mediante el panel de Información sobre rendimiento](USER_PerfInsights.UsingDashboard.md).
### Consultar las tablas performance\$1schema
Para obtener un recuento preciso de las conexiones actuales y totales, consulte las tablas de `performance_schema`. Con esta técnica, podrá identificar el host o usuario de origen responsable de crear un gran número de conexiones. Por ejemplo, consulte las tablas `performance_schema` como se muestra a continuación.
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### Verificar los estados de los subprocesos de sus consultas
Si su problema de rendimiento continúa, verifique los estados de los subprocesos de sus consultas. En el cliente `mysql`, ejecute el siguiente comando.
```
show processlist;
```
### Auditar las solicitudes y consultas
Para verificar la naturaleza de las solicitudes y consultas de las cuentas de usuario, utilice la auditoría avanzada de Aurora MySQL. Para obtener información sobre cómo activar la auditoría, consulte [Uso de auditorías avanzadas con un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
### Agrupar las conexiones de base de datos
Considere la posibilidad de utilizar Amazon RDS Proxy para la administración de conexiones. Con el proxy de RDS puede permitir a las aplicaciones agrupar y compartir conexiones de base de datos para mejorar su capacidad de escala. RDS Proxy hace que las aplicaciones sean más resistentes a los errores de base de datos al conectarse automáticamente a una instancia de base de datos en espera mientras se preservan las conexiones de las aplicaciones. Para obtener más información, consulte [Amazon RDS Proxy para Aurora](rds-proxy.md).
# io/table/sql/handler
El evento `io/table/sql/handler` se produce cuando el trabajo se ha delegado en un motor de almacenamiento.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.waitio.context.supported)
+ [Contexto](#ams-waits.waitio.context)
+ [Causas probables del aumento de las esperas](#ams-waits.waitio.causes)
+ [Acciones](#ams-waits.waitio.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL, versiones 2 y 3
## Contexto
El evento `io/table` indica una espera para acceder a una tabla. Este evento se produce independientemente de si los datos se almacenan en caché en el grupo de búferes o si se accede en el disco. El evento `io/table/sql/handler` indica un aumento de la actividad de la carga de trabajo.
Un *controlador* es una rutina especializada en un determinado tipo de datos o centrada en determinadas tareas especiales. Por ejemplo, un controlador de eventos recibe y procesa eventos y señales del sistema operativo o de una interfaz de usuario. Un controlador de memoria realiza tareas relacionadas con la memoria. Un controlador de entrada de archivos es una función que recibe una entrada de archivos y realiza tareas especiales en los datos, en función del contexto.
Vistas como, por ejemplo, `performance_schema.events_waits_current`, a menudo muestran `io/table/sql/handler` cuando la espera real es un evento de espera anidado como un bloqueo. Cuando la espera real no es `io/table/sql/handler`, Información sobre rendimiento informa del evento de espera anidado. Cuando Información sobre rendimiento informa `io/table/sql/handler`, representa el procesamiento de la solicitud de E/S por parte de InnoDB y no un evento de espera anidado oculto. Para obtener más información, consulte [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) en *MySQL Reference Manual*.
El evento `io/table/sql/handler` a menudo aparece en los principales eventos de espera con esperas de E/S como `io/aurora_redo_log_flush`.
## Causas probables del aumento de las esperas
En Información sobre rendimiento, los picos repentinos en el evento `io/table/sql/handler` indican un aumento de la actividad de la carga de trabajo. El aumento de la actividad significa un aumento de E/S.
Información sobre rendimiento filtra los ID de eventos de anidamiento y no informa de ninguna espera de `io/table/sql/handler` cuando el evento anidado subyacente sea una espera de bloqueo. Por ejemplo, si el evento de causa raíz es [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), Información sobre rendimiento muestra esta espera en los eventos de espera principales y no `io/table/sql/handler`.
En vistas como, por ejemplo, `performance_schema.events_waits_current`, las esperas de `io/table/sql/handler` a menudo aparecen cuando la espera real es un evento de espera anidado como un bloqueo. Cuando la espera real difiere de `io/table/sql/handler`, Información sobre rendimiento busca la espera anidada e informa de la espera real en lugar de `io/table/sql/handler`. Cuando Información sobre rendimiento informa de `io/table/sql/handler`, la espera real es `io/table/sql/handler` y no un evento de espera anidado oculto. Para obtener más información, consulte [Performance Schema Atom and Molecule Events](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html) en *MySQL 5.7 Reference Manual*.
## Acciones
Si este evento de espera domina la actividad de la base de datos, no indica necesariamente un problema de rendimiento. Cuando la base de datos está activa, siempre hay un evento de espera activo. Solo debe actuar cuando el rendimiento se vea reducido.
Recomendamos diferentes acciones en función de los demás eventos de espera que vea.
**Topics**
+ [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.waitio.actions.identify)
+ [Verificar la correlación con las métricas de contador de Información sobre rendimiento](#ams-waits.waitio.actions.filters)
+ [Verificar otros eventos de espera correlacionados](#ams-waits.waitio.actions.maintenance)
### 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 buscar consultas SQL responsables de cargas elevadas**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información sobre rendimiento**.
1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. 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 [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Verificar la correlación con las métricas de contador de Información sobre rendimiento
Verifique si hay métricas de contador de Información sobre rendimiento como `Innodb_rows_changed`. Si las métricas de contador están correlacionadas con `io/table/sql/handler`, siga los pasos que se indican a continuación:
1. En Información sobre rendimiento, busque las instrucciones SQL responsables del evento de espera principal `io/table/sql/handler`. Si es posible, optimice esta instrucción para que devuelva menos filas.
1. Recupere las tablas principales de las vistas `schema_table_statistics` y `x$schema_table_statistics`. Estas vistas muestran la cantidad de tiempo que empleó la tabla. Para obtener más información, consulte [The schema\$1table\$1statistics and x\$1schema\$1table\$1statistics Views](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html) en el *MySQL Reference Manual*.
De forma predeterminada, las filas se ordenan por tiempo de espera total descendente. Las tablas con más contención se muestran en primer lugar. La salida indica si el tiempo se dedica a lecturas, escrituras, recuperaciones, inserciones, actualizaciones o eliminaciones.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### Verificar otros eventos de espera correlacionados
Si `synch/sxlock/innodb/btr_search_latch` y `io/table/sql/handler` contribuyen más a la anomalía de carga de la base de datos, verifique si la variable `innodb_adaptive_hash_index` está activada. Si lo está, considere la posibilidad de aumentar el valor del parámetro `innodb_adaptive_hash_index_parts`.
Si el índice hash adaptativo está desactivado, considere la posibilidad de activarlo. Para obtener más información acerca del índice hash adaptativo, consulte los siguientes recursos:
+ Artículo [Is Adaptive Hash Index in InnoDB right for my workload?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload) en el sitio web de Percona.
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html) en el *MySQL Reference Manual*.
+ Artículo [Contention in MySQL InnoDB: Useful Info From the Semaphores Section](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/) en el sitio web de Percona.
**nota**
El índice hash adaptativo no se admite en instancias de base de datos de lector de Aurora.
En algunos casos, el rendimiento puede ser deficiente en una instancia lectora cuando `synch/sxlock/innodb/btr_search_latch` y `io/table/sql/handler` son dominantes. Si es así, considere la posibilidad de redirigir la carga de trabajo temporalmente a la instancia de base de datos del escritor y active el índice hash adaptativo.
# synch/cond/innodb/row\$1lock\$1wait
El evento `synch/cond/innodb/row_lock_wait` se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. Para obtener información, consulte [InnoDB Locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) en la documentación de MySQL.
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 3
## Causas probables del aumento de las esperas
Las múltiples instrucciones de lenguaje de manipulación de datos (DML) tienen acceso a la misma fila o filas simultáneamente.
## Acciones
Recomendamos diferentes acciones en función de los demás eventos de espera que vea.
**Topics**
+ [Buscar y responder a las instrucciones SQL responsables de este evento de espera](#ams-waits.row-lock-wait.actions.id)
+ [Buscar y responder a la sesión de bloqueo](#ams-waits.row-lock-wait.actions.blocker)
### Buscar y responder a las instrucciones SQL responsables de este evento de espera
Utilice Información sobre rendimiento para identificar las instrucciones SQL responsables de este evento de espera. Consideremos la posibilidad de aplicar las estrategias siguientes:
+ Si los bloqueos de fila son un problema persistente, considere la posibilidad de reescribir la aplicación para utilizar un bloqueo optimista.
+ Utilice instrucciones de varias filas.
+ Distribuya la carga de trabajo en distintos objetos de base de datos. Puede hacerlo mediante una partición.
+ Verifique el valor del parámetro `innodb_lock_wait_timeout`. Controla cuánto tiempo esperan las transacciones antes de generar un error de tiempo de espera.
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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Buscar y responder a la sesión de bloqueo
Determine si la sesión de bloqueo está inactiva o activa. Además, averigüe si la sesión procede de una aplicación o de un usuario activo.
Para identificar la sesión que mantiene el candado, puede ejecutar `SHOW ENGINE INNODB STATUS`. A continuación se muestra un resultado de ejemplo.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
O bien, puede utilizar la siguiente consulta para extraer detalles sobre los bloqueos actuales.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Cuando identifique la sesión, puede seguir una de las opciones siguientes:
+ Ponerse en contacto con el propietario o el usuario de la aplicación.
+ Si la sesión de bloqueo está inactiva, considere la posibilidad de finalizar la sesión de bloqueo. Esta acción podría desencadenar una larga restauración. Para aprender a finalizar una sesión, consulte [Finalización de una sesión o una consulta](mysql-stored-proc-ending.md).
Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html) en la documentación de MySQL.
# synch/cond/innodb/row\$1lock\$1wait\$1cond
El evento `synch/cond/innodb/row_lock_wait_cond` se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. Para obtener información, consulte [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) en la documentación de MySQL.
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 2
## Causas probables del aumento de las esperas
Las múltiples instrucciones de lenguaje de manipulación de datos (DML) tienen acceso a la misma fila o filas simultáneamente.
## Acciones
Recomendamos diferentes acciones en función de los demás eventos de espera que vea.
**Topics**
+ [Buscar y responder a las instrucciones SQL responsables de este evento de espera](#ams-waits.row-lock-wait-cond.actions.id)
+ [Buscar y responder a la sesión de bloqueo](#ams-waits.row-lock-wait-cond.actions.blocker)
### Buscar y responder a las instrucciones SQL responsables de este evento de espera
Utilice Información sobre rendimiento para identificar las instrucciones SQL responsables de este evento de espera. Consideremos la posibilidad de aplicar las estrategias siguientes:
+ Si los bloqueos de fila son un problema persistente, considere la posibilidad de reescribir la aplicación para utilizar un bloqueo optimista.
+ Utilice instrucciones de varias filas.
+ Distribuya la carga de trabajo en distintos objetos de base de datos. Puede hacerlo mediante una partición.
+ Verifique el valor del parámetro `innodb_lock_wait_timeout`. Controla cuánto tiempo esperan las transacciones antes de generar un error de tiempo de espera.
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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Buscar y responder a la sesión de bloqueo
Determine si la sesión de bloqueo está inactiva o activa. Además, averigüe si la sesión procede de una aplicación o de un usuario activo.
Para identificar la sesión que mantiene el candado, puede ejecutar `SHOW ENGINE INNODB STATUS`. A continuación se muestra un resultado de ejemplo.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
O bien, puede utilizar la siguiente consulta para extraer detalles sobre los bloqueos actuales.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Cuando identifique la sesión, puede seguir una de las opciones siguientes:
+ Ponerse en contacto con el propietario o el usuario de la aplicación.
+ Si la sesión de bloqueo está inactiva, considere la posibilidad de finalizar la sesión de bloqueo. Esta acción podría desencadenar una larga restauración. Para aprender a finalizar una sesión, consulte [Finalización de una sesión o una consulta](mysql-stored-proc-ending.md).
Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) en la documentación de MySQL.
# synch/cond/sql/MDL\$1context::COND\$1wait\$1status
El evento `synch/cond/sql/MDL_context::COND_wait_status` se produce cuando hay subprocesos a la espera en un bloqueo de metadatos de tabla.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.cond-wait-status.context.supported)
+ [Contexto](#ams-waits.cond-wait-status.context)
+ [Causas probables del aumento de las esperas](#ams-waits.cond-wait-status.causes)
+ [Acciones](#ams-waits.cond-wait-status.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL, versiones 2 y 3
## Contexto
El evento `synch/cond/sql/MDL_context::COND_wait_status` indica que hay subprocesos a la espera en un bloqueo de metadatos de tabla. En determinados casos, una sesión mantiene un bloqueo de metadatos en una tabla mientras otra sesión intenta adquirir el mismo bloqueo en la misma tabla. En tal caso, la segunda sesión espera en el evento de espera `synch/cond/sql/MDL_context::COND_wait_status`.
MySQL utiliza el bloqueo de metadatos para administrar el acceso simultáneo a los objetos de base de datos y garantizar la coherencia de los datos. El bloqueo de metadatos se aplica a tablas, esquemas, eventos programados, espacios de tabla y bloqueos de usuario adquiridos con la función `get_lock` y programas almacenados. Los programas almacenados incluyen procedimientos, funciones y desencadenadores. Para obtener más información, consulte [Metadata locking](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html) en la documentación de MySQL.
La lista de procesos de MySQL muestra esta sesión en el estado `waiting for metadata lock`. En Información sobre rendimiento, si `Performance_schema` está activado, el evento `synch/cond/sql/MDL_context::COND_wait_status` aparece.
El tiempo de espera predeterminado de una consulta a la espera de un bloqueo de metadatos se basa en el valor del parámetro `lock_wait_timeout`, que por defecto es 31 536 000 segundos (365 días).
Para obtener más información sobre los distintos bloqueos de InnoDB y los tipos de bloqueos que pueden provocar conflictos, consulte [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) en la documentación de MySQL.
## Causas probables del aumento de las esperas
Cuando el evento `synch/cond/sql/MDL_context::COND_wait_status` aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:
**Transacciones de larga duración**
Una o varias transacciones están modificando una gran cantidad de datos y mantienen bloqueos en las tablas durante mucho tiempo.
**Transacciones inactivas**
Una o más transacciones permanecen abiertas durante mucho tiempo, sin confirmarse o revertirse.
**Instrucciones DDL en tablas de gran tamaño**
Una o varias instrucciones de definición de datos (DDL), como, por ejemplo, los comandos `ALTER TABLE`, se ejecutaron en tablas de gran tamaño.
**Bloqueos de tabla explícitos**
Hay bloqueos explícitos en tablas que no se están lanzando a tiempo. Por ejemplo, una aplicación puede ejecutar instrucciones `LOCK TABLE` de manera incorrecta.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera y de la versión del clúster de Aurora MySQL DB.
**Topics**
+ [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.cond-wait-status.actions.identify)
+ [Verificar eventos pasados](#ams-waits.cond-wait-status.actions.past-events)
+ [Ejecutar consultas en Aurora MySQL versión 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [Responder a la sesión de bloqueo](#ams-waits.cond-wait-status.actions.blocker)
### Identificar las sesiones y consultas que provocan los eventos
Puede utilizar Información sobre rendimiento para mostrar las consultas que bloqueó el evento de espera `synch/cond/sql/MDL_context::COND_wait_status`. Sin embargo, para identificar la sesión de bloqueo, consulte las tablas de metadatos desde `performance_schema` y `information_schema` en el clúster de base de datos.
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 buscar consultas SQL responsables de cargas elevadas**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información sobre rendimiento**.
1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Verificar eventos pasados
Puede obtener información sobre este evento de espera para verificar si hay ocurrencias anteriores del mismo. Para ello, complete las acciones siguientes:
+ Verifique el lenguaje de manipulación de datos (DML) y el rendimiento y la latencia de DDL para ver si se han producido cambios en la carga de trabajo.
Puede utilizar Información sobre rendimiento para buscar las consultas que están a la espera en este evento en el momento del problema. Además, puede ver el resumen de las consultas que se ejecutan cerca del momento del problema.
+ Si los registros de auditoría o los registros generales están activados para el clúster de base de datos, puede verificar si se ejecutan todas las consultas en los objetos (schema.table) involucrados en la transacción en espera. También puede verificar si se han completado las consultas que se ejecutaron antes de la transacción.
La información disponible para solucionar problemas de eventos pasados es limitada. La realización de estas verificaciones no muestra qué objeto está a la espera de información. Sin embargo, puede identificar tablas con cargas pesadas en el momento en que se produjo el evento y el conjunto de filas operadas con frecuencia que provocan conflictos en el momento del problema. A continuación, podrá utilizar esta información para reproducir el problema en un entorno de prueba y proporcionar información sobre su causa.
### Ejecutar consultas en Aurora MySQL versión 2
En Aurora MySQL versión 2, puede identificar la sesión bloqueada directamente con la consulta de tablas `performance_schema` o vistas de esquema `sys`. Un ejemplo puede ilustrar cómo consultar tablas para identificar consultas y sesiones de bloqueo.
En el siguiente resultado de la lista de procesos, el ID de conexión `89` está a la espera en un bloqueo de metadatos y ejecuta el comando `TRUNCATE TABLE`. En una consulta sobre las tablas `performance_schema` o las vistas de esquema `sys`, el resultado muestra que la sesión de bloqueo es `76`.
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
A continuación, una consulta sobre las tablas `performance_schema` o las vistas de esquema `sys` muestra que la sesión de bloqueo es `76`.
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### Responder a la sesión de bloqueo
Cuando identifique la sesión, puede seguir una de las opciones siguientes:
+ Ponerse en contacto con el propietario o el usuario de la aplicación.
+ Si la sesión de bloqueo está inactiva, considere la posibilidad de finalizar la sesión de bloqueo. Esta acción podría desencadenar una larga restauración. Para aprender a finalizar una sesión, consulte [Finalización de una sesión o una consulta](mysql-stored-proc-ending.md).
Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) en la documentación de MySQL.
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
El evento `synch/mutex/innodb/aurora_lock_thread_slot_futex` se produce cuando una sesión ha bloqueado una fila para una actualización y otra sesión intenta actualizar la misma fila. Para obtener información, consulte [InnoDB Locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) en *MySQL Reference*.
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL versión 2
## Causas probables del aumento de las esperas
Las múltiples instrucciones de lenguaje de manipulación de datos (DML) tienen acceso a la misma fila o filas simultáneamente.
## Acciones
Recomendamos diferentes acciones en función de los demás eventos de espera que vea.
**Topics**
+ [Buscar y responder a las instrucciones SQL responsables de este evento de espera](#ams-waits.waitsynch.actions.id)
+ [Buscar y responder a la sesión de bloqueo](#ams-waits.waitsynch.actions.blocker)
### Buscar y responder a las instrucciones SQL responsables de este evento de espera
Utilice Información sobre rendimiento para identificar las instrucciones SQL responsables de este evento de espera. Consideremos la posibilidad de aplicar las estrategias siguientes:
+ Si los bloqueos de fila son un problema persistente, considere la posibilidad de reescribir la aplicación para utilizar un bloqueo optimista.
+ Utilice instrucciones de varias filas.
+ Distribuya la carga de trabajo en distintos objetos de base de datos. Puede hacerlo mediante una partición.
+ Verifique el valor del parámetro `innodb_lock_wait_timeout`. Controla cuánto tiempo esperan las transacciones antes de generar un error de tiempo de espera.
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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Buscar y responder a la sesión de bloqueo
Determine si la sesión de bloqueo está inactiva o activa. Además, averigüe si la sesión procede de una aplicación o de un usuario activo.
Para identificar la sesión que mantiene el candado, puede ejecutar `SHOW ENGINE INNODB STATUS`. A continuación se muestra un resultado de ejemplo.
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
O bien, puede utilizar la siguiente consulta para extraer detalles sobre los bloqueos actuales.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Cuando identifique la sesión, puede seguir una de las opciones siguientes:
+ Ponerse en contacto con el propietario o el usuario de la aplicación.
+ Si la sesión de bloqueo está inactiva, considere la posibilidad de finalizar la sesión de bloqueo. Esta acción podría desencadenar una larga restauración. Para aprender a finalizar una sesión, consulte [Finalización de una sesión o una consulta](mysql-stored-proc-ending.md).
Para obtener más información acerca de cómo identificar las transacciones de bloqueo, consulte [Using InnoDB Transaction and Locking Information](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html) en *MySQL Reference Manual*.
# synch/mutex/innodb/buf\$1pool\$1mutex
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.
**Topics**
+ [Versiones del motor relevantes](#ams-waits.bufpoolmutex.context.supported)
+ [Contexto](#ams-waits.bufpoolmutex.context)
+ [Causas probables del aumento de las esperas](#ams-waits.bufpoolmutex.causes)
+ [Acciones](#ams-waits.bufpoolmutex.actions)
## 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](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) 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.
**Topics**
+ [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.bufpoolmutex.actions.identify)
+ [Utilizar Información sobre rendimiento](#ams-waits.bufpoolmutex.actions.action1)
+ [Crear réplicas de Aurora](#ams-waits.bufpoolmutex.actions.action2)
+ [Examinar el tamaño del grupo de búferes](#ams-waits.bufpoolmutex.actions.action3)
+ [Monitorear el historial de estado global](#ams-waits.bufpoolmutex.actions.action4)
### 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/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Performance Insights**.
1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. 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](https://aws.amazon.com/blogs/database/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 [Amazon Aurora Auto Scaling con réplicas de Aurora](Aurora.Integrating.AutoScaling.md).
### 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\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).
# synch/mutex/innodb/fil\$1system\$1mutex
El evento `synch/mutex/innodb/fil_system_mutex` se produce cuando una sesión está a la espera para acceder a la memoria caché de memoria del espacio de tabla.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Contexto](#ams-waits.innodb-fil-system-mutex.context)
+ [Causas probables del aumento de las esperas](#ams-waits.innodb-fil-system-mutex.causes)
+ [Acciones](#ams-waits.innodb-fil-system-mutex.actions)
## Versiones del motor admitidas
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL, versiones 2 y 3
## Contexto
InnoDB utiliza espacios de tabla para administrar el área de almacenamiento de las tablas y archivos de registro. La *caché de memoria del espacio de tabla* es una estructura de memoria global que mantiene información sobre los espacios de tabla. MySQL utiliza las esperas `synch/mutex/innodb/fil_system_mutex` para controlar el acceso simultáneo a la caché de memoria del espacio de tabla.
El evento `synch/mutex/innodb/fil_system_mutex` indica que actualmente hay más de una operación que necesita recuperar y manipular información en la caché de memoria del espacio de tabla para el mismo espacio de tabla.
## Causas probables del aumento de las esperas
Cuando el evento `synch/mutex/innodb/fil_system_mutex` aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, esto suele deberse a la presencia de las condiciones siguientes:
+ Aumento de las operaciones simultáneas de lenguaje de manipulación de datos (DML) que actualizan o eliminan datos de la misma tabla.
+ El espacio de tabla de esta tabla es muy grande y tiene muchas páginas de datos.
+ El factor de relleno de estas páginas de datos es bajo.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.innodb-fil-system-mutex.actions.identify)
+ [Reorganizar grandes tablas durante las horas de menor actividad](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### 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 buscar consultas SQL responsables de cargas elevadas**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información sobre rendimiento**.
1. Elija una instancia de base de datos. Se muestra el panel Información sobre rendimiento para dicha instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. 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 [Analyze Amazon Aurora MySQL Workloads with Performance Insights](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
Otra forma de averiguar qué consultas están causando un gran número de esperas `synch/mutex/innodb/fil_system_mutex` consiste en verificar `performance_schema`, como en el ejemplo siguiente.
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### Reorganizar grandes tablas durante las horas de menor actividad
Reorganice las tablas de gran tamaño que identifique como origen de un gran número de eventos de espera `synch/mutex/innodb/fil_system_mutex` durante el periodo de mantenimiento fuera del horario de producción. De este modo, se garantiza que la limpieza de la asignación de los espacios de tabla internos no tenga lugar en momentos en los que el acceso rápido a la tabla es crítico. Para obtener información sobre la reorganización de tablas, consulte [OPTIMIZE TABLE Statement](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html) en *MySQL Reference*.
# synch/mutex/innodb/trx\$1sys\$1mutex
El evento `synch/mutex/innodb/trx_sys_mutex` se produce cuando hay una elevada actividad de la base de datos con un gran número de transacciones.
**Topics**
+ [Versiones del motor relevantes](#ams-waits.trxsysmutex.context.supported)
+ [Contexto](#ams-waits.trxsysmutex.context)
+ [Causas probables del aumento de las esperas](#ams-waits.trxsysmutex.causes)
+ [Acciones](#ams-waits.trxsysmutex.actions)
## Versiones del motor relevantes
Esta información de evento de espera es compatible con las siguientes versiones del motor:
+ Aurora MySQL, versiones 2 y 3
## Contexto
Internamente, el motor de base de datos InnoDB utiliza el nivel de aislamiento de lectura repetible con instantáneas para proporcionar coherencia de lectura. Esto proporciona una vista puntual de la base de datos en el momento en que se creó la instantánea.
En InnoDB, todos los cambios se aplican a la base de datos tan pronto como llegan, independientemente de si están confirmados. Este enfoque significa que sin el control de simultaneidad multiversión (MVCC), todos los usuarios conectados a la base de datos ven todos los cambios y las filas más recientes. Por lo tanto, InnoDB requiere una forma de realizar un seguimiento de los cambios para comprender qué se debe revertir cuando sea necesario.
Para ello, InnoDB utiliza un sistema de transacciones (`trx_sys`) para realizar un seguimiento de las instantáneas. El sistema de transacciones realiza lo siguiente:
+ Realiza un seguimiento del ID de transacción de cada fila en los registros de deshacer.
+ Utiliza una estructura interna de InnoDB denominada `ReadView` que ayuda a identificar qué ID de transacción están visibles para una instantánea.
## Causas probables del aumento de las esperas
Cualquier operación de base de datos que requiera un manejo coherente y controlado (creación, lectura, actualización y eliminación) de los ID de transacciones genera una llamada desde `trx_sys` al mutex.
Estas llamadas se realizan en tres funciones:
+ `trx_sys_mutex_enter`: crea el mutex.
+ `trx_sys_mutex_exit`: libera el mutex.
+ `trx_sys_mutex_own`: comprueba si el mutex tiene propietario.
La instrumentación de InnoDB Performance Schema realiza un seguimiento de todas las llamadas de mutex `trx_sys`. El seguimiento incluye, entre otras acciones, la administración de `trx_sys` en el inicio o cierre de la base de datos, las operaciones de reversión, las limpiezas de deshacer, el acceso de lectura a filas y las cargas de grupos de búferes. La elevada actividad de la base de datos con un gran número de transacciones da como resultado la aparición frecuente de `synch/mutex/innodb/trx_sys_mutex` entre los eventos de espera principales.
Para obtener más información, consulte [Monitoring InnoDB Mutex Waits Using Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html) en la documentación de MySQL.
## Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
**Topics**
+ [Identificar las sesiones y consultas que provocan los eventos](#ams-waits.trxsysmutex.actions.identify)
+ [Examinar otros eventos de espera](#ams-waits.trxsysmutex.actions.action1)
### 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. Observe los eventos de espera que contribuyen a la carga más alta. Descubra si puede optimizar la base de datos y la aplicación para reducir esos eventos.
**Para ver el gráfico SQL principal en la Consola de administración de AWS**
1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Performance Insights**.
1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. Bajo el 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).
### Examinar otros eventos de espera
Examine los demás eventos de espera asociados con el evento de espera `synch/mutex/innodb/trx_sys_mutex`. De este modo, podrá proporcionar más información acerca de la naturaleza de la carga de trabajo. Un gran número de transacciones podría reducir el rendimiento, pero la carga de trabajo también puede hacer que esto sea necesario.
Para obtener más información sobre cómo optimizar las transacciones, consulte [Optimizing InnoDB Transaction Management](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) en la documentación de MySQL.
# synch/sxlock/innodb/hash\$1table\$1locks
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.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Contexto](#ams-waits.sx-lock-hash-table-locks.context)
+ [Causas probables del aumento de las esperas](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Acciones](#ams-waits.sx-lock-hash-table-locks.actions)
## 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](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html) en la documentación de MySQL.
## 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.
**Topics**
+ [Aumentar el tamaño del grupo de búferes](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Mejorar los patrones de acceso a datos](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Reducir o evitar análisis de tablas completas](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Verificar los registros de errores para detectar daños en la página](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### 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](https://aws.amazon.com/blogs/database/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\$1result::fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), puede probar a aumentar el tamaño de búsqueda de matriz.
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**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. En el panel de navegación, seleccione **Información sobre rendimiento**.
1. Elija una instancia de base de datos. Se muestra el panel de Información sobre rendimiento para esa instancia de base de datos.
1. En el cuadro **Database load (Carga de base de datos)**, elija **Slice by wait (Corte por espera)**.
1. 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](https://aws.amazon.com/blogs/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](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next) en la documentación de MySQL.
### 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.
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
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.
**Topics**
+ [Versiones del motor admitidas](#ams-waits.io-temppoolmanager.context.supported)
+ [Contexto](#ams-waits.io-temppoolmanager.context)
+ [Causas probables del aumento de las esperas](#ams-waits.io-temppoolmanager.causes)
+ [Acciones](#ams-waits.io-temppoolmanager.actions)
## 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 [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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 [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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.
**Topics**
+ [Supervisión y optimización del uso de las tablas temporales](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Revisión de las consultas mediante INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Aumento del parámetro innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Implementar la agrupación de conexiones](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### 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](ams3-temptable-behavior.md).
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:
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram): controla el uso máximo de RAM para las tablas temporales.
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap): establece el límite de almacenamiento de archivos asignados en memoria.
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_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](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Revisión de las consultas mediante INFORMATION\$1SCHEMA
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\$1sync\$1array\$1size
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](https://aws.amazon.com/rds/instance-types/).
### 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.