Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Conceptos de Información sobre rendimiento
Sesiones activas promedio
La carga de base de datos mide el nivel de actividad en la base de datos. La métrica clave en Información sobre rendimiento es DB Load
, que se recopila cada segundo. La unidad para la métrica DBLoad
es el promedio de sesiones activas (AAS) de la instancia de Amazon DocumentDB.
Una sesión activa es una conexión que ha enviado trabajo a la instancia de Amazon DocumentDB y está esperando una respuesta. Por ejemplo, si envía una consulta a una instancia de Amazon DocumentDB, la sesión de base de datos estará activa mientras el motor de base de datos procesa la consulta.
Para obtener un promedio de sesiones activas, la Información sobre rendimiento muestrea el número de sesiones que ejecutan una consulta al mismo tiempo. El AAS es el total del número de sesiones dividido entre el total del número de muestras. En la tabla siguiente se muestran 5 ejemplos consecutivos de una consulta en ejecución.
Ejemplo | Número de sesiones que ejecutan una consulta | AAS | Cálculo |
---|---|---|---|
1 |
2 |
2 |
2 sesiones / 1 muestra |
2 |
0 |
1 |
2 sesiones / 2 muestras |
3 |
4 |
2 |
6 sesiones / 3 muestras |
4 |
0 |
1.5 |
6 sesiones / 4 muestras |
5 |
4 |
2 |
10 sesiones / 5 muestras |
En el ejemplo anterior, la carga de base de datos para el intervalo de tiempo de 1 a 5 es 2 AAS. Un aumento en la carga de base de datos significa que, en promedio, se están ejecutando más sesiones en la base de datos.
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 de las diferentes características de la métrica DB
Load
. Cuando se diagnostican problemas de rendimiento, las dimensiones más útiles son los eventos de espera y top SQL.
estados de espera
Un evento de espera hace que una instrucción de consulta espere a que ocurra un evento específico antes de que pueda continuar ejecutándose. Por ejemplo, una instrucción de consulta podría esperar hasta que se desbloqueara un recurso bloqueado. Al combinar DB Load
con eventos de espera, puede obtener una imagen completa del estado de la sesión. Estos son varios estados de espera de Amazon DocumentDB:
Estado de espera de Amazon DocumentDB | Descripción del estado de espera |
---|---|
Pestillo |
El estado de espera de pestillo se produce cuando la sesión está esperando para paginar el conjunto de búferes. La entrada y salida frecuentes del conjunto de búferes puede producirse con mayor frecuencia cuando el sistema procesa consultas frecuentes de gran tamaño, escanea colecciones o cuando el grupo de búferes es demasiado pequeño para gestionar todo el conjunto de trabajo. |
CPU |
El estado de espera de la CPU se produce cuando la sesión está esperando en la CPU. |
CollectionLock |
El estado de CollectionLock espera se produce cuando la sesión está esperando a que se bloquee la colección. Estos eventos se producen cuando hay operaciones de DDL en la colección. |
DocumentLock |
El estado de DocumentLock espera se produce cuando la sesión está esperando a que se bloquee un documento. Un número elevado de escrituras simultáneas en el mismo documento contribuirá a que haya más estados de DocumentLock espera en ese documento. |
SystemLock |
El estado de SystemLock espera se produce cuando la sesión está en espera en el sistema. Esto puede ocurrir cuando hay consultas frecuentes de larga duración, transacciones de larga duración o mucha simultaneidad en el sistema. |
E/S |
El estado de espera de la E/S se produce cuando la sesión está esperando en la E/S. |
BufferLock |
El estado de BufferLock espera se produce cuando la sesión está esperando a que se bloquee una página compartida del búfer. BufferLockLos estados de espera pueden prolongarse si otros procesos mantienen los cursores abiertos en las páginas solicitadas. |
LowMemThrottle |
El estado de LowMemThrottle espera se produce cuando la sesión está en espera debido a una gran presión de memoria en la instancia de Amazon DocumentDB. Si este estado persiste durante mucho tiempo, considere la posibilidad de escalar verticalmente la instancia para proporcionar memoria adicional. Para obtener más información, consulte Recurso de origen. |
BackgroundActivity |
El estado de BackgroundActivity espera se produce cuando la sesión está en espera de un proceso interno del sistema. |
Otro |
El otro estado de espera es un estado de espera interno. Si este estado persiste durante mucho tiempo, considere la posibilidad de finalizar esta consulta. Para obtener más información, consulte ¿Cómo puedo encontrar y terminar las consultas que tardan mucho en ejecutarse o se bloquean? |
Consultas principales
Mientras que los eventos de espera muestran los cuellos de botella, las consultas principales indican qué consultas están contribuyendo más a la carga de la 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 la base de datos. En este caso, es posible que la carga alta indique un problema con la consulta.
Max vCPU
En el panel, el gráfico de Carga de base de datos recopila, agrega y muestra información de la sesión. Para ver si las sesiones activas superan el máximo de la CPU, observe su relación con la línea Máximo de la CPU virtual. El valor Máximo de la vCPU se determina por el número de núcleos de vCPU (CPU virtual) de la instancia de Amazon DocumentDB.
Si la carga de base de datos suele estar por encima de la línea Máximo de la CPU virtual y el estado de espera principal es CPU, la CPU del sistema está sobrecargada. En este caso, quizá sea conveniente limitar las conexiones con la instancia, ajustar las consultas con una carga de CPU alta o pensar en la posibilidad de usar una clase de instancia de mayor tamaño. Si hay instancias altas y uniformes en cualquier estado de espera, eso indica que es posible que haya problemas de contención de recursos o cuellos de botella que hay que resolver. Esto puede ser así aunque la carga de base de datos no cruce la línea de Máximo de la CPU virtual.