En nuestra empresa ya hemos impartido cerca de de 10-15 veces la formación de Fast Track Datawarehousing para SQL Server 2008 R2. A finales de febrero, se ha revisado la versión 3.0 en el evento annual de TDI en Las Vegas.Cosas de la vida han hecho que el segundo lugar en el que se impartiera la formación oficial de Fast Track 3.0 fuera en Madrid (el primero fué Seattle), y ahí hemos estado entretenidos esta semana pasada 🙂

Si estás interesado en recibir esta formación y tu empresa es partner de Microsoft, te recomiendo contactar con tu representante de Microsoft, para conocer la agenda de las próximas ejecuciones.

Si por el contrario no estas en empresas partners de Microsoft, considera asistir a este evento (SolidQ Summit 2011), donde se impartirá algunas sesiones sobre estos temas. Más información en ibinfo@solidq.com.

 

Antes de seguir:

  • Si no sabes que es Fast Track DW 3.0, vete aquí
  • Si quieres conocer la documentación oficial de la versión 3.0 – arquitectura de referencia, aquí
  • Si quieres conocer la documentación oficial de la versión 2.0 – arquitectura de referencia, aquí
  • Si quieres conocer la propuesta de HP, aquí
  • Si quieres conocer la propuesta de IBM, aquí
  • Si quieres conocer la propuesta de DELL, aquí

 

En la formación de esta semana, HP nos ha proporcionado un DL5XXX con 48 cores, 212GB de RAM, y 4 bandejas conectadas a HBAs de doble puerto de 8GBits.

Esta fué la configuración de una de las bandejas:

En la que cada bandeja dispone de 22 discos:

  • 5 RAID 10 de 4 discos cada uno, todos ellos con un único volumen de 600GB
    • 4 de ellos dedicados para datos
    • 1 de ellos dedicado para archivo de transacciones
  • 2 discos Global Spare

 

Con todo esto, si ha revisado la documentación de la arquitectura de referencia, uno de las validaciones que se suele hacer, es si el sistema está configurado adecuadamente para soportar el volumen de lecturas secuenciales que necesita un datawarehouse; sistemas como estos tienen principalmente lecturas secuenciales de 512KB, por lo esa es la medida fundamental a realizar. Nota, que está en contraposición con los sistemas OLTP tradicionales que buscan fundamentalmente eficiencia en lecturas aleatorias de tamaño reducido: entre 8-64Kb. En nuestro caso, al tratarse de DW, las pruebas se focalizan en lecturas, lectura, muchas lecturas, y todas secuenciales.

Para ello se utiliza una herramienta como SQLIO; si no la conoces, y necesitas más info, aquí la tienes.

Estaba muy interesado en verificar la eficiencia de los discos mecánicos, al realizar lecturas en distintas zonas del disco, y para ello con la ayuda de SQLIO, he creado archivos en uno de los volumenes en las siguientes áreas para medir su eficiencia:

  • 1 archivo de 10GB secuencial sin fragmentación en la zona externa del disco
  • 1 archivo de 10GB secuencial sin fragmentación en la zona media del disco
  • 1 archivo de 10GB secuencial sin fragmentación en la zona interna del disco
  • 1 archivo de 10GB secuencial muy fragmentado físicamente por todo el disco

si te interesa saber cómo lo he hecho, explico un poco cómo ha sido el proceso:

  • partiendo de unidad vacía completamente.
  • un hilo creando un archivo de 10GB.
  • a continuación rellenar hasta llegar a la mitad con archivos de 2.5GB y 200MB alternos. fíjate en la imagen posterior
  • cuando llego a la mitad del disco, vuelvo a crear otro archivo de 10GB.
  • a continuación rellenar hasta llegar a la mitad con archivos de 2.5GB y 200MB alternos. fíjate en la imagen posterior
  • finalmente creo un archivo de 10GB para llenar el disco completamente.
  • una vez todo relleno, borro todos los archivos de 200MB para generar especio suficiente
  • creo otro archivo de 10GB, que por “narices” tendrá que localizarse en los huecos generados 🙂

Una imagen, vale más que mil palabras creo yo:

en la imagen sólo ven en el cuadrado Rojo el primer archivo de 10GB.

fijate los alternos entre archivos de 2.5GB (PERMANxx.dat), y los que se borrarán de 200MB (FILLERxx.dat).

una vez creados los archivos, se renombran adecuadamente los que interesan y se ejecutan las siguientes instrucciones:

