SQL lento por cuellos de botella de E/S ¿Y ahora qué?

Volvemos al ataque con otro artículo sobre problemas de rendimiento. Como buenos DBAs ya hemos luchado contra los temibles problemas con el uso de RAM y los picos de uso de CPU y ahora es el turno de librar una batalla contra los problemas de E/S en los discos duros. Los problemas de velocidad de E/S en disco no son tan fáciles de localizar, sin embargo están ahí, en la sombra, saboteando el buen rendimiento de SQL Server. Los discos duros son el hardware más lento de nuestros servidores y, sin embargo, los que almacenan toda la información. No es extraño que se conviertan en uno de los principales cuellos de botella para nuestras consultas.

¿Qué es un cuello de botella por E/S de disco?

En informática, llamamos cuello de botella a la situación resultante cuando un componente de un sistema es más lento que el resto y por tanto frena todo. Es como un atasco en la carretera de los datos. ¿Habéis escuchado el dicho de que una cadena es tan fuerte como su eslabón más débil? Pues, en nuestro caso, un sistema es tan rápido como su componente más lento. En el caso de SQL Server esto tiene graves consecuencias, como ya hemos dicho, el hardware más lento es el que almacena toda la información.

Causas comunes de los cuellos de botella de E/S

Vale, afrontamos esta batalla con una mano atada a la espalda, los discos son hardware lento. Pero eso no significa que nos tengamos que rendir, existen una serie de optimizaciones que podremos llevar a cabo para paliar este problema en la medida de lo posible.

Velocidad de E/S de discos

Lo primero y lo más obvio será elegir un hardware de calidad acorde a nuestras necesidades. La velocidad de los discos se mide en E/S y no es igual para un disco SATA que para uno SAS (que duplica la velocidad de SATA) que para un disco SSD. Por no hablar de los SSD M2 y NVMe que han supuesto un verdadero avance en este sentido. El problema es que los discos duros, o son rápidos, o son grandes o son económicos, pero las tres cosas a la vez son, a día de hoy, imposibles. Esto hace que tengamos que priorizar, eligiendo discos más rápidos para las bases de datos con más volumen de operaciones como la TempDB y para los ficheros de log.

Separación de discos

Los discos están limitados en velocidad, vale, pero podemos jugar con lo que se llama un escalado horizontal, haciendo crecer nuestro servidor con más discos y aprovechando la ventaja de lectura y escritura simultánea entre ellos. En la era de la virtualización y las redes de almacenamiento NAS y SAN es aún más importante esta separación y tendremos que tener en cuenta más niveles que solo los discos duros. Entrarán en juego conceptos como el uso de varios agregados, LUNs, controladoras y hasta distintas interfaces físicas. 

RAID

Elegir un nivel correcto de RAID para nuestros duros también va  a marcar la diferencia de velocidad. No nos vamos a extender mucho en este tema pues ya le hemos dedicado un artículo completo en el blog hace pocos días. Os recomiendo su lectura si aún no lo habéis hecho.

Optimizaciones en SQL para reducir la E/S

Pero Roberto, mi servidor ya está montado y como DBA no tengo la posibilidad de modificar configuraciones de arquitectura de infraestructura. Tranquilos, jóvenes aprendices, no hace falta una herramienta descomunal para un resultado satisfactorio. Solo hay que saber usar bien lo que tenemos. Y sigo hablando de SQL, mal pensados. Esto que os voy a decir os va a parecer una obviedad, pero es la clave del éxito. Si tienes problemas con las lecturas en disco, haz menos lecturas en disco. Ahora te lo explico, no te preocupes. Menos lecturas en disco no significa que tengas que empezar a cortar el acceso a los usuarios o limitar las consultas, esto lo vamos a lograr con una serie de optimizaciones. 

Limpieza de datos

Esto es clave, todos tendemos a almacenar datos con una especie de síndrome de diógenes digital que de vez en cuando tenemos que evaluar. ¿Realmente necesitamos toda la información que estamos almacenando? En ocasiones estamos sometidos a unas regulaciones que nos implican una retención de los datos por varios años pero, si solo tenemos que almacenarlos y no se consultan, ¿qué hacen en la base de datos de producción? ¿Podrían irse a un backup y eliminarlos de la base de datos? Consulta con el responsable de los datos y el departamento legal si esto es posible.

Bases de datos histórico

Si los datos antiguos tienen pocas lecturas pero las suficientes como para no poder borrarse y almacenarse sólo en una copia de seguridad siempre podremos crear una base de datos de datos históricos y sacarlos de la base de datos principal. Dependiendo de la frecuencia de actualización de estos datos históricos, incluso podremos sacarlos del plan de mantenimiento de índices y de copias de seguridad diarios ahorrando tiempo y espacio y destinando esos recursos a los datos que realmente necesitamos. 

Particionado

El particionado de las tablas es otro potente recurso que tenemos a nuestra disposición para reducir el uso de lecturas en disco. Separando una tabla en distintas particiones, por ejemplo por fecha podremos reducir el número de páginas que SQL Server necesita consultar. Profundizaremos sobre este tema en un futuro artículo.

Índices

Después de ver que unos buenos índices son la solución a los problemas de alto consumo de RAM y de CPU si ahora os digo que también lo son a las lecturas en disco os va a parecer que los uso como un comodín para todo. Pero es que realmente unos buenos índices que cubran las consultas que ejecutamos nos ayudará a reducir el número de páginas leídas, reduciendo enormemente las necesidades de E/S. Y ese es el motivo subyacente por el que se cargan menos páginas en RAM y el procesador trabaja menos.

Conclusión

Los discos duros de nuestros servidores son el hardware más lento y donde almacenamos toda la información, eso los hace propensos de ser uno de los causantes más comunes de cuellos de botella para el rendimiento de nuestras consultas. Con unas buenas prácticas de implementación tanto de infraestructura como de arquitectura y modelado de los datos podemos reducir al mínimo este problema. Si te ha gustado esta serie de artículos dedicados a reducir incidencias de rendimiento por falta de recursos permanece atento al blog que mañana vamos a publicar la guía definitiva de creación de índices para solucionar los problemas.

Espero que este artículo te haya resultado útil e interesante. Si tienes alguna duda o comentario, no dudes en contactarnos en Twitter o por mail o dejarnos un mensaje en los comentarios de aquí abajo. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir.