Lidiar con un servidor que parece drásticamente sub-potenciado puede causar frustración en todos lados. Afortunadamente, afinar los índices puede resultar en fantásticas ganancias de rendimiento.
Como parte de lo que hago, veo tantas configuraciones diferentes de SQL Server en uso por los clientes. Sólo en las últimas semanas, he visto versiones de SQL Server desde 2000 hasta la última y más grande, 2014. Los clientes tienen diferentes requerimientos y expectativas para cada instancia de SQL Server que tienen en funcionamiento, y eso mantiene mi trabajo interesante. Recientemente ayudé con dos servidores diferentes que pensé que estaban muy poco potentes, incluso me sorprendió cómo un pequeño ajuste podía hacer una diferencia tan grande en el rendimiento. Aquí hay un rápido desglose de lo que hice, y cómo puedes hacerlo también.
Servidor1
Admito que me sorprendió descubrir que Server1 estaba ejecutando SQL Server 2005 Standard Edition en Windows Server 2003 de 32 bits. SQL Server es intensivo en memoria, y esta configuración sólo soporta 2 GB de RAM.
Migrar a un nuevo hardware o a una máquina virtual y actualizar el servidor SQL, el sistema operativo y las aplicaciones no se logrará rápidamente, pero son planes a largo plazo. Este cliente esperaba que pudiera encontrar una forma de eliminar los frecuentes tiempos muertos que experimentaba la aplicación principal. Después de algunos cambios de configuración, el cliente me pidió que me concentrara en las consultas que se habían agotado o que habían tardado más de un minuto en ejecutarse. Podría haber sugerido cambios en el índice porque se podrían ejecutar rápidamente, pero cualquier cambio de código tendría que esperar, así que no los sugerí.
Al recomendar sólo unos pocos cambios de índice para eliminar los escaneos de índice agrupados y las búsquedas clave en las 15 principales consultas, la aplicación funcionó mucho mejor. También descubrí que con sólo cambiar un índice, se podían mejorar dos o tres consultas diferentes. La frecuencia de los tiempos de espera disminuyó drásticamente, y el cliente está muy contento con lo que hemos logrado.
Servidor2
La base de datos principal del Server2 tiene un tamaño superior a un terabyte y crece a medida que se importan nuevos datos cada mes. Esta base de datos no se utiliza todos los días, pero cuando lo hace, ejecuta un proceso por lotes que realiza cálculos sobre cientos de miles de filas, tardando minutos en completarse. La tabla principal tiene más de seis mil millones de filas. Las actualizaciones y eliminaciones deben hacerse con cautela para evitar bloquear el servidor.
En el mundo actual de las bases de datos, una base de datos de terabytes no es inusual. Lo que es inusual, sin embargo, es que el servidor (que se ejecuta en una máquina virtual) sólo se le asignó 16 GB.
Revisé el servidor y señalé los cambios de configuración más comunes, pero pasé la mayor parte del día hablando con el CIO y el arquitecto de software sobre índices, partición y compresión. Al hacer un cambio en un solo índice, fueron capaces de disminuir el tiempo del proceso por lotes de tres minutos a unos 10 segundos.
También miramos las funciones definidas por el usuario. La característica de la función definida por el usuario es atractiva para los desarrolladores, pero a menudo es la fuente de problemas de rendimiento ocultos. En este caso, el código llamaba miles de veces a la misma función que contenía una llamada a la base de datos con los mismos parámetros. Al usar Profiler, les mostré que SQL Server no guardaba el valor devuelto, sino que determinaba el valor una y otra vez. Había varias capas de UDFs, pero experimentamos eliminando sólo una y así, vimos una mejora del 25 por ciento.
Sólo un par de días después, el cliente decidió aumentar la cantidad de RAM a 48 GB. No estaban seguros de que aumentar la memoria fuera realmente tan beneficioso, ya que cada ejecución del proceso accedería a diferentes datos… por lo que las páginas en caché no ayudarían realmente. Sin embargo, noté que el índice de aciertos del buffer cache estaba disminuyendo al 20 por ciento y la expectativa de vida de la página estaba tocando fondo cada vez que el proceso se ejecutaba en ese primer día; un signo seguro de la presión de la memoria. Tal vez estén en lo cierto; 48 GB puede que no sea muy diferente de 16 GB en esta situación.
La división y la compresión podrían ayudar aquí. Este servidor no está en la Enterprise Edition, pero hablamos de crear un prototipo en la Developer Edition para probar mi teoría. La compresión disminuiría los requerimientos de almacenamiento y mejoraría el rendimiento en esta carga de trabajo de lectura. El particionamiento mejoraría la carga y el borrado de datos y proporcionaría un aumento en el rendimiento de las consultas también. Estas dos características funcionan bien juntas, ya que las particiones pueden ser comprimidas individualmente en diferentes niveles dependiendo de la frecuencia de las actualizaciones.
Para llevar
Si se trata de un servidor que parece tener poca potencia, intente ajustar los índices antes de tomar medidas más drásticas. Puede que te sorprendas tanto como yo al descubrir la gran diferencia que puede suponer.
Contenidos