Analizando cargas de trabajo de Amazon RDS con Performance Insigths

Por Kyle Hailey, Product Manager para Performance Insights

AWS anunció recientemente la disponibilidad general de Amazon Aurora con compatibilidad con PostgreSQL. Con esta versión, AWS también ha incluido la primera versión de una función útil en Amazon Relational Database Service (Amazon RDS) denominada Performance Insights. Con el uso de un tablero (dashboard) que visualiza la carga trabajo de la base de datos – junto con las sentencias SQL que causan la carga y por qué – Performance Insights facilita la detección de problemas de rendimiento tanto para usuarios expertos como para no-expertos.

Debido a que recopila datos de rendimiento mediante métodos ligeros, Performance Insights no afecta al rendimiento de sus aplicaciones. Tampoco requiere configuración ni mantenimiento, y actualmente está disponible como una vista previa gratuita con Amazon Aurora PostgreSQL. Performance Insights está habilitado de forma predeterminada para las instancias que cree en la cónsola de administración de AWS. Puede habilitarlo para otras instancias de la cónsola seleccionando Modificar (Modify) en el menú Acciones de instancias (Instance actions). O también puede utilizar el parámetro EnablePerformanceInsights de los métodos de la API CreateDBInstance o ModifyDBInstance.

Comenzar es fácil. Simplemente inicie sesión en la cónsola de Amazon RDS y vaya al tablero de Performance Insights para empezar a monitorear el rendimiento de sus instancias RDS con un solo clic.

Accediendo a Performance Insights
Usted puede acceder a Performance Insights a través de la cónsola de Amazon RDS en dos sitios:

• Elija Performance Insights en el panel de navegación izquierdo para abrir el tablero y ver la lista de instancias de base de datos que tienen habilitada Performance Insights.
• Elija el link debajo del rótulo “actividad actual” (current activity) de una instancia de base de datos para abrir el tablero Performance Insights de esa instancia de base de datos. Las instancias que tienen habilitada Performance Insights muestran la actividad actual medida en sesiones (sessions).

¿Por qué Performance Insights mide la carga de trabajo de bases de datos en sesiones?

Sesiones, en este caso, es la forma abreviada de “promedio de sesiones activas”, a veces abreviado como “AAS”. Una sesión activa es una conexión de base de datos que ha enviado una solicitud a la base de datos pero aún no ha recibido la respuesta. La medición del número promedio de sesiones simultáneas activas a lo largo del tiempo proporciona una imagen clara de la carga de trabajo en la base de datos

En la lista de instancias de base de datos, una barra en la columna Actividad Actual (Current Activity) muestra la carga de la base de datos de cada instancia que tiene habilitada Performance Insights. Un rectángulo vacío con un borde azul indica una instancia inactiva. La línea roja vertical indica la capacidad del servidor. A medida que aumenta la carga de la base de datos, la barra se rellena de azul. Cuando la carga supera la capacidad del servidor, el relleno cambia a rojo.

Por lo tanto, siempre que haya rojo en la barra, significa que la instancia de base de datos está saturada y debe consultar el tablero Performance Insights para entender por qué. En el siguiente ejemplo, una instancia de Aurora se muestra en rojo en la barra Actividad Actual. Esto indica que la instancia de base de datos está sometida a una carga pesada. Puede darse cuenta de que esta instancia tiene habilitada Performance Insights, porque la Actividad Actual se expresa en Sesiones. Al elegir la barra se abre el tablero Performance Insights.

El Tablero de Performance Insights

El tablero está dividido en dos partes:

• En la parte superior, un gráfico de carga muestra el historial reciente de carga de la base de datos en unidades de sesiones activas promedio (AAS).
• En la parte inferior, una tabla de actividades más significativas muestra lo que contribuye a la carga de la base de datos durante el intervalo de tiempo en el gráfico de carga.

De forma predeterminada, el gráfico de carga está codificado por colores según el tipo de espera. Desglosar la carga de la base de datos por tipos de espera puede ayudarle a comprender qué tipo de mecanismos de base de datos están contribuyendo principalmente a la carga de trabajo en el servidor. La lista “actividad principal” muestra las sentencias SQL de forma predeterminada. Comprender qué sentencias SQL contribuyen principalmente a la carga de trabajo del servidor puede ayudarlo a comprender qué partes de su aplicación son responsables de los cuellos de botella.

Base de Datos Inactiva

Una base de datos que está completamente inactiva no tiene sesiones activas y, por tanto, no tiene carga. Aunque parezca obvio, saber que una base de datos está inactiva puede ayudar a diagnosticar problemas. Por ejemplo, si una base de datos está inactiva, es probable que los problemas de rendimiento que puedan existir no estén causados por la base de datos. Con el tablero Performance Insights, es fácil determinar si un problema de rendimiento está dentro de la base de datos o fuera de la base de datos, quizás en otra capa o componente de la aplicación.

El siguiente ejemplo ilustra una base de datos inactiva.

Optimizando un cuello de botella de la base de datos

Una sesión es la terminología de base de datos para una conexión de base de datos que sirve una aplicación. Las sesiones que esperan por la ejecución de solicitudes de base de datos contribuyen a la carga de trabajo de la base de datos. Una sesión puede esperar respuesta por muchos motivos. Una razón común es que la solicitud se está ejecutando y utilizando ciclos de CPU para completarse. Sin embargo, la solicitud también podría estar esperando a que se complete una operación de Entrada/Salida (I/O), un bloqueo, escrituras en el almacenamiento, espacio en un área de búfer o por cualquier otra razón. Estos distintos estados de espera aparecen en el gráfico de carga como áreas de color apiladas. Los colores corresponden a los estados de espera que se pueden ver en la leyenda del lado derecho. Los colores más destacados en el gráfico de carga son los que más contribuyen a la carga de trabajo de la base de datos.

Una señal visual importante en el gráfico de carga es la línea de CPU máxima (Max CPU). Esta línea representa la cantidad de vCPUs (unidades de procesamiento central virtual) en el servidor. Si hay más sesiones activas en espera de CPU que vCPUs, significa que la instancia se está ejecutando por encima de la capacidad de la CPU. Siempre que la carga total supere la línea de CPU máxima, puede haber un cuello de botella. El cuello de botella puede deberse a la saturación del CPU, o puede deberse a una de las muchas otras formas en que las sesiones esperan en una base de datos.

Cuello de Botella en el CPU

En los ejemplos anteriores, hay dos núcleos de vCPU, por lo que solo dos sesiones se pueden ejecutar simultáneamente en la CPU sin ponerse en cola. Si tres sesiones se ejecutan en la CPU simultáneamente, entonces, en un momento dado, al menos una de ellas espera en la cola de ejecución y, por lo tanto, no realiza el trabajo que tiene asignado.

En el siguiente ejemplo, la carga de la base de datos ha aumentado mucho por encima de la línea de CPU máxima (Max CPU). La pregunta es: ¿Qué está causando este cuello de botella? Puede hacer zoom en el cuello de botella haciendo clic y arrastrando (consulte el área azul claro en el siguiente gráfico), para seleccionar el área que le interesa.

En el siguiente ejemplo, hemos ampliado (hecho zoom sobre) el área seleccionada.

En este caso, el cuello de botella está en el CPU, ya que el verde (CPU) es el color dominante de las sesiones activas. La demanda de CPU está por encima de la capacidad de CPU disponible que se muestra en la línea de CPU máxima (Max CPU). Para abordar este problema, tiene dos opciones. Puede escalar a un tipo de instancia más grande con más CPU o puede reducir la carga en la instancia actual. Si bien la ampliación a un tipo de instancia más grande es una opción, por lo general requiere discusión y programación, y puede aumentar los costos. A menudo, una solución más directa es optimizar la carga de trabajo en el sistema actual.

Para optimizar el sistema en el ejemplo anterior, la pregunta es: ¿Qué ajustamos? La tabla de actividades, debajo del gráfico de carga, puede ayudarte a responder a eso. Con la pestaña SQL seleccionada (por defecto), esta tabla muestra qué sentencias contribuyen más a la carga de trabajo en el servidor y, por lo tanto, son buenas candidatas para el ajuste. En este caso, una sentencia SQL es el principal contribuyente a la carga de trabajo y también es el contribuyente predominante a la espera del CPU. Es evidente que la función minute_rollups() es responsable de la carga del CPU en esta base de datos. Podría valer la pena dedicar un esfuerzo a reducir el uso de CPU de esta función almacenada.

Cuellos de botella generados por “esperas”

En el ejemplo anterior, puede ver que poco tiempo después, en la misma base de datos, aparece un nuevo cuello de botella como un pico naranja claro. De nuevo, puedes hacer clic y arrastrar para ampliar sobre ese nuevo cuello de botella.

En lugar de CPU, este pico consiste principalmente en el evento de espera IO:XactSync. Para obtener más información sobre esta espera, detenga el cursor sobre los elementos de la leyenda y aparecerá información sobre los eventos de espera. A partir de esta información, puede aprender que IO:XactSync ocurre cuando una sesión está esperando escrituras en un almacenamiento estable. Cuando observas la lista de sentencias SQL más importantes, ves que, por mucho, el mayor contribuyente a este estado de espera es una sentencia “insert”.

