Databases, Flash Storage: no siempre mayor rendimiento (es)

Questo post è anche disponibile in italiano

Es difícil leer un artículo que diga; el uso de tecnología flash en ambientes de bases de datos relacionales puede no comportar algún beneficio del punto de vista del rendimiento. Es común orientarse a tecnologías All Flash porque estas proporcionan ambientes de mayor eficiencia: facilidad de uso, reducción de datos gracias a mecanismos de compresión y/o deduplica y menores costes de manutención.  Sin embargo, casi siempre, el “driver” principal en la adopción de una tecnología flash es el de obtener notables aumentos de performance.

En este post veremos cómo esta última común presunción puede no ser siempre cierta. Usando Oracle como ejemplo de base de datos relacional, analizaremos algunos conceptos relacionados con el “tuning” a través del AWR con el objetivo de obtener el conocimiento básico que nos permita de determinar cuándo un DB puede NO obtener beneficios de rendimiento en una plataforma All Flash.

AWR 101 para un especialista storage

El utilitario de informes Oracle AWR (Automatic Workload Repository) proporciona una visión general del rendimiento de la base de datos en un determinado tiempo, creando “snapshots” o muestras de datos de performance a intervalos que pueden ser definidos (default 1 hora). AWR utiliza un “time modelling” donde se evidencian las siguientes variables:

Elapsed time es la cantidad de minutos desde el snap inicial al final.

Elapsed time = DB time + Idle time. El elapsed time comprende el DB time o tiempo en que la base de datos está ejecutando una instrucción SQL para una sesión y el Idle Time o el tiempo en que la base de datos está activa pero no hay aplicaciones conectadas, o todas las sesiones conectadas están inactivas.

DB Time = DB CPU + Wait Time. El DB Time comprende el DB CPU y el wait time. DB CPU es el “wall-clock-time” que un proceso de una instancia Oracle está en la CPU.

El “wall-clock-time” es la suma de tres términos; tiempo de CPU + tiempo de I/O + el retardo de comunicación en el canal, por ejemplo, si los datos se transmiten a través de múltiples máquinas.  A diferencia del tiempo de CPU, que mide sólo el tiempo durante el cual el procesador está trabajando activamente en una tarea, el “wall-clock-time ” mide el tiempo total para completar el proceso. La diferencia entre los dos es el tiempo debido a retrasos programados o en espera de recursos que tienen que estar disponibles, en nuestro caso, nos referimos al componente de almacenamiento de datos (storage).

db-and-flash-performance-awr101
db-and-flash-performance-awr101

El “wall-clock-time” se refiere al tiempo efectivo necesario para completar una determinada tarea.  El wait time es lo opuesto a DB CPU. Cualquier evento que hace que un procesamiento SQL activo no esté en la CPU es un evento de espera. Oracle categoriza en modo claro los eventos de wait en diferentes clases. En particular, para el análisis de performance y sus impactos a nivel del sistema de almacenamiento de datos, las clases que más interesan son user I/O y commit. User I/O wait es el tiempo que los procesos de la sesión están bloqueados mientras esperan que se completen las operaciones de I/O. Claramente, valores altos en esta clase de wait impactan el rendimiento de general de la aplicación. La tecnología flash es en grado de disminuir estos valores de wait aumentando de este modo el rendimiento. Contrariamente, valores de user I/O wait de pocos milisegundos significa que la sola implementación de discos flash non proporcionará grandes beneficios de performance.

Para un especialista storage es útil comenzar el análisis del AWR desde la sección o tabla Top 5 Timed Foreground Events. En esta tabla Oracle organiza los eventos en clases. La suma (expresada en %time) de las clases user I/O + commit representan el tiempo total que los procesos son en wait por el sistema de almacenamiento.

Por ejemplo, en la tabla siguiente podemos observar que sobre el tiempo total (% DB Time), solo por el 33% de este tiempo los procesos están en DB CPU, o sea el DB está desarrollando trabajo. En este ejemplo, durante el tiempo restante el DB está en wait por el sistema de almacenamiento (clases User I/O y Commit). Un AWR de este tipo es un clara indicación que este entorno obtendrá beneficios de performance con la adopción de una tecnología All Flash.

db-and-flash-performance-timed-foreground-events
db-and-flash-performance-timed-foreground-events
No todas las cargas de trabajos benefician de un sistema de almacenamiento All Flash.

Recordemos que todo lo que impide a un proceso SQL activo de “estar” en la CPU es un evento de wait. El objetivo es lograr que la diferencia entre DB CPU y DB Time sea el menor posible. Cuando el DB Time = DB CPU el único modo de aumentar el rendimiento es utilizar CPU más veloces.

Se podría pensar que monitoreando el uso de las CPU a nivel de los servidores esto podría dar una indicación de “cuanto bien” está trabajando el DB.

Sin embargo, este análisis por si solo puede llevar a conclusiones erradas. Veamos el ejemplo siguiente: la aplicación presenta tiempos de respuesta elevados y por este motivo se piensa a un upgrade tecnológico con un storage de tipo All Flash para mejorar el rendimiento. El objetivo es obtener el “menor” tiempo de respuesta posible.

