Eventos de espera de Aurora MySQL

El número de conexiones activas que están listas para ejecutarse es siempre mayor que el número de vCPU. Para obtener más información, consulte cpu.

Una sesión está conservando datos en el almacenamiento de Aurora. Este evento de espera suele ser para una operación de E/S de escritura en Aurora MySQL. Para obtener más información, consulte io/aurora_redo_log_flush.

El procesamiento de consultas se ha completado y se devuelven los resultados al cliente de la aplicación para las siguientes versiones de Aurora MySQL: 2.10.2 y versiones posteriores a 2.10, 2.09.3 y versiones posteriores a 2.09 y 2.07.7 y versiones posteriores a 2.07. Compare el ancho de banda de red de la clase de instancia de base de datos con el tamaño del conjunto de resultados que se devuelve. Además, verifique los tiempos de respuesta del lado del cliente. Si el cliente no responde y no puede procesar los paquetes TCP, pueden producirse caídas de paquetes y retransmisiones TCP. Esta situación afecta negativamente al ancho de banda de la red. En las versiones anteriores a 2.10.2, 2.09.3 y 2.07.7, el evento de espera incluye erróneamente el tiempo de inactividad. Para obtener información sobre cómo ajustar la base de datos cuando esta espera es destacada, consulte io/aurora_respond_to_client.

Los subprocesos escriben a las tablas con un formato de valores separados por comas (CSV). Compruebe el uso de tablas CSV. Una causa habitual de este evento es que se haya establecido log_output en una tabla.

Un subproceso está esperando por un archivo de registro binario (binlog) que se está escribiendo en disco.

Una sesión está conservando datos en el almacenamiento de Aurora. Este evento de espera suele ser para una operación de E/S de escritura en Aurora MySQL. Para obtener más información, consulte io/redo_log_flush.

El programa mysqld está ocupado creando subprocesos para gestionar las nuevas conexiones de clientes entrantes. Para obtener más información, consulte io/socket/sql/client_connection.

El motor está esperando el acceso 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. Para obtener más información, consulte io/table/sql/handler.

Este evento de espera es un controlador de evento de espera de bloqueo de tabla. Para obtener más información sobre los eventos de átomo y molécula del esquema de rendimiento, consulte Performance Schema Atom and Molecule Events en la documentación de MySQL.

Varias instrucciones de lenguaje de manipulación de datos (DML) acceden a las mismas filas de base de datos al mismo tiempo. Para obtener más información, consulte synch/cond/innodb/row_lock_wait.

Varias instrucciones DML acceden a las mismas filas de base de datos al mismo tiempo. Para obtener más información, consulte synch/cond/innodb/row_lock_wait_cond.

Los subprocesos están esperando por un bloqueo de metadatos de tabla. El motor utiliza este tipo de bloqueo para administrar el acceso simultáneo a un esquema de base de datos y garantizar la coherencia de los datos. Para obtener más información, consulte Optimizing Locking Operations en la documentación de MySQL. Para obtener información sobre cómo ajustar la base de datos cuando este evento es destacado, consulte synch/cond/sql/MDL_context::COND_wait_status.

Ha activado el registro binario. Puede haber un alto rendimiento de confirmaciones, un gran número de transacciones que se comprometen o réplicas que leen binlogs. Considere utilizar instrucciones de varias filas o agrupar estados de cuenta en una transacción. En Aurora, utilice bases de datos globales en lugar de replicación de registros binarios o utilice los parámetros aurora_binlog_*.

Varias instrucciones DML acceden a las mismas filas de base de datos al mismo tiempo. Para obtener más información, consulte synch/mutex/innodb/aurora_lock_thread_slot_futex.

El grupo de búferes no es lo suficientemente grande como para almacenar el conjunto de datos de trabajo. O bien, la carga de trabajo accede a páginas de una tabla específica, lo que genera contención en el grupo de búferes. Para obtener más información, consulte synch/mutex/innodb/buf_pool_mutex.

El proceso está esperando el acceso a la memoria caché de memoria del espacio de tabla. Para obtener más información, consulte synch/mutex/innodb/fil_system_mutex.

Las operaciones comprueban, actualizan, eliminan o agregan ID de transacción en InnoDB de forma coherente o controlada. Estas operaciones requieren un llamada mutex de trx_sys, a la que se le realiza un seguimiento mediante la instrumentación Performance Schema. Las operaciones incluyen la administración del sistema de transacciones cuando se inicia o cierra la base de datos, reversiones, limpiezas de deshacer, acceso de lectura de filas y cargas de grupos de búfer. La carga elevada de la base de datos con un gran número de transacciones da como resultado la aparición frecuente de este evento de espera. Para obtener más información, consulte synch/mutex/innodb/trx_sys_mutex.

El mutex de keycache->cache_lock controla el acceso a la caché de claves de las tablas MyISAM. Si bien Aurora MySQL no permite el uso de tablas MyISAM para almacenar datos persistentes, se utilizan para almacenar tablas temporales internas. Considere la posibilidad de comprobar los contadores con el estado created_tmp_tables o created_tmp_disk_tables, ya que, en determinadas situaciones, las tablas temporales se escriben en el disco cuando ya no caben en la memoria.

El motor adquiere este mutex al abrir o crear un archivo de metadatos de tabla. Cuando este evento de espera se produce con una frecuencia excesiva, el número de tablas que se crean o abren ha aumentado.

