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 Amazon RDS, 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 obtener más información sobre todos los eventos de espera de MariaDB y MySQL, consulte Wait Event Summary Tables (Tablas de resumen de eventos de espera)
en la documentación de MySQL. -
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. -
Para obtener más información sobre todos los eventos de espera de Oracle, consulte Descriptions of Wait Events (Descripciones de los eventos de espera)
en la documentación de Oracle. -
Para obtener información sobre todos los eventos de espera de SQL Server, consulte Types of Waits (Tipos de espera)
en la documentación de SQL Server.
nota
Para Oracle, los procesos en segundo plano a veces funcionan sin una instrucción SQL asociada. En estos casos, Performance Insights informa del tipo de proceso en segundo plano concatenado con un punto y coma y la clase de espera asociada a ese proceso en segundo plano. Entre los tipos de procesos en segundo plano se incluyen LGWR, ARC0, PMON, etc.
Por ejemplo, cuando el archivador está realizando E/S, el informe de Performance Insights correspondiente es similar a ARC1:System I/O. Ocasionalmente, también falta el tipo de proceso en segundo plano y Performance Insights solo informa sobre la clase de espera, por ejemplo, :System
I/O.
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.
Planes
Un plan de ejecución, también llamado simplemente plan, es una secuencia de pasos que acceden a los datos. Por ejemplo, un plan para unir las tablas t1 y t2 podría recorrer en bucle todas las filas de t1 y comparar cada fila con una fila de t2. En una base de datos relacional, un optimizador es un código integrado que determina el plan más eficiente para una consulta de SQL.
Para las instancias de base de datos, Información de rendimiento recopila planes de ejecución automáticamente. Para diagnosticar problemas de rendimiento de SQL, examine los planes capturados para consultas de SQL de altos recursos. Los planes muestran cómo la base de datos ha analizado y ha ejecutado consultas.
Para obtener información sobre cómo analizar la carga de la base de datos mediante planes, consulte:
Captura del plan
Cada cinco minutos, Información de rendimiento identifica las consultas que requieren más recursos y captura sus planes. Por lo tanto, no es necesario recopilar ni administrar manualmente una gran cantidad de planes. En su lugar, puede usar la pestaña Top SQL (SQL principal) para centrarse en los planes de las consultas más problemáticas.
nota
Performance Insights no captura planes para consultas cuyo texto supere el límite máximo de texto de consulta recopilable. Para obtener más información, consulte Acceso a más texto SQL en el panel de Performance Insights.
El período de retención de los planes de ejecución es el mismo que el de todos los datos de Performance Insights. La configuración de retención en la capa gratuita es Default (7 days) (Predeterminado [7 días]). Para retener los datos de rendimiento durante más tiempo, especifique de 1 a 24 meses. Para obtener más información acerca de los periodos de retención, consulte Precios y retención de datos de Performance Insights.
Consultas de resumen
La pestaña Top SQL (SQL principal) muestra las consultas de resumen de forma predeterminada. Una consulta de resumen no tiene por sí misma un plan, pero todas las consultas que utilizan valores literales sí tienen planes. Por ejemplo, una consulta de resumen podría incluir el texto WHERE `email`=?. El resumen podría contener dos consultas, una con el texto WHERE email=user1@example.com y otra con WHERE
email=user2@example.com. Cada una de estas consultas literales podría incluir varios planes.
Al seleccionar una consulta de resumen, la consola muestra todos los planes para las instrucciones secundarias del resumen seleccionado. Por lo tanto, no es necesario revisar todas las instrucciones secundarias para encontrar el plan. Es posible que vea planes que no están en la lista mostrada de las 10 principales instrucciones secundarias. La consola muestra los planes de todas las consultas secundarias para las que se han recopilado planes, independientemente de si las consultas se encuentran entre las 10 principales.
