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 clave para ajustar el rendimiento de las bases de datos
DevOpsGuru for RDS supone que está familiarizado con algunos conceptos clave de rendimiento. Para más información sobre estos conceptos, consulte Overview of Performance Insights (Visión general de información sobre rendimiento) en la Guía del Usuario de Amazon Aurora o Overview of Performance Insights en la Guía del Usuario de Amazon RDS.
Métricas
Una métrica representa un conjunto de puntos de datos ordenados por tiempo. Una métrica es una variable que hay que monitorizar y los puntos de datos son los valores de esa variable a lo largo del tiempo. Amazon RDS proporciona métricas en tiempo real para la base de datos y para el sistema operativo (SO) en el que se ejecuta su instancia de base de datos. Puede ver todas las métricas del sistema y la información de procesos de sus instancias de base de datos de Amazon RDS en la consola de Amazon RDS. DevOpsGuru for RDS monitorea y proporciona información sobre algunas de estas métricas. Para obtener más información, consulte Monitoring metrics in an Amazon Aurora cluster (Supervisión de métricas en un clúster de Amazon Aurora) o Monitoring metrics in an Amazon Relational Database Service instance (Supervisión de métricas en una instancia del servicio de la base de datos relacional de Amazon).
Detección de problemas
DevOpsGuru for RDS emplea métricas de bases de datos y sistemas operativos (OS) para detectar problemas críticos de rendimiento de las bases de datos, ya sean inminentes o continuos. Existen dos formas principales en las que funciona la detección de problemas de DevOps Guru for RDS:
Uso de umbrales
Uso de anomalías
Detectar problemas con los umbrales
Los umbrales son los valores límite con los que se evalúan las métricas monitorizadas. Puede pensar en un umbral como una línea horizontal en un gráfico métrico que separa el comportamiento normal del comportamiento potencialmente problemático. DevOpsGuru for RDS monitorea métricas específicas y crea umbrales analizando qué niveles se consideran potencialmente problemáticos para un recurso específico. DevOpsLuego, Guru for RDS crea información en la consola de DevOps Guru cuando los nuevos valores de las métricas cruzan un umbral específico durante un período de tiempo determinado de forma constante. El resultado de información contiene recomendaciones para evitar que el rendimiento de las bases de datos se vea afectado en el futuro.
Por ejemplo, DevOps Guru para RDS podría supervisar el número de tablas temporales que utilizan el disco durante un período de 15 minutos y obtener una idea cuando la tasa de tablas temporales que utilizan disco por segundo es anormalmente alta. El aumento de los niveles de uso de las tablas temporales en el disco podría afectar al rendimiento de la base de datos. Al exponer esta situación antes de que se vuelva crítica, DevOps Guru for RDS le ayuda a tomar medidas correctivas para evitar problemas.
Detección de problemas con anomalías
Si bien los umbrales proporcionan una forma sencilla y eficaz de detectar problemas en las bases de datos, en algunas situaciones no son suficientes. Pensemos en un caso en el que los valores de las métricas se disparan y se convierten en comportamientos potencialmente problemáticos de forma regular debido a un proceso conocido, como un trabajo diario de elaboración de informes. Dado que estos picos son de esperar, la creación de información y notificaciones para cada uno de ellos sería contraproducente y probablemente conduciría a la fatiga de alerta.
Sin embargo, aún es necesario detectar picos muy inusuales, ya que las métricas que son mucho más altas que las demás o que duran mucho más tiempo podrían representar problemas reales de rendimiento de las bases de datos. Para solucionar este problema, DevOps Guru for RDS monitorea determinadas métricas para detectar cuándo el comportamiento de una métrica se vuelve muy inusual o anómalo. DevOpsA continuación, Guru informa sobre estas anomalías en Insights.
Por ejemplo, DevOps Guru for RDS puede generar información cuando la carga de la base de datos no solo es alta, sino que también se desvía considerablemente de su comportamiento habitual, lo que indica una ralentización importante e inesperada de las operaciones de la base de datos. Al reconocer únicamente los picos anómalos de carga de la base de datos, DevOps Guru for RDS le permite centrarse en las cuestiones que son realmente importantes.
Carga de la base de datos
El concepto clave para el ajuste de la base de datos es la métrica de carga de la base de datos (carga de la base de datos). La carga de la base de datos representa el grado de ocupación de la base de datos en un momento específico. Un aumento en la carga de la base de datos significa un aumento en la actividad de la base de datos.
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 sesión que está en proceso de ejecutar una solicitud de base de datos. 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 en la memoria y, a continuación, consumir CPU mientras lee los datos de la página.
La métrica DBLoad en Información sobre Rendimiento se mide en promedio de sesiones activas (AAS). Para calcular el AAS, Información sobre Rendimiento hace un muestreo del número de sesiones activas por segundo. El AAS es el total del número de sesiones activas dividido entre el total del número de muestras para un periodo específico. Un valor de AAS de 2 significa que, en promedio, 2 sesiones han estado activas en las solicitudes en un momento dado.
Una analogía para la carga de base de datos es la actividad en un almacén. Supongamos que el almacén da trabajo a 100 empleados. Si entra 1 pedido, 1 empleado cumple el pedido mientras los demás empleados están inactivos. Si entran 100 pedidos, los 100 empleados llevan a cabo los pedidos simultáneamente. Si hace un muestreo periódico de cuántos empleados están activos durante un plazo determinado, puede calcular el número medio de empleados activos. El cálculo muestra que, en promedio, N empleados están ocupados cumpliendo pedidos en un momento dado. Si el promedio fue de 50 empleados ayer y 75 empleados hoy, aumentó el nivel de actividad en el almacén. Del mismo modo, la carga de base de datos aumenta a medida que aumenta la actividad de la sesión.
Para obtener más información, consulte Carga de la base de datos en la Guía del Usuario de Amazon Aurora o Carga de la base de datos en la Guía del Usuario de Amazon RDS.
Eventos de espera
Un evento de espera es un tipo de instrumentación de base de datos que indica qué recurso está esperando una sesión de base de datos para poder continuar. Cuando Información sobre Rendimiento cuenta las sesiones activas para calcular la carga de la base de datos, también registra los eventos de espera que hacen que las sesiones activas esperen. Esta técnica permite a Información sobre Rendimiento mostrarle qué eventos de espera contribuyen a la carga de la base de datos.
Cada sesión activa se ejecuta en la CPU o en espera. Por ejemplo, las sesiones consumen CPU cuando buscan memoria, 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 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 % 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 solucionar el problema.
Considere la analogía de un empleado de almacén. Recibe un pedido de un libro. Es posible que el empleado se demore en la tramitación del pedido. Por ejemplo, puede ser que otro empleado abastezca los estantes o que no haya un carro disponible. O bien, puede que el sistema utilizado para ingresar el estado del pedido sea lento. Cuanto más espere el empleado, más tardará en cumplir el pedido. La espera es una parte natural del flujo de trabajo del almacén, pero si el tiempo de espera es excesivo, la productividad disminuye. Del mismo modo, las esperas de sesión repetidas o prolongadas pueden degradar el rendimiento de la base de datos.
Para obtener más información acerca de eventos de espera, consulte Ajuste con eventos de espera de Aurora PostgreSQL y Ajuste con eventos de espera de Aurora MySQL en la Guía del Usuario de Amazon Aurora.
Para más información sobre los eventos de espera en otras bases de datos de Amazon RDS, consulte Cómo ajustar los eventos de espera para RDS para PostgreSQL en la Guía del Usuario de Amazon RDS.
