"20,000 IOPS por nodo tienen un buen rendimiento con 5 ms de latencia". Para OLTP: no

La razón para escribir este artículo fue una revisión muy valiosa de cómo probamos VMware vSAN ... CROC. La revisión es digna, pero tiene una frase con la que he estado luchando durante más de una década. Los administradores de almacenamiento, virtualizadores e integradores repiten una y otra vez: "Los retrasos de 5 ms son un excelente indicador". Incluso la cifra de 5 ms durante diez años no cambia. Escuché esto en vivo de administradores altamente respetados no menos de una docena de veces. De menos respetados - docenas, y cuántas veces leo en Internet ... No, no, no. Para cargas OLTP de 5 ms, especialmente porque generalmente se miden, estos son fallas épicas. Tuve que explicar las razones de esto muchas veces, esta vez decidí reunir mis pensamientos en una forma reutilizable.

Debo decir de inmediato que no hay tales errores en el artículo mencionado anteriormente, sino que la frase funcionó como un disparador.

Inicio típico

Todo lo que se describe en este artículo es cierto para los DBMS comunes utilizados para OLTP empresarial típico. Sobre todo, tengo experiencia con MS SQL Server, pero, al menos para PostgeSQL, Oracle y Sybase, muchos puntos y conclusiones también seguirán siendo ciertos.

El DBMS de rendimiento generalmente no está satisfecho con todos. Si hay un DBMS en un sistema grande, y de repente casi siempre está ahí, entonces este DBMS es un cuello de botella. Bueno, o inmediatamente se convertirá en un cuello de botella si comienzas a optimizar todo lo demás. Y así, el cliente llega y dice con voz humana: "¡Ayuda! ¡Ahorre! Pagaron $ NNNNNNNN por el servidor y el almacenamiento, ¡pero la velocidad no aumenta! Ah, y el administrador configuró y el proveedor consultó, pero aún no se mueve". Si los desarrolladores del sistema se ajustan a la definición de Lavrov (podemos hacerlo sin una cita exacta), y los especialistas de operación y mantenimiento "luchan con incidentes al reiniciar el servidor", entonces el problema es a menudo simple y sin pretensiones: no hay índices, consultas torcidas, errores fatales de configuración (sobre los cuales la documentación está en negrita dice "¡no puedes hacer esto!" ), bloqueos excesivos, puntos muertos y otras tonterías simples y claras. Hay muchos de estos casos, la mayoría, pero no todos. Si el sistema, en complejidad o carga, ha cruzado algún límite invisible, morirá de estos problemas o pasará al siguiente nivel.

En este nivel, el servidor ya no está bajo la mesa del director, los discos ya no están dentro del servidor, pero en el sistema de almacenamiento, los desarrolladores conocen los índices y los administradores ya conocen PowerShell, y los gerentes de TI comienzan a decir palabras inteligentes como SLA y RPO / RTO. Una situación interesante surge a este nivel:

• DBMS es un cuello de botella.
• El servidor parece ser suficiente en todos los aspectos.
• El DBMS puede mejorarse aún más mediante programación, pero es difícil (cambiar a licencias más caras o cambiar a la "zona roja de la curva Shipilev" para la optimización)
• El sistema de disco se compra caro y, al parecer, incluso está configurado de alguna manera.

Pero no El cocodrilo no se atrapa, el coco no crece y el rendimiento del sistema es el mismo o inferior que en el servidor anterior. Miro en sys.dm_os_waitsats y veo WRITELOG , PAGEIOLATCH_SH y PAGEIOLATCH_EX en la parte superior, el tiempo de espera promedio es de 5+ ms. Bueno, típico, cho: "Hola, administradores y DBA, aquí tienes un sistema de disco - cuello de botella" y aquí comienza una vieja canción de unos 5 ms:

• Tenemos 5 ms para SLA
• Sí, tenemos un regimiento de 20,000 IOPS
• El vendedor nos dijo que todos los archivos de la base de datos pueden estar en una partición
• Tenemos virtualización e hiperconvergencia y no podemos asignar discos separados bajo la base de datos.
• Según nuestros datos, la utilización del servidor 5%
• Todo está configurado según las recomendaciones.
• Sus bases de datos no necesitan mucho rendimiento, no hacen más de 300 IOPS (y tenemos un estante para 20,000 IOPS)

Por cierto, todo lo anterior, no solo sobre "sus" servidores, sino también sobre los servicios en la nube y la virtualización. Hay un montón de sus propios detalles, pero el cuadro clínico típico es casi el mismo: base de datos moderadamente optimizada, personal inteligente de desarrollo y mantenimiento, hay una reserva para el procesador y la memoria, el "escape" de futuras inversiones es casi cero.

Entonces aquí. Toda esta canción sobre "5 ms" no tiene sentido y tiene sentido. Si usted mismo dice esto, lea este artículo. Y si te dicen esto, prepara los argumentos. Antes, cuando escuché estas palabras, estaba enojado, pero ya no estoy enojado. Yo, como esa olla con una petunia de la Guía del autoestopista galáctico, solo tengo un pensamiento: "Bueno, otra vez ...".

¿Quién tiene la culpa?

¿Por qué la base de datos es tan lenta? Bueno, parece que un servidor típico con 20-64 núcleos a una frecuencia de 2-3 GHz es capaz de realizar operaciones simples de 50-150 mil millones, y las pruebas de base de datos máximas (sintéticas) muestran en tales máquinas solo 10,000-50000 transacciones por segundo. Hey Bueno, esto es de un millón a una docena de posibles millones de transacciones por transacción. No es solo mucho, es mucho sentir.
Tal costo indirecto ACID- requisitos para transacciones.

• Una tomicidad: o se completa la transacción completa o no se completa la totalidad.
• C onstancia: a la entrada y a la salida de una transacción, el sistema está en un estado consistente
• I solation - las transacciones no ven los estados intermedios del otro
• Durabilidad: si la transacción se ha completado con éxito (comprometido), entonces, independientemente de las circunstancias, los cambios realizados deben permanecer en el sistema.

Por cierto, letra por letra, estos requisitos no se cumplen en casi ningún lugar y nunca, sino simplemente en sistemas distribuidos (el teorema CAP interfiere). Para nuestra situación, el requisito "D" es más probable que sea más costoso que otros, este requisito lo proporciona el mecanismo clave de todos los DBMS OLTP comunes: WAL, registro de escritura anticipada (PostgeSQL), también es un registro de transacciones (SQL Server), también conocido como registro REDO (Oracle). Aquí está: una piedra en el cuello de la productividad, y es la base de las transacciones de Durabilidad.

¿Qué es el WAL?

Olvidemos por un momento los SSD modernos, los sistemas de almacenamiento geniales. Supongamos que tenemos un servidor, tiene uno o más discos.
Cualquier transacción, incluso la inserción de un registro, es al menos potencialmente, pero de hecho casi siempre y de manera realista una acción no atómica. Casi siempre necesitamos cambiar no solo la página donde se encuentra el registro, sino también las páginas de índice, posiblemente las páginas de servicio. Además, en la misma transacción, la misma página puede cambiar muchas veces. Además, se pueden realizar otras transacciones en paralelo con nosotros. Además, las transacciones vecinas en el tiempo constantemente "jalan" las mismas páginas. Si esperamos que cada página se escriba en el disco antes de continuar, que es esencialmente lo que Durability requiere, tendremos que escribir muchas veces más y esperar a que se complete cada grabación en medios no volátiles. ¡Sin cachés, sin reorganización de operaciones en la cola, de lo contrario no habrá integridad! Además, de alguna manera tenemos que tener en cuenta qué datos ya están en las transacciones fijas y cuáles no (y qué datos estaban antes). Para entenderlo, un disco duro único típico (HDD) en este modo dará 50-100 IOPS y esto ha sido una constante durante 20 años. Una pequeña transacción requerirá 5-10 operaciones de escritura. Ah, sí, para saber qué grabar, debes leerlo. Incluso los sistemas OLTP muy, muy fuertemente escribibles leen 3 veces más de lo que escriben. Por lo tanto, nuestra transacción cuesta 20-40 IO, lo que significa 0.2-0.8 segundos por disco.
2 transacciones por segundo. ¿No es suficiente? ¿Intentamos dispersar los discos? Ah, pero todavía tenemos que esperar hasta que se grabe el anterior y no haya paralelismo al final. Como ser ¡Y comencemos un archivo de registro en el que registraremos secuencialmente todas las operaciones de escritura en la base de datos y las marcas de transacción! Pros:

• La información sobre la operación puede ser mucho más compacta que registrar toda la página (un tamaño de página típico es de 8 KiB, la información escrita en el registro suele ser de 0,5-1 KiB).
• En lugar de escribir sobre si la transacción se registra o no directamente en la página, hay suficientes etiquetas sobre el comienzo y la fijación de la transacción en el registro.
• Las páginas no se pueden escribir después de cada transacción, varias veces menos. El proceso de lectura / escritura de datos está completamente "desatado" del registro.
• Lo principal Si colocamos nuestro diario en un disco separado y escribimos registros secuencialmente, entonces debido al hecho de que no necesita reposicionar constantemente los cabezales del disco, incluso un HDD doméstico en este modo comprime hasta 1000 IOPS, dado que las pequeñas transacciones "cuestan" 2-4 entradas de diario, entonces puedes exprimir 200-400 TPS
• En caso de falla, el estado del archivo de datos puede restaurarse utilizando dicho registro, y si se cancela una transacción, los cambios pueden revertirse.

Dicho registro se denomina registro de escritura anticipada / registro de transacciones / registro REDO.

¡Hurra! Genial Hubo 2 transacciones por segundo, se convirtió en 300, mejoró 150 veces. ¿Y a qué costo? Como resultado, el precio es significativo:

• En todos los DBMS comunes, el registro es estrictamente consistente. Un hilo es responsable de escribir en el registro. ¿Tienes 100 procesadores? Genial Y el registro seguirá escribiendo un hilo. La profundidad de la cola es exactamente una.
• Aún así, no hay cachés del sistema operativo, no hay permutaciones de operaciones. Los requisitos de durabilidad se mantuvieron. Operaciones de escritura: hasta que el disco respondió "Escribí, lo escribí directamente a la superficie, no al caché, seguro" El DBMS no continúa funcionando.
• Si coloca el archivo de registro en el disco de datos, se perderán casi todos los beneficios de la grabación secuencial. Además, para bien, si hay varias bases de datos en el servidor, entonces varios discos para revistas.
• Reversión de transacciones (al menos en MS SQL Server): lea el registro y restaure el estado a partir de él. Estas son tantas o incluso más operaciones de escritura como operaciones de escritura en la transacción. ¡La reversión es costosa!

Esta explicación es muy simplificada, "en los dedos". Esto es suficiente para nuestro tema. WAL es un mecanismo clave y fundamental para garantizar la transaccionalidad, es necesariamente una escritura, el acceso es de un solo subproceso solo para grabación secuencial, desde el punto de vista del almacenamiento, la profundidad de la cola es 1.

El tema del registro de escritura anticipada en la base de datos debe ser al menos mínimo conocido para cualquiera que de alguna manera administre el DBMS, o la infraestructura del DBMS, o desarrolle bases de datos.

WAL y SHD

Los fabricantes de almacenamiento "desde el nacimiento" se enfrentan al DBMS. Es para las bases de datos que las empresas compran estos complejos increíblemente caros: desde el almacenamiento de precios en la calle de Dell-EMC, HP, Hitachi, NetApp, al diseñar un presupuesto, los ojos están llenos de lágrimas de la mayoría de los altos directivos, a menos que, por supuesto, obtengan un porcentaje de este precio. Pero hay un conflicto de ingeniería y marketing. Lo explicaré usando Dell-EMC como ejemplo, pero solo porque recuerdo dónde tienen la documentación.

Entonces

1. Diario de un solo hilo
2. El registro de escritura, es decir, la latencia, es "eterno" en comparación con el rendimiento de la CPU
3. Las cargas OLTP son muchas transacciones relativamente pequeñas,
4. La mayoría de las otras cargas de DBMS son paralelas de una forma u otra.

La ley de Amdahl nos dice sin piedad que una carga de bajo rendimiento de un solo subproceso hará que agregar procesadores sea inútil, y el registro determinará el rendimiento. Además, en este momento no nos importará el rendimiento del almacenamiento en IOPS, y solo la latencia será importante.
Pero no descarte otras operaciones de disco: leer y escribir en archivos de datos y tempdb . La lectura también es una operación de "espera". Hasta que una página de datos se lea del disco a la memoria, el procesador no puede procesarla. Pero para estas operaciones, son posibles grandes colas y permutación de operaciones en esta cola: el DBMS a menudo sabe qué páginas cargar en la memoria, qué páginas volcar y pone muchas colas para leer a la vez. Como en este escenario es importante cuando finaliza la última operación del paquete, en esta carga, por el contrario, IOPS es más importante para nosotros que la latencia de una sola operación. Para comprender el alcance: las operaciones de lectura en un sistema OLTP típico son 85% -95%. Sí, sí, sí, las operaciones de escritura son un orden de magnitud menor.

Los ingenieros de almacenamiento de proveedores están trabajando estrechamente con los proveedores de DBMS y conocen todos los matices técnicos de cómo funciona un DBMS con un subsistema de disco. La planificación, partición y asignación adecuadas de los recursos del disco para el DBMS es una competencia compleja e importante del administrador del sistema de almacenamiento . El mismo Dell-EMC incluso tiene el documento técnico básico H14621 y H12341 para las recomendaciones de partición para SQL Server: más de cien páginas. Hey Este no es un muelle detallado, este es el libro blanco más común. Todavía hay un montón de específicos ( h15142 , h16389 ... hay oscuridad allí). Los "adyacentes" de VMware: la arquitectura de Microsoft SQL Server en VMware vSphere no se quedan atrás. Tenga en cuenta que estos documentos no son solo y no tanto para los DBA como para los administradores de infraestructura y almacenamiento.
También noto que en todos estos documentos, los LUN separados se cortan para datos, registros y tempdb . Sí, en algún lugar de los últimos documentos dicen claramente que para las soluciones All-Flash no tiene sentido separar los registros en medios físicamente separados, pero los LUN aún ofrecen cortarlos por separado. Si volca datos y registros en un LUN, desde el punto de vista del sistema operativo será una cola de E / S. Y habrá un problema. Las operaciones de latencia tendrán inmediatamente un orden de magnitud más. Y debido al hecho de que las operaciones de registro no reubicables aparecerán en la cola, IOPS se deslizará en los archivos de datos y tempdb . Este no es un "descubrimiento del siglo", es una verdad elemental de trabajar con la base de datos. No está desactualizado ni cancelado con la llegada de All-Flash. Sí, los retrasos en las operaciones con SSD son más rápidos en un orden de magnitud que en las operaciones con HDD, pero aún son un par de órdenes de magnitud más lentos que las operaciones con memoria. IO sigue siendo el cuello de botella del DBMS.
Y los documentos técnicos enfatizan correctamente que en los registros de transacciones el número de IOPS no es importante, pero es importante que la latencia sea mínima (en los tiempos modernos se escribe menos de 1 ms).

Pero los vendedores necesitan vender. Hiperconvergencia! Virtualización! Implementación Flexibilidad! ¡Deduplicación! Fácil configuración! ¡Muchas, muchas IOPS! Hermosas presentaciones, voz segura, disfraces formales. Pero, ¿de qué otra manera vender una solución con una etiqueta de precio de 6 a 7 dígitos en dólares? Para esto, de alguna manera se olvida que se puede obtener latencia o rendimiento del sistema de almacenamiento, pero no ambos a la vez, que algún tipo de licencia para el equilibrador de carga es como otro estante, que si la grabación intensiva dura más de una hora, entonces la RAM de los controladores no es suficiente y la productividad se reducirá a "como si no hubiera caché", que capacitar a los empleados del cliente cuesta otros 100.000 rublos durante el primer año, bueno, tales trucos ...

5 ms

Habiendo escuchado mucho de haber leído a los vendedores, o de la pereza, o debido a algún tipo de cucarachas, pero por alguna razón, a menudo los administradores de almacenamiento hacen algo como esto. Tomamos un estante grande, lo combinamos todo en algo plano, lo cortamos en LUN aprovisionados delgados y lo distribuimos por LUN al servidor. O dos, porque "la partición del sistema está bien deduplicada". Y cuando veo que con el subsistema de disco desde el lado de SQL hell-hell-hell, la misma canción comienza que "5 ms es un excelente indicador", que "100000 IOPS", "Su carga de almacenamiento es inferior al 5%"

NO

• Para sistemas OLTP en una partición con WAL / registros de transacciones de 5 ms, este es un indicador no válido. En el trozo de hierro "casi básico" por un precio de 1000 (en palabras: mil) veces más barato, el indicador normal ahora será 0.1-0.3 ms. Y mañana - 0.01 ms. No es necesaria la velocidad, como la del HDD 2008, al precio de una entrada completa de apartamentos en Moscú. Ninguna "capacidad de servicio" vale la pena.
• ¿Escribe el proveedor que los registros de transacciones no son exigentes con IOPS y pueden colocarse en el HDD? Si lo es Pero para esto es necesario que ninguno de estos discos contagio Además de escribir registros, el DBMS no tocó la tarea. Y para que el sistema de almacenamiento responda al servidor que los datos se escriben, inmediatamente cuando los datos ingresaron en la memoria no volátil (esto es mucho antes de que se escriban)
• Los discos delgados para bases de datos OLTP reales son malos.
• Para WAL, es absolutamente interesante la cantidad de IOPS que se puede exprimir a una profundidad de cola de 10 o 20. No hay profundidad allí.
• Para WAL, no es un indicador de que la cola de E / S en el sistema operativo sea "solo alrededor de 1". Ella ya no lo estará.
• No, los desarrolladores de DBA y DB no son "pájaros carpinteros que no pueden configurar correctamente para escribir en el paralelo WAL" (opinión real del administrador)
• La lógica de los ventiladores para considerar el reciclaje "dado que su sistema que configuramos torcidamente en una partición no hace 10,000 IOPS, entonces debe moverse de una matriz de gama alta a un rango medio" - esta es una lógica incorrecta.
• Si el servidor de 40 núcleos tiene una carga de procesador del 2.5 por ciento, esto no significa que no tiene nada que hacer, pero, lo más probable, significa que hay algún tipo de tarea que bloquea a todos los demás.

Cuando la carga de algunos datos en la computadora portátil del desarrollador toma 5 minutos, y en el servidor nuclear número 40 con 1 TiB de RAM y almacenamiento por medio millón de dólares, se realiza la misma tarea durante una hora, incluso los clientes más pacientes tendrán preguntas sobre la factibilidad de los costos.

Que hacer

Consejos de administración y DBA

Para OLTP, deje de contar "reciclaje" y IOPS. Separadamente, observo: no mire IOPS con grandes profundidades de cola: incluso en particiones de datos, las colas grandes generalmente tienen una ráfaga corta o algo que no afecta el rendimiento real de OLTP.