Como procedimiento para definir el upgrade tecnológico, utilizamos el razonamiento “El workload define la arquitectura”, en línea con la metodología del FlashSessment, ver:  Architecturas de almacenamiento storage y cargas de trabajo

db-and-flash-performance-workload-characterization
db-and-flash-performance-workload-characterization

A través del FlashSessment sabemos que la aplicación en objeto es una aplicación Oracle y notamos en los AWR que se trata de una carga de trabajo que pasa gran parte de su tiempo en la CPU.

db-and-flash-performance-load-profile
db-and-flash-performance-load-profile

La diferencia de tiempo entre DB Time / DB CPU es muy, muy pequeña. Esto significa que la aplicación se ejecuta ya lo más rápidamente posible que permiten las CPU del host.

Monitoreando las CPU del host se espera de encontrar que esta aplicación es de tipo CPU bound, o sea que utiliza todos los recursos disponibles del host (CPU) y por lo tanto no es en grado de ulteriores aumentos de rendimiento. Sin embargo, en este caso, las CPU del servidor no están al 100% de uso. Qué significa? Existen dos conceptos que es útil conocer para entender una situación de este tipo.

Host CPU bound vs DB saturated workload

Normalmente en los actuales sistemas multi-CPU y multi-core es una práctica común asignar un cierto número de cores a una aplicación.  De este modo parte de la capacidad de elaboración del servidor se dedica al DB y parte a otros procesos no relacionados al DB. En estos casos, cuando observamos a nivel del servidor el uso de la CPU, puede que notemos que el sistema no se encuentra en una situación de Host CPU bound (100% de uso) y por lo tanto esto induce a pensar que el problema de no obtener un buen rendimiento es debido a “otras causas”. Estas otras causas apuntan muchas veces sistema de almacenamiento.

db-and-flash-performance-db-cpu-concepts
db-and-flash-performance-db-cpu-concepts

Un ejemplo nos permitirá de entender el concepto de DB saturated workload.

En la siguiente figura, siempre proveniente del AWR, podemos notar el número de cores dedicados a la aplicación.

db-and-flash-performance-host-environment
db-and-flash-performance-host-environment

Esta aplicación utiliza 6 sockets, con un número de 39 cores para un total de 312 CPU threads en un server Solaris M6. Estos servidores tienen 12 cores con 8 threads / 6 sockets lo que hace un total de 576 threads. De este total, 312 están dedicados al DB mientras los restantes 264 threads se utilizan para hacer otros trabajos. Si estos otros threads se utilizan para hacer un trabajo intensivo entonces los 312 threads potencialmente comparten una sobrecarga lo que hace que las CPU sean menos eficaces para ejecutar el workload de la aplicación.

No hay “eventos” de tipo I/O (User I/O, última columna) que indiquen problemas lado “discos”

db-and-flash-performance-10-foreground-events
db-and-flash-performance-10-foreground-events

Para concluir este ejemplo podemos decir que la aplicación no es CPU saturated (el servidor tiene recursos) pero es DB workload saturated (el número de recursos del DB están saturados), una distinción importante que pasa a veces desapercibida.

Sin cambios adicionales que ayuden al paralelismo (DOP PQO) o SQL tuning para usar menos CPU, o sin dedicar más trheads, el sistema actualmente tiene el mayor rendimiento posible que permite el entorno.

db-and-flash-performance-flash-assessments
db-and-flash-performance-flash-assessments

Sin un estudio previo del real comportamiento de la aplicación, un “tech refresh” hubiese llevado a la compra de una solución All Flash probablemente con características de capacidad similares al actual sistema de almacenamiento, pero que dada las características del workload en estudio, habría dado ganancias de rendimiento mínimas.

Resumiendo

Un centro de datos moderno aprovecha la tecnología flash en la mayoría de las arquitecturas posibles. El flash normalmente está asociado a un aumento del rendimiento a nivel de las aplicaciones y por lo tanto, a la cantidad de trabajo se puede hacer en una determinada unidad de tiempo.

El aumento en el rendimiento es quizás el aspecto más evidente de la tecnología flash y por este motivo se piensa que su adopción implica siempre un aumento “automático” de rendimiento. Sin embargo, si se considera solo el rendimiento, NO todos los workloads pueden beneficiar de una solución All Flash.

A menudo, caracterizar la arquitectura flash necesaria para el entorno y los beneficios de rendimiento que esta puede aportar, sobre todo en entornos complejos, no es una tarea fácil. Por este motivo, Dell EMC ha diseñado un proceso, un “assessment”, ver:  Evaluación de la infraestructura de TI  que, en forma sencilla, nos permite de identificar el medio ambiente que mejor se adapta a las necesidades de negocio en examen y ofrece además, información sobre las ventajas que la solución propuesta tendrá con respecto a la actual.

 

db-and-flash-performance-big-picture
db-and-flash-performance-big-picture

 


Para mayor información:

Sistemas de Almacenamiento Dell EMC All Flash

#IWork4Dell

 

Este post también está disponible en: Italiano (Italiano)