Uno de los cuellos de botella de rendimiento más comunes que veo como consultor es el rendimiento inadecuado del subsistema de almacenamiento. Hay una serie de razones para el bajo rendimiento del almacenamiento, pero medirlo y comprender lo que se debe medir y monitorear siempre es un ejercicio útil.
En realidad, hay tres métricas principales que son más importantes cuando se trata de medir el rendimiento del subsistema de E/S:
Latencia
La primera métrica es la latencia, que es simplemente el tiempo que tarda en completarse una E/S. Esto a menudo se denomina tiempo de respuesta o tiempo de servicio. La medición comienza cuando el sistema operativo envía una solicitud a la unidad (o al controlador de disco) y finaliza cuando la unidad termina de procesar la solicitud. Las lecturas se completan cuando el sistema operativo recibe los datos, mientras que las escrituras se completan cuando la unidad informa al sistema operativo que ha recibido los datos.
Para escrituras, los datos aún pueden estar en un caché DRAM en la unidad o controlador de disco, según su política de almacenamiento en caché y hardware. El almacenamiento en caché de reescritura es mucho más rápido que el almacenamiento en caché de escritura simultánea, pero requiere una batería de respaldo para el controlador de disco. Para el uso de SQL Server, desea asegurarse de que está utilizando el almacenamiento en caché de reescritura en lugar del almacenamiento en caché de escritura simultánea, si es posible. También querrá asegurarse de que la memoria caché de su disco de hardware esté realmente habilitada, ya que algunas herramientas de administración de discos de proveedores la desactivan de forma predeterminada.
Operaciones de entrada/salida por segundo (IOPS)
La segunda métrica es Operaciones de entrada/salida por segundo (IOPS). Esta métrica está directamente relacionada con la latencia. Por ejemplo, una latencia constante de 1 ms significa que una unidad puede procesar 1000 E/S por segundo con una profundidad de cola de 1. A medida que se agreguen más E/S a la cola, la latencia aumentará. Una de las ventajas clave del almacenamiento flash es que puede leer/escribir en múltiples canales NAND en paralelo, junto con el hecho de que no hay partes móviles electromecánicas que ralenticen el acceso al disco. IOPS en realidad es igual a la profundidad de la cola dividida por la latencia, e IOPS por sí mismo no considera el tamaño de transferencia para una transferencia de disco individual. Puede traducir IOPS a MB/seg y MB/seg a latencia siempre que conozca la profundidad de la cola y el tamaño de la transferencia.
Rendimiento secuencial
El rendimiento secuencial es la velocidad a la que puede transferir datos, normalmente medido en megabytes por segundo (MB/s) o gigabytes por segundo (GB/s). Su métrica de rendimiento secuencial en MB/s es igual a las IOPS multiplicadas por el tamaño de la transferencia. Por ejemplo, 556 MB/s equivalen a 135 759 IOPS por un tamaño de transferencia de 4096 bytes, mientras que 135 759 IOPS por un tamaño de transferencia de 8192 bytes serían 1112 MB/s de rendimiento secuencial. A pesar de su importancia cotidiana para SQL Server, el rendimiento del disco secuencial a menudo se ve afectado en el almacenamiento empresarial, tanto por los proveedores de almacenamiento como por los administradores de almacenamiento. También es bastante común ver que los discos magnéticos reales en un gabinete de almacenamiento adjunto directo (DAS) o un dispositivo de red de área de almacenamiento (SAN) están tan ocupados que no pueden entregar su rendimiento secuencial nominal completo.
El rendimiento secuencial es fundamental para muchas actividades comunes del servidor de bases de datos, incluidas las copias de seguridad y restauraciones de bases de datos completas, la creación y reconstrucción de índices y los análisis de lectura secuencial de tipo almacén de datos de gran tamaño (cuando los datos no caben en el grupo de búfer de SQL Server). Un objetivo de rendimiento al que me gusta apuntar en las nuevas compilaciones de servidores de bases de datos es tener al menos 1 GB/s de rendimiento secuencial para cada letra de unidad o punto de montaje. Tener este nivel de rendimiento (o mejor) hace que su vida sea mucho más fácil como profesional de bases de datos. Hace que muchas de las tareas comunes de la base de datos sean mucho más rápidas y también le da la libertad de realizar ajustes de índice más frecuentes cuando puede crear un índice en una tabla grande en segundos o minutos en lugar de horas.
Métricas de carga de trabajo de E/S de SQL Server
Cuando se trata de SQL Server y el rendimiento de E/S, hay una serie de cosas que debe medir y monitorear a lo largo del tiempo. Debe conocer la proporción de lectura frente a escritura de su carga de trabajo para todos los archivos de la base de datos de usuario y para tempdb. Las proporciones serán diferentes para los diferentes tipos de archivos y cargas de trabajo de SQL Server. Puede usar mis Consultas de diagnóstico del DMV para determinar esto, y también puede usar la Vista de actividad del disco en SQL Sentry Performance Advisor para obtener fácilmente una vista más completa de la actividad de su disco, desde un panorama general de alto nivel, hasta el final. a archivos individuales:
Asesor de rendimiento de SQL Sentry:actividad del disco
También debe medir las tasas de E/S típicas para IOPS y el rendimiento secuencial. En el Monitor de rendimiento de Windows (PerfMon), las lecturas/seg. y las escrituras/seg. muestran IOPS, mientras que los bytes de lectura de disco/seg. y los bytes de escritura de disco/seg. representan el rendimiento secuencial. Debe usar PerfMon para medir el promedio de segundos/lectura del disco y el promedio de segundos/escritura del disco, que es la latencia de lectura y escritura en el nivel del disco. Finalmente, puede usar mis Consultas de diagnóstico del DMV para medir la latencia promedio de lectura y escritura a nivel de archivo para todos sus archivos de base de datos de usuario, así como para tempdb.
Métodos para medir el rendimiento de E/S
Puede usar la sección Disco en el Monitor de recursos de Windows para obtener una vista rápida y en tiempo real de algunas métricas de disco clave para todos sus archivos de base de datos de SQL Server. Profundizando, puede usar PerfMon para medir y monitorear los contadores de rendimiento críticos que mencioné anteriormente. Antes de entrar en producción con un nuevo servidor de base de datos, debe realizar algunas pruebas comparativas de disco para determinar qué tipo de rendimiento puede ofrecer realmente su subsistema de E/S. En realidad, esto no es tan difícil ni requiere mucho tiempo (si utiliza las herramientas adecuadas), pero a menudo se olvida cuando se aprovisiona y prueba un nuevo servidor de base de datos.
El primer banco de pruebas de disco que siempre debe ejecutar es CrystalDiskMark 4.0, que se ha reescrito recientemente para usar el programa de banco de pruebas de disco relativamente nuevo Microsoft DiskSpd. La interfaz de usuario de CDM 4.0 le permite elegir una gama más amplia de tamaños de archivos de prueba y también le permite elegir la profundidad de la cola y la cantidad de subprocesos para las ejecuciones de prueba. Esto le permite obtener una carga de trabajo de E/S más similar a la de un servidor y también le permite enfatizar de manera más adecuada los dispositivos de almacenamiento flash NVMe más nuevos que pueden manejar profundidades de cola superiores a 32.
CrystalDiskMark 4.03 Resultados con QD =32 y subprocesos =1
Figura 2:Resultados de CrystalDiskMark 4.03 con QD =32 y subprocesos =4
A diferencia de las versiones anteriores de CDM, las dos filas más relevantes para el uso de SQL Server se encuentran en el medio de la pantalla de resultados. Son las lecturas y escrituras aleatorias de 4K con una gran profundidad de cola (32 por defecto) y las lecturas y escrituras secuenciales. Después de realizar algunas pruebas comparativas de almacenamiento con CrystalDiskMark 4.0, debe realizar algunas pruebas más exhaustivas con Microsoft DiskSpd. En un artículo futuro, cubriré cómo usar DiskSpd para realizar pruebas más completas para SQL Server.
