¿Qué diablos es un DTU?

Autor invitado:Andy Mallon (@AMtwo)

No, en serio. ¿Qué es una DTU?

Cuando implementa cualquier aplicación, una de las primeras preguntas que surge es "¿Cuánto costará esto?" La mayoría de nosotros hemos realizado este tipo de ejercicio para dimensionar una instalación de SQL Server en algún momento, pero ¿qué sucede si está implementando en la nube? Con las implementaciones de IaaS de Azure, no ha cambiado mucho:todavía está construyendo un servidor en función del recuento de CPU, cierta cantidad de memoria y configurando el almacenamiento para brindarle suficientes IOPS para su carga de trabajo. Sin embargo, cuando da el salto a PaaS, Azure SQL Database se dimensiona con diferentes niveles de servicio, donde el rendimiento se mide en DTU. ¿Qué diablos es una DTU?

Sé lo que es un BTU. ¿Quizás DTU significa Unidad Térmica de Base de Datos? ¿Es la cantidad de potencia de procesamiento necesaria para elevar la temperatura del centro de datos en un grado? En lugar de adivinar, consultemos la documentación y veamos qué tiene que decir Microsoft:

Bien, esa fue mi segunda suposición, pero ¿cuál es la "medida combinada"? ¿Cómo puedo traducir lo que sé sobre dimensionar un servidor para dimensionar una base de datos SQL de Azure? Desafortunadamente, no existe una forma sencilla de traducir "2 núcleos de CPU y 4 GB de memoria" en una medida de DTU.

¿No hay una calculadora de DTU?

¡Sí! Microsoft nos proporciona una calculadora de DTU para estimar el nivel de servicio adecuado de Azure SQL Database. Para usarlo, descargue y ejecute un script de PowerShell (sql-perfmon.ps1) en el servidor mientras ejecuta una carga de trabajo en SQL Server. El script genera un CSV que contiene cuatro contadores perfmon:(1) % total de tiempo de procesador, (2) total de lecturas de disco por segundo, (3) total de escrituras de disco por segundo y (4) total de bytes de registro vaciados por segundo. Esta salida CSV luego se carga en la Calculadora de DTU, que estima qué nivel de servicio se adaptará mejor a sus necesidades. Los únicos datos que la calculadora de DTU toma además del CSV es la cantidad de núcleos de CPU en el servidor que generó el archivo. La calculadora de DTU sigue siendo una especie de caja negra:no es fácil mapear lo que sabemos de nuestras bases de datos locales en Azure.

Me gustaría señalar que la definición de una DTU es que es "una medida combinada de CPU, memoria y E/S de datos y E/S de registro de transacciones..." Ninguno de los contadores perfmon utilizados por la calculadora de DTU tiene en cuenta la memoria, pero está claramente enumerada en la definición como parte del cálculo. Esto no es necesariamente un problema, pero es evidencia de que la Calculadora de DTU no va a ser perfecta.

Cargaré algo de carga sintética en la calculadora DTU y veré si puedo averiguar cómo funciona esa caja negra. De hecho, fabricaré los CSV por completo para poder controlar totalmente los números de perfmon que cargamos en la calculadora de DTU. Veamos una métrica a la vez. Para cada métrica, cargaremos 25 minutos (1500 segundos, me gustan los números redondos) de datos fabricados y veremos cómo esos datos de perfmon se convierten en DTU.

CPU

Voy a crear un CSV que simule un servidor de 16 núcleos, incrementando lentamente la utilización de la CPU hasta que esté fijada al 100 %. Dado que voy a simular el aumento en un servidor de 16 núcleos, crearé mi CSV para aumentar 1/16 a la vez, esencialmente simulando un núcleo al máximo, luego un segundo al máximo, luego el tercero, etc. Mientras tanto, el CSV mostrará cero lecturas, escrituras y vaciados de registros. Un servidor nunca generaría una carga de trabajo como esta, pero ese es el punto. Estoy aislando completamente la utilización de la CPU para poder ver cómo afecta la CPU a las DTU.

Crearé un archivo CSV que tiene una fila por segundo y, cada 94 segundos, aumentaré el contador de tiempo total del procesador en un ~6%. Los otros tres contadores serán cero en todos los casos. Ahora, subo este archivo a la Calculadora de DTU (y le digo a la Calculadora de DTU que considere 16 núcleos), y este es el resultado:

¿Esperar? ¿No aumenté la utilización de la CPU en 16 pasos pares? Este gráfico de DTU solo muestra cinco pasos. Debo haberlo hecho mal. No, mi CSV tenía 16 pasos pares, pero eso (aparentemente) no se traduce uniformemente en DTU. Al menos no según la calculadora DTU. Según nuestra prueba de CPU al máximo, nuestra asignación de CPU a DTU a nivel de servicio se vería así:

Observar estos datos nos dice algunas cosas:

1. Un núcleo de CPU, 100 % utilizado equivale a 100 DTU.
2. Las DTU aumentan un poco linealmente a medida que aumenta la CPU, pero aparentemente a trompicones.
3. Los niveles de servicio Básico y Estándar equivalen a menos de un solo núcleo de CPU.
4. Cualquier servidor multinúcleo se traduciría en cierto tamaño dentro del nivel de servicio Premium.

Lecturas

Esta vez, voy a utilizar la misma metodología. Generaré un CSV con números crecientes para el contador de lecturas/segundo, con los otros contadores de perfmon en cero. Poco a poco iré aumentando el número con el tiempo. Esta vez, aumentemos en partes de 2000, cada 100 segundos, hasta llegar a 30000. Esto nos da el mismo tiempo total de 25 minutos; sin embargo, esta vez tengo 15 pasos en lugar de 16. (Me gustan los números redondos).

Cuando subimos este CSV a la calculadora de DTU, nos da este gráfico de DTU:

Espera un segundo... se ve bastante similar al primer gráfico. Nuevamente, está aumentando en 5 incrementos desiguales, a pesar de que tenía 15 pasos pares en mi archivo. Veámoslo en un formato tabular:

Nuevamente, vemos que los niveles Básico y Estándar se superan con bastante rapidez (menos de 2000 lecturas por segundo), pero el nivel Premium es bastante amplio, abarcando de 2000 a 30 000 lecturas por segundo. En la tabla anterior, las "Lecturas/seg" probablemente podrían considerarse como "IOPS"... O, técnicamente, simplemente "OPS" ya que no hay escrituras para constituir la parte de "entrada" de IOPS.

Escribe

Si creamos un CSV usando la misma fórmula que usamos para Lecturas y subimos ese CSV a la Calculadora de DTU, obtendremos un gráfico idéntico al gráfico para Lecturas:

IOPS son IOPS, por lo tanto, ya sea una lectura o una escritura, parece que el cálculo de DTU lo considera por igual. Todo lo que sabemos (o creemos saber) sobre las lecturas parece aplicarse igualmente a las escrituras.

Borrar bytes de registro

Llegamos al último contador de perfmon:bytes de registro vaciados por segundo. Esta es otra medida de IO, pero específica del registro de transacciones de SQL Server. En caso de que aún no se haya dado cuenta, estoy creando estos CSV para que los valores altos se calculen como una base de datos de Azure P15, y luego simplemente divida el valor para dividirlo en pasos iguales. Esta vez, vamos a pasar de 5 millones a 75 millones, en pasos de 5 millones. Como hicimos en todas las pruebas anteriores, los otros contadores de perfmon serán cero. Dado que este contador de perfmon está en bytes por segundo y estamos midiendo en millones, podemos pensar en esto en la unidad con la que nos sentimos más cómodos:Megabytes por segundo.

Subimos este CSV a la calculadora de DTU y obtenemos el siguiente gráfico:

La forma de este gráfico se está volviendo bastante predecible. Excepto que esta vez, avanzamos a través de los niveles un poco más rápido, llegando a P15 después de solo 8 pasos (en comparación con 11 para IO y 12 para CPU). Esto podría llevarlo a pensar:"¡Este va a ser mi cuello de botella más estrecho!" pero yo no estaría tan seguro de eso. ¿Con qué frecuencia genera 75 MB de registro en un segundo? ? Eso es 4,5 GB por minuto . Eso es mucha actividad de la base de datos. Mi carga de trabajo sintética no es necesariamente una carga de trabajo realista.

Combinando todo

Bien, ahora que hemos visto dónde se encuentran algunos de los límites superiores de forma aislada, voy a combinar los datos y ver cómo se comparan cuando la CPU, la E/S y la E/S del registro de transacciones suceden al mismo tiempo, después de todo. , ¿no es así como realmente suceden las cosas?

Para crear este CSV, simplemente tomé los valores existentes que usamos para cada prueba individual anterior y combiné esos valores en un solo CSV, lo que produce este hermoso gráfico:

También produce el mensaje:

Si observa el eje Y, verá que alcanzamos "1,000k" (es decir, 1 millón) de DTU en la marca de 1200 segundos. Eso parece... uhh... ¿mal? Si observamos las pruebas anteriores, la marca de 1200 segundos fue cuando las 4 métricas individuales alcanzaron la marca de 4000 DTU, nivel P15. Tiene sentido que estuviéramos fuera de rango, pero la forma del gráfico no tiene mucho sentido para mí; creo que la calculadora de DTU simplemente levantó las manos y dijo:"Lo que sea, Andy. Es mucho. Es demasiado mucho. Son miles de millones de DTU. Esta carga de trabajo no se ajusta a Azure SQL Database".

OK, entonces, ¿qué sucede antes la marca de 1200 segundos? Reduzcamos el CSV y volvamos a enviarlo a la calculadora con solo los primeros 1200 segundos. Los valores máximos para cada columna son:81 % de CPU (o aproximadamente 13 núcleos al 100 %), 24 000 lecturas/seg, 24 000 escrituras/seg y 60 MB de registro vaciado/seg.

Hola, viejo amigo... Esa forma familiar está de regreso. Este es un resumen de los datos del CSV y lo que estima la calculadora de DTU para el uso total de DTU y el nivel de servicio.

Ahora, veamos cómo se comparan los cálculos de DTU individuales (cuando los evaluamos de forma aislada) con los cálculos de DTU de esta verificación más reciente:

Notará que el cálculo de DTU no es tan simple como sumar sus DTU por separado. Como dice la definición que cité al principio, es una "medida combinada" de esas métricas separadas. La fórmula utilizada para "combinar" es complicada y en realidad no tenemos esa fórmula. Lo que podemos ver es que las estimaciones de la calculadora de DTU son más bajas que la suma de los cálculos de DTU separados.

Asignación de DTU a hardware tradicional

Tomemos los datos de la calculadora de DTU e intentemos hacer algunas conjeturas sobre cómo el hardware tradicional podría asignarse a algunos niveles de Azure SQL Database.

Primero, supongamos que "lecturas/seg" y "escrituras/seg" se traducen directamente a IOPS, sin necesidad de traducción. En segundo lugar, supongamos que la suma de estos dos contadores nos dará nuestro total de IOPS. En tercer lugar, admitamos que no tenemos idea de qué es el uso de la memoria, y no tenemos forma de sacar conclusiones al respecto.

Mientras calculo las especificaciones de hardware, también elegiré un posible tamaño de máquina virtual de Azure que se ajuste a cada configuración de hardware. Hay muchos tamaños de máquinas virtuales de Azure similares, cada uno optimizado para diferentes métricas de rendimiento, pero me he adelantado y he limitado mis selecciones a la serie A y la serie DSv2.

El nivel Básico es increíblemente limitado. Es bueno para uso ocasional/casual, y es una forma económica de "estacionar" su base de datos cuando no la está usando. Pero si está ejecutando una aplicación real, el nivel Básico no funcionará para usted.

El nivel estándar también es bastante limitado, pero para aplicaciones pequeñas, es capaz de satisfacer sus necesidades. Si tiene un servidor de 2 núcleos que ejecuta un puñado de bases de datos, entonces esas bases de datos individualmente podrían encajar en el nivel Estándar. De manera similar, si tiene un servidor con una sola base de datos, que ejecuta 1 núcleo de CPU al 100 % (o 2 núcleos que funcionan al 50 %), probablemente sea suficiente potencia para inclinar la balanza hacia el nivel de servicio Premium-P1.

Si usaría un servidor multinúcleo en las instalaciones (o IaaS), buscaría dentro del nivel de servicio Premium en Azure SQL Database. Solo es cuestión de determinar cuántos caballos de fuerza de CPU y E/S necesita para su carga de trabajo. Su servidor de 2 núcleos y 4 GB probablemente lo lleve a algún lugar alrededor de una base de datos SQL Azure P6. En una carga de trabajo de CPU pura (sin I/O), una base de datos P15 podría manejar 16 núcleos de procesamiento, pero una vez que agrega IO a la mezcla, nada más grande que ~12 núcleos no cabe en Azure SQL Database.

La próxima vez, tomaré algunas cargas de trabajo reales y compararé el rendimiento entre los niveles de servicio. ¿Serán precisas las estimaciones de la calculadora de DTU? Lo averiguaremos.

Sobre el autor