En esta continuación de mi serie de "ajustes de rendimiento instintivos", me gustaría analizar los discos de estado sólido (SSD) y algunos de los problemas que veo con su uso en un entorno de SQL Server. Para obtener una descripción detallada de las unidades SSD, consulte este artículo de Wikipedia.
¿Qué hacen los SSD para el rendimiento de SQL Server?
Los SSD no tienen piezas móviles, por lo que cuando se produce una lectura o escritura, casi no hay latencia de E/S. La latencia en una unidad giratoria proviene de dos cosas:
- Mover la cabeza del disco a la pista derecha en la superficie del disco (conocido como el tiempo de búsqueda)
- Esperar a que el disco gire hacia el punto correcto de la pista (conocido como latencia de rotación)
Esto significa que las unidades SSD brindan un gran aumento de rendimiento cuando hay un cuello de botella de E/S.
Es así de simple.
Hay una pequeña complicación que vale la pena mencionar, pero que está más allá del alcance de este artículo para profundizar:el rendimiento de SSD puede comenzar a degradarse a medida que la unidad se llena (investigado y explicado en detalle en este artículo de AnandTech). También es posible que se requiera algo de memoria del sistema para que el controlador SSD ayude con la nivelación del desgaste (prolongando la vida útil de las celdas NAND en el SSD), y eso variará según el proveedor. Suficiente de eso, de vuelta a las cosas de SQL Server.
Evite los malos consejos de Internet
Hay dos consejos muy malos que veo en Internet sobre SQL Server y SSD.
El primero es sobre qué poner en el SSD, donde el consejo es poner siempre tempdb y sus registros de transacciones en SSD. A primera vista, parece un buen consejo, ya que los registros de transacciones y tempdb suelen ser cuellos de botella en el sistema.
Pero, ¿y si no lo son?
Es posible que su carga de trabajo sea principalmente de lectura, en cuyo caso es probable que el registro de transacciones no sea un cuello de botella de la carga de trabajo y, por lo tanto, ponerlo en un SSD puede ser un desperdicio de un SSD costoso.
Es posible que su tempdb no se use mucho por su carga de trabajo, por lo que colocarlo en un SSD puede ser un desperdicio de un SSD costoso.
Cuando está considerando qué parte del entorno de SQL Server trasladar al SSD, desea investigar dónde están los cuellos de botella de E/S. Esto se puede hacer muy fácilmente usando el código que publiqué la semana pasada que usa el DMV sys.dm_io_virtual_file_stats para proporcionar una instantánea de las latencias de E/S para todos los archivos en todas las bases de datos en la instancia. Para dar sentido a sus números de latencia y compararlos con valores buenos/malos, lea esta larga publicación que hice específicamente sobre tempdb y las latencias de E/S del registro de transacciones.
Y luego, incluso si tiene latencias altas, no piense que la única solución es mover los archivos de bajo rendimiento a un SSD:
- Para las latencias de lectura de archivos de datos, investigue por qué se están produciendo tantas lecturas. Cubro eso aquí.
- Para las latencias de escritura de archivos de registro, considere todas las formas de ajustar el rendimiento del registro y lo que se registra. Lo cubro aquí, aquí y aquí.
El peor caso posible es cuando recibe un montón de SSD, sigue los consejos de Internet para mover tempdb y sus archivos de registro a ellos, y luego no hay ganancia en el rendimiento de la carga de trabajo. Eso no alentará a su administración a proporcionarle SSD más caros.
El segundo consejo deficiente es sobre la fragmentación del índice, donde el consejo es que debido a que los SSD son tan rápidos, no necesita preocuparse por la fragmentación del índice cuando usa SSD.
¡Qué tontería!
Hay tres formas en las que refuto ese mal consejo:
Lo único que hacen los SSD con respecto a la fragmentación de índices es hacer que las lecturas sean más rápidas, por lo que hay menos penalización de rendimiento para los escaneos de rango de índice cuando existe fragmentación de índice, pero el punto 3 anterior muestra que todavía hay una penalización.
Los SSD no cambian la forma en que maneja o previene la fragmentación de índices en su entorno de SQL Server.
Asegúrese de proteger sus datos
Uno de los pecados capitales que veo que la gente comete al usar SSD es usar solo uno de ellos. Con solo una unidad, ¿qué nivel de RAID está utilizando? Cero. RAID-0 no proporciona redundancia en absoluto.
Si va a usar un SSD, entonces necesita usar al menos dos, en una configuración RAID-1 (duplicación). No tiene sentido tener un aumento de rendimiento si está sacrificando la disponibilidad del sistema como contrapartida.
Un inconveniente que a veces recibo al usar al menos dos SSD es que la tarjeta SSD proporciona dos unidades a Windows, por lo que seguramente crear un volumen reflejado de Windows en las dos unidades es lo mismo que RAID-1 en dos SSD físicamente separados.
No, no es. Sigue siendo un SSD físico, sin redundancia. ¿Alguna vez has visto fallar la mitad de una tarjeta SSD? No, yo tampoco. Hágalo bien y use dos de ellos y obtenga redundancia real para sus datos.
El otro rechazo que recibo es que son SSD, no unidades giratorias, por lo que no van a fallar. Eso está mal. Los SSD pueden fallar y fallan al igual que las unidades giratorias. Personalmente, he visto fallar dos SSD de nivel empresarial durante las pruebas en nuestro entorno de laboratorio. De acuerdo con este artículo en StorageReview.com, las SSD para consumidores tienen un MTBF de 2 millones de horas frente a 1,5 millones de horas para las unidades giratorias para consumidores, y esperaría resultados similares para las unidades para empresas, pero las SSD fallan.
Resumen
No caiga en la trampa de pensar que lo que sea que coloque en el SSD significa que obtendrá un aumento en el rendimiento:debe elegir con cuidado. Y tampoco se crea las tonterías que existen sobre ignorar la fragmentación del índice cuando se usan SSD.
Los SSD son una forma muy útil de aumentar el rendimiento, pero por su costo, debe asegurarse de maximizar el retorno de la inversión de su empresa usándolos correctamente y solo cuando sea apropiado.
En el próximo artículo de la serie, analizaré otra causa común de ajuste de rendimiento instintivo. Hasta entonces, ¡feliz resolución de problemas!