El motor adquiere este mutex mientras realiza operaciones tales como reset_size, detach_contents, o bien add_contents en la estructura interna que hace un seguimiento de las tablas abiertas. El mutex sincroniza el acceso al contenido de la lista. Cuando este evento de espera se produce con alta frecuencia, indica un cambio repentino en el conjunto de tablas a las que se había accedido anteriormente. El motor necesita acceder a tablas nuevas o dejar de lado el contexto relacionado con las tablas a las que se ha accedido anteriormente.

El número de tablas que están abriendo las sesiones supera el tamaño de la caché de definiciones de tablas o de la caché abierta de tablas. Aumente el tamaño de estas cachés. Para obtener más información, consulte How MySQL Opens and Closes Tables.

El número de tablas que están abriendo las sesiones supera el tamaño de la caché de definiciones de tablas o de la caché abierta de tablas. Aumente el tamaño de estas cachés. Para obtener más información, consulte How MySQL Opens and Closes Tables.

En este evento de espera, hay subprocesos esperando por un bloqueo de log. Por ejemplo, un subproceso podría esperar a un bloqueo para escribir en el archivo log de consultas lentas.

En este evento de espera, hay un subproceso esperando a adquirir un bloqueo con la intención de efectuar una confirmación en el log binario. La contención de logs binarios se puede producir en las bases de datos cuya velocidad de cambio es muy alta. Según la versión de MySQL, hay algunos bloqueos que se utilizan para proteger la coherencia y durabilidad del log binario. En RDS for MySQL, los registros binarios se utilizan para la replicación y para el proceso de backup automatizado. En Aurora MySQL, los logs binarios no se necesitan para la replicación o las copias de seguridad nativas. Están deshabilitados de forma predeterminada, pero se pueden habilitar y utilizar para la replicación externa o la captura de datos de cambios. Para obtener más información, consulte The Binary Log en la documentación de MySQL.

Si el registro binario está activado, el motor adquiere este mutex cuando imprime métricas de subprocesos de volcado activos en el registro de errores del motor y en el mapa de operaciones interno.

Si el registro binario está activado, el motor adquiere este mutex cuando agrega, elimina o busca en la lista de archivos binlog detrás del último.

Si el registro binario está activado, el motor adquiere este mutex durante las operaciones de caché de E/S binlog de Aurora: asignar, cambiar el tamaño, liberar, escribir, leer, purgar y acceder a la información de la caché. Si este evento se produce con frecuencia, el motor accede a la caché donde se almacenan los eventos binlog. Para reducir los tiempos de espera, reduzca las confirmaciones. Intente agrupar varios estados de cuenta en una sola transacción.

Ha activado el registro binario. Puede haber un alto rendimiento de confirmaciones, muchas transacciones que se comprometen o réplicas que leen binlogs. Considere utilizar instrucciones de varias filas o agrupar estados de cuenta en una transacción. En Aurora, utilice bases de datos globales en lugar de replicación de registros binarios o utilice los parámetros aurora_binlog_*.

El mutex SERVER_THREAD::LOCK_sync se adquiere durante la programación, el procesamiento o el lanzamiento de subprocesos para la escritura de archivos. La ocurrencia excesiva de este evento de espera indica una mayor actividad de escritura en la base de datos.

El motor adquiere el mutex de TABLESPACES:lock durante las siguientes operaciones de espacio de tabla: crear, eliminar, truncar y extender. La ocurrencia excesiva de este evento de espera indica una alta frecuencia de operaciones de espacio de tabla. Un ejemplo es cargar una gran cantidad de datos en la base de datos.

En este evento de espera, hay subprocesos esperando por un rwlock aplicado al diccionario de datos de InnoDB.

En este evento de espera, hay subprocesos manteniendo bloqueos en operaciones del diccionario de datos de InnoDB.

Al mismo tiempo se activan un gran número de declaraciones de lenguaje de control de datos (DCL) simultáneas en el código de lenguaje de definición de datos (DDL). Reduzca la dependencia de la aplicación de los DDL durante la actividad regular de la aplicación.

Un gran número de instrucciones de lenguaje de manipulación de datos (DML) acceden al mismo objeto de base de datos al mismo tiempo. Intente usar instrucciones de varias filas. Además, distribuya la carga de trabajo sobre distintos objetos de base de datos. Por ejemplo, implementar particiones.

Al mismo tiempo se activan un gran número de declaraciones de lenguaje de control de datos (DCL) simultáneas en el código de lenguaje de definición de datos (DDL). Reduzca la dependencia de la aplicación de los DDL durante la actividad regular de la aplicación.

Al mismo tiempo se activan un gran número de declaraciones de lenguaje de control de datos (DCL) simultáneas en el código de lenguaje de definición de datos (DDL). Reduzca la dependencia de la aplicación de los DDL durante la actividad regular de la aplicación.

La sesión no ha encontrado páginas del grupo de búferes. El motor necesita leer un archivo o modificar la lista menos usada recientemente (LRU) para el grupo de búferes. Considere aumentar el tamaño de la caché del búfer y mejorar las rutas de acceso para las consultas pertinentes.

Muchas instrucciones de lenguaje de manipulación de datos (DML) acceden al mismo objeto de base de datos al mismo tiempo. Intente usar instrucciones de varias filas. Además, distribuya la carga de trabajo sobre distintos objetos de base de datos. Por ejemplo, implementar particiones.