Compartir espacio en disco por LUN no es un capricho de DBA. La base de datos tiene varios perfiles de carga de subsistema de disco diferentes. Como mínimo, se puede distinguir lo siguiente:

• Trabajar con archivos de datos. Por lo general, esto es leer y escribir con bloques aleatorios de 8/64 KiB. Lecturas 80-95%. Surgen colas: durante los períodos de servicio, durante los períodos de carga masiva, en solicitudes ineficientes o masivas, y durante el punto de control. El rendimiento se ve afectado por la capacidad de respuesta a la lectura. Es importante que la alineación de los bloques KiB 8/64 "a través" pase por todo el sistema de almacenamiento.
• Trabajar con tempdb es lo mismo que trabajar con archivos de datos, pero las lecturas suelen ser del 40-75% y la capacidad de respuesta de escritura puede ser importante. En los sistemas modernos de MS SQL, esta base de datos se puede cargar varias veces más fuerte que las bases de datos. En una configuración DBMS no agrupada, esta sección debe excluirse de cualquier replicación de almacenamiento. Su contenido después de reiniciar el servicio seguirá siendo destruido.
• Trabajar con datos archivados / DWH. Las lecturas son cercanas al 100%. El tamaño de un bloque de lectura suele ser de 64 KiB. Las solicitudes se leen mucho y seguidas, por lo que la cola puede saltar hasta 1000 o más.
• Trabajar con registros de transacciones. La lectura es solo para mantenimiento (copia de seguridad, replicación, etc.), el rendimiento de la aplicación solo se ve afectado por la escritura. Grabación en bloques de 0.5-64 KiB. Sin cola, en un hilo. El retraso es crítico para las aplicaciones.
• Copia de seguridad y restauración. Desde el punto de vista de la base de datos está leyendo en bloques grandes (a menudo 1 MiB). Es importante que esta carga pueda descansar en los canales / buses (tanto FC como Ethernet) y el rendimiento de los procesadores de almacenamiento en algunos casos. Hacer una copia de seguridad de un servidor puede afectar el rendimiento de otros servidores de la misma SAN / SHD.
• Trabaje con archivos de aplicación: estos son registros, rastreo predeterminado, archivos binarios, etc. Esta carga rara vez es significativa y es importante solo al comienzo del sistema.

Existen otros tipos de carga, pero son ligeramente exóticos (por ejemplo, puede haber un repositorio de archivos almacenados en la base de datos en forma del directorio FileStream). Todos estos tipos de cargas tienen requisitos de disco diferentes, a menudo conflictivos. Si todos están apilados en una partición, no solo degrada el rendimiento, sino que es muy importante que pierda la capacidad de comprender por qué el sistema se ralentiza, y también pierde la oportunidad de mejorar solo esa parte que necesita mejoras sin mejoras / actualizaciones globales de almacenamiento. Por lo tanto, la recomendación principal:

, " " . .

• , . Dell/EMC SQL Server .
• . "" (, NUC c SSD, , ). --, .
• DBA, - ( 200 ).
• (etrolaster ), , , . +0,5 , 0,2, 0,7 3 .
• , . tempdb , , , RCSI 12 .
• Latency throughput. , " ", . throughput latency, . .

MS SQL Server

MS SQL, bottleneck , - :

1. . Esto es correcto . 1000 5-30 1000 INSERT . , , , , " — ".
2. tempdb " ". . , , .
3. , BULK INSERT . , "Simple" "Bulk logged". , , Simple/Bulk logged Full . — The Data Loading Performance Guide , . ( ETL, OLTP) We Loaded 1TB in 30 Minutes with SSIS, and So Can You
4. SQL Server Delayed Transaction Durability — , .
5. SQL Server In-Memory OLTP . , .
6. , , AlwaysOn .

***

Eso es todo . 20000 IOPS 5 latency 4-16 OLTP. OLTP , .