SQL Server ha encontrado casos de solicitudes de E / S que demoran más de 15 segundos

En Production SQL Server, tenemos la siguiente configuración:

3 servidores Dell PowerEdge R630, combinados en el grupo de disponibilidad Los 3 están conectados a una sola unidad de almacenamiento SAN de Dell que es una matriz RAID

De vez en cuando, en PRIMARIO vemos mensajes similares a los siguientes:

SQL Server ha encontrado 11 ocurrencias de solicitudes de E / S que tardan más de 15 segundos en completarse en el archivo [F: \ Data \ MyDatabase.mdf] en la identificación de la base de datos 8.
El identificador del archivo del sistema operativo es 0x0000000000001FBC.
El desplazamiento de la última E / S larga es: 0x000004295d0000.
La duración de la E / S larga es: 37397 ms.

Somos novatos en la resolución de problemas de rendimiento

¿Cuáles son las formas más comunes o las mejores prácticas para solucionar este problema en particular relacionado con el almacenamiento? ¿Qué contadores de rendimiento, herramientas, monitores, aplicaciones, etc. deben usarse para reducir la causa raíz de tales mensajes? ¿Podría haber un evento extendido que pueda ayudar, o algún tipo de auditoría / registro?

Tenemos una configuración similar y recientemente encontramos estos mensajes en los registros. Estamos utilizando una SAN DELL Compellent. Aquí hay algunas cosas para verificar al recibir estos mensajes que nos ayudaron a encontrar una solución

• Revise los contadores de rendimiento de Windows para sus discos a los que apuntan los mensajes de advertencia, específicamente:
  • Promedio de disco tiempo de lectura
  • Promedio de disco tiempo de escritura
  • Lectura de disco en bytes / seg.
  • Disco escribir bytes / seg.
  • Transferencias de disco / seg.
  • Media longitud de la cola del disco
• Lo anterior son promedios. Si tiene muchos archivos de base de datos en una unidad, estos promedios pueden sesgar el resultado y enmascarar un cuello de botella en archivos de base de datos específicos. Echa un vistazo a esta consulta de Paul S. Randal que devuelve la latencia promedio para cada archivo desde el dmv sys.dm_io_virtual_file_stats. En nuestro caso, la latencia promedio informada fue aceptable, pero debajo de las cubiertas teníamos muchos archivos con una latencia promedio> 200 ms.
• Verifique los horarios. ¿Hay algún patrón? ¿Ocurre con mayor frecuencia a cierta hora de la noche? Si es así, compruebe si hay trabajos de mantenimiento en ejecución en ese momento o cualquier actividad programada que pueda aumentar la actividad del disco y exponer un cuello de botella en su subsistema de E / S.
• Verifique el visor de eventos de Windows en busca de errores. Si su conmutador o SAN se está sobrecargando o no está configurado correctamente para su aplicación, puede encontrar algunos mensajes en este registro, y es bueno llevar esta información a su administrador de SAN. En nuestro caso, recibíamos errores de conexión iSCSI a menudo durante todo el día, lo que indicaba el problema.
• Revise su código de SQL Server. Cuando reciba estos mensajes, no debería pensar de inmediato que es un problema del subsistema IO y pasarlo a su administrador de SAN. Debe hacer su parte y revisar la base de datos. ¿Realmente se ejecutan consultas realmente malas que generan toneladas de datos? Mala indexación? Escrituras de registro de transacciones excesivas? Puede usar algunas consultas de código abierto para obtener una verificación de estado en su base de datos, un ejemplo para verificar cómo se ve su plan de consulta es sp_blitzCache
• No ignores estos. Hoy puede recibirlos varias veces al día ... luego, varios meses después, cuando aumenta su carga de trabajo y se olvida de controlarlos, comienzan a aumentar. Recibir muchos de estos mensajes puede evitar que SQL Server acceda a un determinado archivo, y si es tempdb , eso no es bueno. En nuestro caso se puso tan mal que SQL Server se apagó solo.

Nuestra solución fue actualizar nuestro conmutador a un conmutador SAN. Sí, estos son todos los puntos a cubrir dentro de SQL Server. Lo que nos llevó a descubrir que fue el cambio fue que recibíamos aproximadamente 1500 errores de desconexión de PDU iSCSI en el visor de eventos de la aplicación de Windows en el Servidor SQL todos los días. Eso provocó la investigación de nuestros administradores de SAN sobre el cambio.

Inmediatamente después de la actualización, los errores de iSCSI desaparecieron y la latencia promedio se redujo a alrededor de 50 ms para todos los archivos, y eso se correlacionó con un mejor rendimiento en la aplicación. Con estos puntos en mente, espero que pueda encontrar su solución.

Esto es mucho menos frecuente un problema de disco, y mucho más a menudo un problema de red. ¿Sabes, la N en SAN?

Si va a su equipo SAN y comienza a hablar de que los discos son lentos, le mostrarán un gráfico elegante con una latencia de 0 milisegundos y luego le señalarán una grapadora.

