Conceptos esenciales para el ajuste de Aurora MySQL
Antes de ajustar la base de datos Aurora MySQL, asegúrese de saber qué son los eventos de espera y por qué se producen. Revise también la arquitectura de disco y memoria básica de Aurora MySQL cuando utilice el motor de almacenamiento InnoDB. Para obtener un diagrama de arquitectura útil, consulte el Manual de referencia de MySQL
Temas
Eventos de espera de Aurora MySQL
Un evento de espera indica un recurso por el cual una sesión está en espera. Por ejemplo, el evento de espera io/socket/sql/client_connection indica que un subproceso está controlando una nueva conexión. Los recursos típicos por los que espera una sesión son los siguientes:
-
Acceso de subproceso único a un búfer, por ejemplo, cuando una sesión intenta modificar un búfer
-
Una fila bloqueada actualmente por otra sesión
-
Lectura de un archivo de datos
-
Escritura de un archivo de registro
Por ejemplo, para satisfacer una consulta, la sesión podría hacer un escaneo de tabla completo. Si los datos ya no están en la memoria, la sesión espera a que se complete la E/S del disco. Cuando los búferes se leen en la memoria, es posible que la sesión tenga que esperar porque otras sesiones tienen acceso a los mismos búferes. La base de datos registra las esperas mediante un evento de espera predefinido. Estos eventos se agrupan en categorías.
Un evento de espera no muestra por sí solo un problema de rendimiento. Por ejemplo, si los datos solicitados no están en memoria, es necesario leer los datos del disco. Si una sesión bloquea una fila para una actualización, otra sesión espera a que se desbloquee la fila para poder actualizarla. Una confirmación requiere un tiempo de espera para que se complete la escritura en un archivo de registro. Las esperas forman parte del funcionamiento normal de una base de datos.
Un gran número de eventos de espera suele mostrar un problema de rendimiento. En estos casos, se pueden utilizar los datos de los eventos de espera para determinar en qué se gastan las sesiones. Por ejemplo, si un informe que normalmente se ejecuta en minutos ahora se ejecuta durante horas, puede identificar los eventos de espera que más contribuyen al tiempo total de espera. Si puede determinar las causas de los principales eventos de espera, a veces puede hacer cambios que mejoren el rendimiento. Por ejemplo, si la sesión se encuentra a la espera de una fila que ha sido bloqueada por otra sesión, puede terminar la sesión de bloqueo.
Estados del subproceso Aurora MySQL
Un estado de subproceso general es un valor State asociado al procesamiento general de consultas. Por ejemplo, el estado del subproceso sending data indica que un subproceso está leyendo y filtrando filas de una consulta para determinar el conjunto de resultados correcto.
Puede utilizar estados de subprocesos para ajustar Aurora MySQL de forma similar a la forma en que utiliza los eventos de espera. Por ejemplo, apariciones frecuentes de sending data suelen indicar que una consulta no utiliza un índice. Para obtener más información acerca de los estados de los subprocesos, consulte Estados generales de subprocesos
Al utilizar Información sobre rendimiento, se cumple una de las condiciones siguientes:
-
Performance Schema activado: Aurora MySQL muestra los eventos de espera en lugar del estado de subprocesos.
-
Performance Schema desactivado: Aurora MySQL muestra los estados de subprocesos.
Recomendamos configurar Performance Schema para la administración automática. Performance Schema proporciona información adicional y mejores herramientas para investigar posibles problemas de rendimiento. Para obtener más información, consulte Descripción general de Performance Schema para Información de rendimiento en Aurora MySQL.
Memoria de Aurora MySQL
En Aurora MySQL, las áreas de memoria más importantes son el grupo de búferes y el búfer de registro.
Temas
Grupo de búferes
El grupo de búferes es el área de memoria compartida en la que Aurora MySQL almacena en caché los datos de tabla e índice. Las consultas pueden acceder a los datos de uso frecuente directamente desde la memoria sin leer desde el disco.
El grupo de búferes está estructurado como una lista vinculada de páginas. Una página puede contener varias filas. Aurora MySQL utiliza un algoritmo menos usado recientemente (LRU) para determinar cuáles son las páginas del grupo más antiguas.
Para obtener más información, consulte Buffer Pool
Procesos de Aurora MySQL
Aurora MySQL utiliza un modelo de procesos muy diferente del de Aurora PostgreSQL.
Servidor MySQL (mysqld)
El servidor MySQL es un proceso del sistema operativo único denominado mysqld. El servidor MySQL no genera procesos adicionales. Por lo tanto, las bases de datos Aurora MySQL utilizan mysqld para realizar la mayor parte de su trabajo.
Cuando se inicia el servidor MySQL, escucha las conexiones de red de los clientes de MySQL. Cuando un cliente se conecta a la base de datos, mysqld abre un subproceso.
Threads
Los subprocesos del administrador de conexiones asocian cada conexión de cliente con un subproceso dedicado. Este subproceso administra la autenticación, ejecuta instrucciones y devuelve los resultados al cliente. El administrador de conexiones crea nuevos subprocesos cuando es necesario.
La caché de subprocesos es el conjunto de subprocesos disponibles. Cuando finaliza una conexión, MySQL devuelve el subproceso a la caché de subprocesos si esta no está llena. La variable del sistema thread_cache_size determina el tamaño de la caché de subprocesos.
Grupo de subprocesos
El grupo de subprocesos consta de varios grupos de subprocesos. Cada grupo administra un conjunto de conexiones de clientes. Cuando un cliente se conecta a la base de datos, el grupo de subprocesos asigna las conexiones a los grupos de subprocesos de forma rotativa. El grupo de subprocesos separa las conexiones y los subprocesos. No existe una relación fija entre las conexiones y los subprocesos que ejecutan las instrucciones que se reciben de esas conexiones.