De forma predeterminada, en PostgreSQL, inserciones de un solo registro se ejecutan con un commit automático (auto-commit). Esto significa que la base de datos debe esperar la durabilidad (escritura en el almacenamiento) para completar cada inserción. Para mejorar el rendimiento, PostgreSQL admite inserciones de varios registros y deshabilitar commit automático (auto-commit).

Utilizando Performance Insights para dimensionar un servidor de bases de datos

Performance Insights puede ayudar con el dimensionamiento de una instancia de base de datos. En el siguiente ejemplo, la carga de la base de datos está muy por debajo de Max CPU. Si este es el patrón usual, es posible que la base de datos esté alojada en un tipo de instancia más grande de lo necesario y se podría reducir.

Por otro lado, si la carga de trabajo de la base de datos supera regularmente Max CPU y la carga de trabajo no se puede ajustar más, es posible que el tipo de instancia sea demasiado pequeño. En el siguiente ejemplo, la carga de trabajo de la base de datos supera continuamente Max CPU.

Explorando otras dimensiones

Tanto el gráfico de carga de trabajo como la tabla de actividades del panel pueden mostrar dimensiones distintas de las que se muestran de forma predeterminada (esperas y SQL).

La leyenda del gráfico de carga de trabajo tiene un selector para elegir la dimensión por la que desea desglosar el gráfico. Para Aurora PostgreSQL, Performance Insights actualmente admite el desglose por esperas, SQL, servidores, y usuarios.

La lista de actividades principales puede desglosarse por cualquiera de las dimensiones indicadas en la parte superior de la lista. Para Aurora PostgreSQL, Performance Insights actualmente admite desglosar las principales actividades por SQL, esperas, servidores, y usuarios.

En la imagen anterior, la lista de actividades principales se ha agrupado por Servidores (Hosts), lo que muestra la carga de trabajo que viene de cada máquina cliente desde la que se ejecutan las sentencias SQL. En este caso, solo hay un servidor generando carga de trabajo en el CPU. Esto podría indicar un problema de implementación. Estos hosts son servidores de aplicaciones, que deben ejecutar el mismo código y presentar perfiles de carga similares.

Para tener una idea de cómo la carga de trabajo de SQL puede ser diferente en estos servidores, elija Desglosar por (Slice by) en la leyenda del gráfico de carga y, a continuación, elija SQL.

Con la carga de trabajo del servidor agrupada por SQL en lugar de esperas, ahora puede ver que 172.31.31.154 es el único servidor ejecutando With CTE as ( SELECT…. Este es el mismo servidor que mostraba asimétricamente la mayor carga de CPU en el ejemplo anterior cuando la carga del servidor se agrupaba por esperas.

También puede ver que este mismo servidor, 172.31.18.90, es el único ejecutando INSERT INTO authors… Y además, que este parece ser el único SQL que está ejecutando. Es importante comprender cómo la carga de trabajo en la capa de aplicaciones y la carga de trabajo en la capa de base de datos se distribuyen asimétricamente en una flota de servidores de aplicaciones, ya que puede ayudarlo a diagnosticar problemas de rendimiento general de la aplicación.

De forma predeterminada, el panel muestra la carga de trabajo por esperas y la actividad principal por SQL. Esta es la combinación más útil para uso general.

Sumario

Performance Insights identifica rápida y fácilmente los cuellos de botella de rendimiento en una instancia de base de datos de Amazon RDS y muestra dónde buscar para abordar esos cuellos de botella. Performance Insights se activa de forma predeterminada al crear la base de datos en la consola o al modificar la instancia de base de datos. Está completamente automatizado y la sobrecarga es de aproximadamente el 1 por ciento de un núcleo de vCPU. Todo el almacenamiento, el procesamiento, y la agregación de datos se administran automáticamente y se realizan fuera del servidor de la base de datos y no tienen ningún impacto en la base de datos que se monitorea.

Amazon RDS Performance Insights está disponible ahora en todos los motores de bases de datos soportados por Amazon RDS.

Acerca del autor

Kyle Hailey es un Product Manager para Performance Insights en Amazon Web Services.

Traductor

Camilo Leon es un Arquitecto de Soluciones Principal especializado en bases de datos en Amazon Web Services radicado en San Francisco. Camilo Trabaja con clientes de AWS para proporcionar orientación y asistencia técnica en servicios de bases de datos relacionales, ayudándoles a mejorar el valor de sus soluciones cuando utilizan AWS.