En cambio, pregúnteles sobre la ruta de red a la SAN. Obtenga velocidades, si tiene varias rutas, etc. Obtenga números de ellas sobre las velocidades que debería estar viendo. Pregunte si tienen puntos de referencia de cuando se configuraron los servidores.

Luego puede usar Crystal Disk Mark o diskpd para validar esas velocidades. Si no se alinean, nuevamente, lo más probable es que se trate de redes.

También debe buscar en su registro de errores mensajes que contengan "FlushCache" y "saturación", porque también pueden ser signos de contención de la red.

Una cosa que puede hacer para evitar esas cosas como un DBA es asegurarse de que su mantenimiento y cualquier otra tarea con muchos datos (como ETL) no se realicen al mismo tiempo. Eso definitivamente puede ejercer mucha presión sobre las redes de almacenamiento.

También puede consultar las respuestas aquí para obtener más sugerencias: punto de control lento y advertencias de E / S de 15 segundos en almacenamiento flash

Escribí en un blog sobre un tema similar aquí: del servidor a la SAN

¿Por qué almacenar los datos en una SAN? ¿Cuál es el punto de? Todo el rendimiento de la base de datos está vinculado a la E / S de disco y está utilizando 3 servidores con un solo dispositivo para la E / S detrás de ellos. Eso no tiene sentido ... y desafortunadamente es muy común.

Me paso la vida encontrando plataformas de hardware mal diseñadas donde las personas simplemente intentan diseñar una computadora a gran escala. Toda la potencia de la CPU aquí, todos los discos allí ... con suerte no hay tal cosa como RAM remota. Y lo más triste es que compensan la falta de eficiencia de este diseño con enormes servidores que cuestan diez veces más de lo que deberían. Vi infra de $ 400k más lento que una computadora portátil de $ 1k.

Un software de servidor SQL es un software muy avanzado, está diseñado para aprovechar cualquier parte de hardware, núcleos de CPU, caché de CPU, TLB, RAM, controladores de disco, caché de disco duro ... Casi incluyen toda la lógica del sistema de archivos. Se desarrollan en una computadora normal y se comparan con los sistemas de alta gama. Por lo tanto, un servidor SQL debe tener sus propios discos. Instalarlos en una SAN es como "emular" una computadora, pierde todas las optimizaciones de rendimiento. Las SAN son para almacenar copias de seguridad, archivos inmutables y archivos a los que simplemente agrega datos (registros).

Los administradores de centros de datos tienden a poner todo lo que pueden en SAN porque de esta manera solo tienen que administrar un grupo de almacenamiento, es más fácil que cuidar el almacenamiento en cada servidor. Es una opción de "No quiero hacer mi trabajo", y una muy mala, porque entonces tienen que lidiar con problemas de rendimiento y toda la empresa sufre esto. Simplemente instale el software en el hardware para el que está diseñado. Mantenlo simple. Cuide el ancho de banda de E / S, la caché y la sobrecarga del cambio de contexto, la fluctuación de recursos (ocurre cuando se comparte el recurso). Terminará manteniendo 1/10 de los dispositivos con la misma potencia de salida sin procesar, ahorrará muchos dolores de cabeza a su equipo de operaciones, obtendrá un rendimiento que hará que sus usuarios finales estén contentos y sean más productivos, haga de su empresa un mejor lugar para trabajar y Ahorre mucha energía (el planeta se lo agradecerá).

Usted dijo en los comentarios que está considerando colocar SSD en su servidor. No reconocerá su configuración con SSD dedicados, en comparación con una SAN obtendrá una mejora de 500x incluso con archivos de registro de datos y transacciones en la misma unidad. Un servidor SQL de última generación tendría un SSD rápido y separado para el registro de datos y transacciones en diferentes canales de controladores de hardware (la mayoría de las placas base del servidor tienen varias). Pero en comparación con su configuración actual, estamos hablando de ciencia ficción allí. Solo prueba SSD.

Ok, para cualquier persona interesada,

Resolvimos el problema en la pregunta hace un par de meses simplemente instalando unidades SSD conectadas directamente en cada uno de los 3 servidores, y moviendo datos de DB y archivos de registro desde SAN a esas unidades SSD

Aquí un resumen de lo que hice para investigar sobre este tema (usando las recomendaciones de todas las publicaciones en esta pregunta), antes de que decidiéramos instalar unidades SSD:

1) comenzó a recopilar contadores PerfMon para las siguientes unidades en los 3 servidores:

Disk F:es un disco lógico basado en SAN, contiene archivos de datos MDF
Disk I:es un disco lógico basado en SAN, contiene archivos de registro LDF
Disk T:está directamente conectado SSD, dedicado exclusivamente a tempDB

La imagen a continuación muestra los valores promedio recopilados durante un período de 2 semanas.

Disk I: (LDF)tiene un IO tan pequeño y la latencia es muy baja, por lo que el disco I: puede ignorarse
Puede ver que Disk T: (TempDB)tiene un IO más grande en comparación con Disk F: (MDF), y tiene una latencia mucho mejor al mismo tiempo - 0 ms

Obviamente, algo está mal con el disco F: donde residen los archivos de datos, tiene una alta latencia y una cola de escritura de disco promedio, a pesar de la baja E / S

2) Latencia comprobada para bases de datos individuales utilizando la consulta de este sitio web

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Pocas bases de datos activas en el servidor primario tenían una latencia de lectura de 150 a 250 ms y una latencia de escritura de 150 a 450 ms
. otra indicación de que algo está mal con SAN

3) No hubo tiempos específicos

Durante el cual aparecieron mensajes de "SQL Server ha encontrado incidentes ..."
No se ejecutaron ETL de mantenimiento o disco pesado cuando se registraron esos mensajes

4) Visor de eventos de Windows

No mostró ninguna otra entrada que sugiriera el problema, excepto que "SQL Server ha encontrado eventos ..."

5) Comenzó a verificar las 10 consultas principales

Desde sp_BlitzCache (cpu, lecturas, etc.), y omptimizando donde sea posible
No hay consultas pesadas súper IO que produzcan toneladas de datos e impacten mucho el almacenamiento, aunque la
indexación en bases de datos está bien, lo mantengo

6) No tenemos equipo de SAN

Solo tenemos 1 administrador del sistema que ayuda en ocasiones Ruta de
red a SAN: es de múltiples rutas, cada uno de los 3 servidores tiene 2 cables de red que conducen a los conmutadores y luego a SAN, y se supone que es de 1 Gigabyte / seg.

7) No hubo resultados de CrystalDiskMark

O cualquier otro resultado de prueba de referencia de cuando se configuraron los servidores, por lo que no sé cuáles deberían ser las velocidades , y no es posible comparar en este punto para ver cuáles son las velocidades actuales, ya que habría afectado la producción

8) Configurar la sesión de eventos extendidos en el evento de punto de control para la base de datos en cuestión

La sesión XE ayudó a descubrir que durante los mensajes "SQL Server ha encontrado eventos ...", el punto de control sucedió muy lento (hasta 90 segundos)

9) Registro de errores del servidor SQL

Entradas "Saturación" contenidas en "FlushCache"
Se supone que se muestran cuando el tiempo del punto de control para la base de datos dada excede la configuración del intervalo de recuperación

Los detalles mostraron que la cantidad de datos que el punto de control está tratando de eliminar es pequeña y está tardando mucho en completarse, y la velocidad general es de aproximadamente 0.25 MB / seg ... raro

10) Finalmente, esta imagen muestra la tabla de solución de problemas de almacenamiento:

Parece que simplemente tenemos un "Problema de hardware: - Trabaje con el administrador del sistema / proveedor de hardware para corregir cualquier configuración incorrecta de SAN, controladores antiguos, defectuosos, controladores, firmware, etc."

En otra pregunta "Punto de control lento ..." Punto de control lento y advertencias de E / S de 15 segundos en el almacenamiento flash Sean tenía una lista muy buena de los elementos que deben verificarse a nivel de hardware y software para solucionar problemas

Nuestro administrador de sistemas no pudo verificar todas las cosas de la lista, por lo que simplemente elegimos lanzar un poco de hardware a este problema; no era costoso en absoluto

Resolución:

Pedimos unidades SSD de 1 TB y las instalamos directamente en los servidores

Dado que tenemos Grupos de disponibilidad, migramos archivos de datos de base de datos de SAN a SSD en réplicas secundarias, luego conmutamos por error y migramos archivos en la primaria anterior. Esto permitió un tiempo de inactividad total mínimo: menos de 1 minuto

Ahora cada servidor tiene una copia local de los datos de la base de datos, y se realizan copias de seguridad completas / diferenciadas / de registro en la SAN mencionada.
No más mensajes de "SQL Server ha encontrado ocurrencias ..." en los registros del Visor de sucesos de Windows y el rendimiento de las copias de seguridad, las verificaciones de integridad, reconstrucciones de índice, consultas, etc. ha aumentado significativamente

¿Cuánto rendimiento en términos de latencia de E / S ha mejorado desde que migramos los archivos DB a SSD?

Para evaluar el impacto, el rendimiento utilizado de Windows Performance Monitor registra 2 semanas antes de la migración y 4 semanas después de la migración:

También a continuación se muestra la comparación de estadísticas de latencia de nivel de base de datos (se utilizaron las estadísticas de archivos virtuales capturados de SQL Server antes y después de la migración)

Resumen

La migración de SAN a SSD locales conectados directamente valió la pena.
Tuvo un gran impacto en la latencia del almacenamiento y mejoró más del 90% en promedio (especialmente las operaciones de ESCRITURA), y ya no tenemos picos de 20-50 segundos en IO

Pasar a SSD local resolvió no solo los problemas de rendimiento de almacenamiento, sino también la seguridad de los datos que me preocupaban (si SAN falla, los 3 servidores pierden sus datos al mismo tiempo)