Carga de base de datos
La carga de base de datos mide el nivel de actividad de la sesión en la base de datos. DBLoad es la métrica clave de Información sobre rendimiento y Información sobre rendimiento recopila la carga de la base de datos cada segundo.
Sesiones activas
Una sesión de base de datos representa el diálogo de una aplicación con una base de datos relacional. Una sesión activa es una conexión que ha enviado trabajo al motor de base de datos y está esperando una respuesta.
Una sesión está activa cuando se ejecuta en la CPU o a la espera de que un recurso esté disponible para que pueda continuar. Por ejemplo, una sesión activa puede esperar a que se lea una página (o bloque) en la memoria y, a continuación, consumir CPU mientras lee los datos de la página.
Sesiones activas promedio
El promedio de sesiones activas (AAS) es la unidad para la métrica de DBLoad en Performance Insights. Mide cuántas sesiones están activas simultáneamente en la base de datos.
Cada segundo, Información de rendimiento muestra el número de sesiones que ejecutan una consulta simultáneamente. Para cada sesión activa, Información de rendimiento recopila los siguientes datos:
-
Instrucción SQL
-
Estado de la sesión (en ejecución en la CPU o en espera)
-
Host
-
Usuario que ejecuta el SQL
Información de rendimiento calcula el AAS que se obtiene dividiendo el número total de sesiones entre el número total de ejemplos de un periodo de tiempo específico. Por ejemplo, en la tabla siguiente se muestran 5 ejemplos consecutivos de una consulta en ejecución realizada a intervalos de 1 segundo.
| Ejemplo | Número de sesiones que ejecutan una consulta | AAS | Cálculo |
|---|---|---|---|
| 1 | 2 | 2. | 2 sesiones en total / 1 ejemplo |
| 2 | 0 | 1 | 2 sesiones en total / 2 ejemplos |
| 3 | 4 | 2 | 6 sesiones en total / 3 ejemplos |
| 4 | 0 | 1.5 | 6 sesiones en total / 4 ejemplos |
| 5 | 4 | 2 | 10 sesiones en total / 5 ejemplos |
En el ejemplo anterior, la carga de base de datos para el intervalo de tiempo es de 2 AAS. Esta medición significa que, de media, 2 sesiones han estado activas a la vez durante el plazo en que se han tomado las 5 muestras.
Ejecuciones activas promedio
Las ejecuciones activas promedio (AAE) por segundo están relacionadas con las sesiones activas promedio. Para calcular el AAE, Performance Insights divide el tiempo total de ejecución de una consulta por el intervalo de tiempo. En la tabla siguiente se muestra el cálculo de AAE para la misma consulta de la tabla anterior.
| Tiempo transcurrido (en segundos) | Tiempo total de ejecución (en segundos) | AAE | Cálculo |
|---|---|---|---|
| 60 | 120 | 2 | 120 segundos de ejecución/60 segundos transcurridos |
| 120 | 120 | 1 | 120 segundos de ejecución/120 segundos transcurridos |
| 180 | 380 | 2.11 | 380 segundos de ejecución/180 segundos transcurridos |
| 240 | 380 | 1.58 | 380 segundos de ejecución/240 segundos transcurridos |
| 300 | 600 | 2 | 600 segundos de ejecución/300 segundos transcurridos |
En la mayoría de los casos, el AAS y el AAE de una consulta dan aproximadamente lo mismo. Sin embargo, dado que las entradas de los cálculos son diferentes orígenes de datos, los cálculos suelen variar ligeramente.
Dimensiones
La métrica db.load es distinta de las demás métricas de series temporales porque puede desglosarla en subcomponentes llamados dimensiones. Las dimensiones son una especie de categorías “dividir por” de las diferentes características de la métrica DBLoad.
Cuando se diagnostican problemas de rendimiento, las siguientes dimensiones suelen ser las más útiles:
Para obtener una lista completa de las dimensiones de los motores de Aurora, consulte Carga de base de datos dividida por dimensiones.
Eventos de espera
Un evento de espera hace que una instrucción SQL espere a que ocurra un evento específico antes de que pueda continuar ejecutándose. Los eventos de espera son una dimensión o categoría importante de la carga de base de datos, porque indican dónde se ve obstaculizado el trabajo.
Cada sesión activa se ejecuta en la CPU o en espera. Por ejemplo, las sesiones consumen CPU cuando buscan memoria para un búfer, llevan a cabo un cálculo o ejecutan código de procedimiento. Cuando las sesiones no consumen CPU, pueden estar en espera de que se libere un búfer de memoria, se lea un archivo de datos o se escriba un registro. Cuanto más tiempo espere una sesión por los recursos, menos tiempo se ejecutará en la CPU.
Cuando ajusta una base de datos, a menudo intenta averiguar los recursos que esperan las sesiones. Por ejemplo, dos o tres eventos de espera podrían representar el 90 por ciento de la carga de base de datos. Esta medida significa que, en promedio, las sesiones activas pasan la mayor parte del tiempo en espera de un pequeño número de recursos. Si puede averiguar la causa de estas esperas, puede intentar una solución.
Los eventos de espera varían en función del motor de base de datos:
-
Para ver una lista de los eventos de espera de Aurora MySQL que se utilizan con más frecuencia, consulte Eventos de espera de Aurora MySQL. Para obtener información sobre cómo ajustar con estos eventos de espera, consulte Ajuste de Aurora MySQL.
-
Para obtener más información sobre todos los MySQL, consulte Wait Event Summary Tables (Tablas de resumen de eventos de espera)
en la documentación de MySQL. -
Para ver una lista de los eventos de espera de Aurora PostgreSQL que se utilizan con más frecuencia, consulte Eventos de espera de Amazon Aurora PostgreSQL. Para obtener información sobre cómo ajustar con estos eventos de espera, consulte Ajuste con eventos de espera de Aurora PostgreSQL.
-
Para obtener más información sobre todos los eventos de espera de PostgreSQL, consulte Ecentos de espera de PostgreSQL
en la documentación de PostgreSQL.
SQL principal
Mientras que los eventos de espera muestran los cuellos de botella, la dimensión SQL principal indica qué consultas contribuyen más a la carga de base de datos. Por ejemplo, es posible que, aunque haya muchas consultas ejecutándose actualmente en la base de datos, una de ellas consuma el 99 % de la carga de base de datos. En este caso, es posible que la carga alta indique un problema con la consulta.
De forma predeterminada, en la consola de Performance Insights se muestran las principales consultas SQL que contribuyen a la carga de la base de datos. En la consola se muestran también estadísticas importantes sobre cada instrucción. Para diagnosticar los problemas de rendimiento de una instrucción específica, puede examinar su plan de ejecución.