sqlio.exe -kR -fsequential -t4 -o40 -b512 -s15 C:FTdata15TEST__INICIO.dat >INICIO.TXT
sqlio.exe -kR -fsequential -t4 -o40 -b512 -s15 C:FTdata15TEST__MEDIO.dat>MEDIO.TXT
sqlio.exe -kR -fsequential -t4 -o40 -b512 -s15 C:FTdata15TEST__FIN.dat>FIN.TXT
sqlio.exe -kR -fsequential -t4 -o40 -b512 -s15 C:FTdata15TEST__FRAGMENTADO.dat>FRAGMENTADO.TXT

los argumentos de SQLIO son los siguientes:

  • -kR: operaciones de lectura
  • -fsequential: operaciones secuenciales
  • -t4: numero de threads
  • -o40: número de peticiones encoladas en disco (outstanding IOs)
  • -b512: operaciones de 512Kb
  • -s15: duración de la prueba en segundos

 

Resultados de la prueba:

 

En color Rojo: bytes leidos por segundo.

En color Azul: tiempo medio de espera por petición de lectura.

Los porcentajes dependerán de cada tipo de disco y configuración, pero de las pruebas realizadas en nuestro entorno:

  • la diferencia entre tener el archivo en la zona externa del disco vs la zona interna es de un 33% en cuanto a la capacidad de transferencia de información; fíjate que desciende de poco más de 300MB/sec a algo más de 200MB/sec
  • por diferencia, el peor escenario posible es que el archivo esté fragmentado: frente al mejor caso, aparecen tasas de transferencia de 150MB/sec vs los más de 300MB/sec

Conclusiones:

  • Cuanto más en la zona interna esté el archivo, menor será la tasa de transferencia y mayores serán las latencias para realizar la operación
  • El peor escenario posible es trabajar con archivos fragmentados (en nuestro caso, el número de fragmentos era de 200 para un archivo de 10GB)
  • por último, y no menos importante, estas mediciones impactarán negativamente en el sistema completo; considera que estamos hablando de sistemas cuya tasa de transferencia desde el sistema de E/S fácilmente por encima de los 4GB/sec – el sistema probado lo configuramos para 4.5GB/sec, por lo que podríamos estar en casos en los que la tasa de transferencia se reduzca por debajo de 3GB/sec, lo cual implica que el sistema estaría totalmente des-balanceado, que precisamente es lo que persiguen la arquitectura de referencia para FTDW…

 

————————————————————————————————————————————————————————————————————————

Ya como pié de post, y fuera del contexto del artículo, este sería el resultado para la siguiente ejecución – dejo al lector averiguar para qué tipo de sistema serían esas operaciones Smile, eso si, nota que el impacto es muchísimo mayor!:

sqlio.exe -kR -frandom -t4 -o40 -b64 -s15 C:FTdata15TEST__INICIO.dat >INICIO.TXT
sqlio.exe -kR -frandom -t4 -o40 -b64 -s15 C:FTdata15TEST__MEDIO.dat>MEDIO.TXT
sqlio.exe -kR -frandom -t4 -o40 -b64 -s15 C:FTdata15TEST__FIN.dat>FIN.TXT
sqlio.exe -kR -frandom -t4 -o40 -b64 -s15 C:FTdata15TEST__FRAGMENTADO.dat>FRAGMENTADO.TXT

Conclusion general: si tienes un sistema de bases de datos con archivos muy fragmentados físicamente, tienes un problema serio! el problema es que para deshacer esa fragmentación, en muchos casos (sobre todo el FTDW) tienes que parar y empezar de nuevo, así que ya sabes, si no quieres problemas: hazlo bien desde el principio… si eres recién llegado al sistema y te encuentras el pastel… investiga y lucha por arreglarlo; recuerda a Paulo Coelho: “Cuando quieres algo, todo el universo conspira para que realices tu deseo” .

 

Eladio Rincón

Mentor & Flex Director at SolidQ
I am professionally focused on SQL Server databases. I am an MVP on SQL Server since 2003, and my area of expertise is resolution of performance and scalability issues for OLTP based systems.

My professional career revolve on SQL Server mentoring, consulting, and training projects. I believe that mixing training and mentoring projects is the best approach to help the clients to get the most from SQL Server. With other mentors of SolidQ I have developed a tuning methodology applied in most of the SQL Server consulting projects.
Eladio Rincón