Infra

La mayoría de las empresas que trabajan con SQL Server no tienen ni la más remota idea de lo que les cuesta no optimizar sus consultas. Y no, no hablo de la típica pérdida de rendimiento que molesta al usuario de vez en cuando. Hablo de dinero. Del que se escapa cada mes por la rendija del servidor porque nadie se molestó en revisar ese SELECT con JOIN cruzado que parece escrito por un algoritmo con ganas de venganza.

Pero vamos por partes. Porque el drama tiene capítulos, y todos salen caros.

Hardware: más coste para hacer lo mismo (o menos)

Cuando una consulta no está optimizada, lo primero que pide el sistema es más CPU. Más RAM. Más disco. Y como somos humanos, y a veces un poco vagos, el primer impulso es escalar verticalmente: poner más hierro. Total, si ya funciona mal, con más recursos irá mejor, ¿no?

Pues sí. Durante un rato. Luego viene otra consulta igual de mala y vuelta a empezar. El patrón es de sobra conocido: base de datos lenta, compras hardware, mejora temporal, vuelve la lentitud, compras más hardware… y cuando te das cuenta, estás alimentando un monstruo que vive de cores, GB y licencias.

Y aquí entra la broma que siempre duele: SQL Server se licencia por core. Así que cada vez que decides “arreglar” un problema de rendimiento añadiendo CPU, estás aceptando voluntariamente pagar más en licencias, que no son baratas. Es como combatir la sed bebiendo agua salada: parece que ayuda, pero en realidad te estás hundiendo más.

Por favor, deja este campo vacío

Únete a la newsletter de SoyDBA

Regístrate gratis para no perderte ninguna novedad. Te avisaré de noticias y eventos importantes

¡No hacemos spam! Lee nuestra política de privacidad para obtener más información.

Revisa tu bandeja de entrada para confirmar tu suscripción. Si no ves el correo revisa la carpeta de spam.

El coste real en la nube: «elástico», sí, pero hacia arriba

Muchos creen que al migrar a la nube el problema desaparece. Que Azure SQL, AWS RDS o cualquier plataforma PaaS mágica va a solucionar lo que tu SELECT * no quiso arreglar. Y no, no es así.

En la nube todo se factura. Cada milisegundo de CPU, cada MB de RAM, cada GB de almacenamiento y cada IO de disco. Una consulta ineficiente en Azure no solo es lenta: es cara. Muy cara. Porque, a diferencia de tu servidor físico en el CPD, aquí no tienes un coste hundido. Aquí cada operación se convierte en un apunte contable. Y si te pasas, la factura no perdona.

He visto clientes triplicar su consumo mensual de Azure SQL sin añadir ni un solo usuario más. ¿La causa? Un informe mal diseñado, una vista que arrastra medio millón de registros y un desarrollador con más entusiasmo que criterio.

Una historia real de coste en azure

Y luego están los casos como este. Años atrás, un cliente me llamó porque su Azure SQL Managed Instance con 8 cores (unos 1.355€ al mes) tenía la CPU por encima del 90% casi todo el día, con picos constantes al 100% que parecían avisos de incendio. Lo más grave no era eso, sino que ya habían asumido que la única salida era duplicar recursos y pasar a 16 cores, lo que dispararía la factura a 2.700€/mes. Antes de firmar el salto, decidieron llamarme. Por suerte.

Lo que me encontré era un festival del despropósito. Ni un solo índice clustered, todos los índices nonclustered eran de una sola columna y, por supuesto, sin INCLUDE. Mirando el uso, el 95% de esos índices no se usaban. Y claro, la DMV de índices faltantes parecía la lista de tareas de un becario sin supervisión: infinita, desordenada y sin lógica.

Con un par de días de trabajo serio (revisión de patrones de consulta y una política de indexación con sentido común) no solo evitamos el escalado, sino que redujimos la instancia a 4 cores. El resultado fue sorprendente, CPU estable al 30% incluso en horas pico. Lo que se dice, respirar. Pero además, más de 25.000€ al año de ahorro respecto a la solución que estaban a punto de contratar.

El coste del “Pero si se lanza una vez al año…”

Ya que me he puesto en plan cuentacuentos, déjame contarte otra de esas anécdotas que se graban a fuego.

Un día me encontré con un informe, hecho en Tableau (pero eso es lo de menos), que lanzaban una vez al año y que tardaba en completarse… 22 horas. Bueno, yo lo pillé cuando llevaba 22 horas de ejecución en el SQL Server de producción, a saber cuánto más le quedaba. Cuando lo comenté, me dijeron que no pasaba nada, que solo se lanzaba una vez al año y que solían dejarlo corriendo de un día para otro, como quien pone la olla lenta con garbanzos.

Pero yo lo vi claro. La consulta tenía 47 subconsultas en el SELECT. Si, si, CUARENTA Y SIETE. No índices raros, no estructuras marcianas, solo una estructura de consulta absurda.

¿El cambio? Reescribir con LEFT JOIN bien definidos en lugar de esas subconsultas incrustadas. Nada más. Bueno si, una subconsulta que se repetía bastantes veces muy parecida se persistió como temporal al inicio del proceso. De esa manera los datos se leian y filtraban de una tabla grande una sola vez y se quedaban en una tabla pequeña para consultar el resto de las veces. Pero nada más, ni cambiar índices, ni tocar el esquema. Vamos, sin reformar la casa. ¿El resultado? Menos de 20 milisegundos.

Y esto amigos, esto no es una mejora. Eso es pasar de enviar la consulta en burro a ponerle un cohete. Y no exagero.

Porque no todo el coste es culpa del desarrollador

No vamos a demonizar. Todos hemos escrito consultas que después nos dieron vergüenza ajena. Y sí, hay veces que las prisas, las entregas y los deadlines te llevan a empalmar un par de subconsultas “de emergencia” con un UNION sin ALL y a mirar para otro lado.

Pero eso no justifica dejar ese código en producción durante años como si fuera parte del mobiliario. Porque esa consulta, aunque solo se ejecute una vez al día, puede ser la responsable de saturar el servidor, disparar el DTU en Azure o arrastrar a otras aplicaciones con ella.

Aquí entra en juego lo que me gusta llamar “el coste invisible de la desidia técnica”. No se ve, no se presupuesta, pero se paga igual. En horas de soporte, en tiempo perdido, en usuarios frustrados, en reputación quemada.

De 10 minutos a 2 milisegundos (sin efectos especiales)

Otra historia real, por si alguien aún cree que exagero.

Me llama un cliente porque un proceso tarda más de 10 minutos. Revisamos el plan de ejecución y canta como un tenor: falta un índice. Literalmente lo está pidiendo a gritos. Un Clustered Index Scan sobre una tabla de 10 millones de registros con 5 campos varchar(max).

Creamos un índice sencillo sobre los dos campos que busca… y bajamos a 20 segundos. Bien, ¿no?

Pero no me conformé. Me di cuenta de que esos campos varchar(max) apenas se usaban y propuse moverlos a otra tabla. Un cambio mínimo de esquema, sin traumas. El resultado: la consulta se resuelve ahora en 2 milisegundos.

Sí, de más de diez minutos a dos milisegundos. Sin comprar licencias, sin añadir cores, sin tirar la casa por la ventana. Solo sentido común.

Consultas eficientes, bases de datos rentables

Optimizar una consulta no es hacer magia negra ni sacrificar cabras sobre el plan de ejecución. Es técnica, análisis y experiencia. A veces basta con añadir un índice. O con quitar un SELECT * y poner solo las columnas que necesitas. O con evitar ese cursor que llevas arrastrando desde hace 10 años como si fuera un trauma sin resolver.

Una consulta optimizada no sólo corre más rápido. Consume menos CPU. Bloquea menos. Permite que más usuarios trabajen al mismo tiempo. Y, lo más importante, reduce directamente tu coste de infraestructura y licenciamiento.

No es filosofía, son matemáticas puras, si una consulta tarda 500 ms y logra pasar a 50 ms, puedes hacer 10 veces más operaciones con los mismos recursos. ¿Te imaginas que tu equipo hiciera 10 veces más tareas al mismo sueldo? Eso es lo que hace una base de datos bien afinada.

El coste del «si funciona, no lo toques»

Una de las excusas más repetidas cuando se habla de optimizar es: “Pero si ya funciona, ¿para qué meternos ahí?” Pues por eso mismo. Porque ahora va, pero mal. Y cada día que pasa, cada usuario que se conecta, cada nuevo informe que se genera, lo hace un poco peor.

La deuda técnica no caduca. Se acumula. Y cuando salta, no lo hace con un error bonito y fácil de arreglar. Lo hace con un rendimiento desastroso en el peor momento: justo antes del cierre contable, durante el Black Friday o cuando el CEO quiere ver “cómo va todo” desde Power BI (todo casos reales).

Si optimizar parece caro, espera a ver cuánto cuesta no hacerlo.

Formación, experiencia y algo de mala leche

Sí, optimizar lleva tiempo. Requiere saber leer planes de ejecución, entender estadísticas, conocer cómo SQL Server decide qué estrategia usar y cuándo. Pero también requiere actitud. Ganas de escarbar. De no conformarse con que funcione “más o menos”.

Y eso, lamentablemente, no lo da ningún botón mágico ni el asistente del Management Studio. Hay que aprenderlo. O contratar a alguien que lo sepa.

Aquí es donde entra mi parte, claro. No solo como autor de este blog, sino también como consultor. Llevo más de 12 años viendo barbaridades que harían llorar al optimizador de consultas. Y ayudando a equipos a entender por qué sus bases de datos son lentas, y cómo hacer que dejen de serlo sin hipotecar la nube ni sacrificar fines de semana enteros en tareas de mantenimiento que no deberían existir.

Y sí, estoy escribiendo un libro

Mi libro se va a llamar “SQL SERVER: La NO guía práctica de optimización”. Y no será el típico tocho con recetas milagrosas genéricas que nadie es capaz de aplicar en producción. Será un manual honesto, directo y realista. Uno que explica cómo optimizar sin morir en el intento, desde la base y comprendiendo el funcionamiento interno del motor de base de datos. Porque ya tenemos demasiadas presentaciones bonitas que no dicen nada.

Y sí, también haré formación. Y talleres. Y sesiones donde, si hace falta, nos peleamos con los planes de ejecución hasta que canten. Porque se puede. Porque debe hacerse. Y porque seguir pagando licencias por no optimizar… simplemente no tiene sentido.

¿Quieres dejar de pagar por no saber? Hablemos.

Si después de leer esto has pensado en esa consulta que lleva años sin tocar, en ese informe que tarda 12 minutos, o en ese servidor que cada semana pide más cores como si fueran cromos… ya sabes lo que hay.

Puedes seguir ignorándolo, puedes aprender cómo optimizar SQL Server o puedes llamarme y lo miramos juntos.

Tu factura lo va a notar.

Hay palabras que, al oírlas, nos ponen en guardia. “NUMA” es una de ellas. No porque suene peligrosa, sino porque suele venir envuelta en conceptos vagos y soluciones mágicas a problemas que no entendemos del todo. Pero no nos engañemos: si administramos SQL Server sobre hardware serio (y no sobre portátiles reciclados con Docker “porque mola”), entender cómo se comporta la arquitectura NUMA no es opcional. Es imprescindible.

¿Qué es NUMA? Una ciudad con barrios.

NUMA (Non-Uniform Memory Access) es una arquitectura de memoria en la que cada CPU (o grupo de CPUs) tiene acceso preferente a un bloque de memoria. A este conjunto se le llama nodo NUMA. Sí, se puede acceder a la memoria de otros nodos, pero es más lento. Y en un mundo donde las latencias de microsegundos importan más que los deadlines de los Project Managers, eso no es un detalle menor.

Puede parecer lioso pero vamos a verlo en una imagen para que no haya dudas. Realmente todo esto no es algo abstracto, viene directamente definido a nivel hardware. Las placas base de los servidores tienen varios socket de procesadores y, cada uno de ellos, tiene unos slots de RAM más cercanos a los que accede con menor latencia.

Aquí, por ejemplo, vemos dos sockets físicos, cada uno con 8 núcleos y 128 GB de RAM. Cada socket está conectado a su propia porción de memoria. Esto es lo que llamamos una arquitectura NUMA: cada CPU accede más rápido a su “propia” memoria que a la del otro socket. Y sí, como os decía, un procesador puede acceder a la memoria del otro, pero con más latencia. Cómo cruzar la ciudad para ir al mercadona de otro barrio teniendo uno en el tuyo, se puede, pero no es lo ideal.

SQL Server es plenamente NUMA-aware desde hace muchas versiones. Y no es solo marketing. El motor entiende esta arquitectura y la usa para optimizar la asignación de memoria, la ejecución de tareas en paralelo y la gestión de schedulers. Todo esto siempre y cuando no le pongamos la zancadilla con configuraciones absurdas.

Planificación y schedulers: cómo SQL Server reparte el trabajo

Cada nodo NUMA tiene un conjunto de schedulers, que no son otra cosa que planificadores de hilos (threads). Para ser lo más eficiente posible, SQL Server intenta ejecutar los hilos en el mismo nodo donde se asignaron, y acceder a la memoria local del mismo. Si la información está bien distribuida, esto reduce el tráfico entre nodos y mejora la latencia general. Pero si metemos la pata, por ejemplo fijando la afinidad de forma manual y sin criterio, podemos forzar al motor a comportarse como un repartidor de pizzas desorientado: yendo de un barrio a otro sin sentido y perdiendo tiempo en cada esquina.

Además, cada instancia de SQL Server crea un grupo de trabajo por cada nodo NUMA visible. Y si usamos el modo de memoria comprimida, las decisiones de qué nodo usa qué buffer pool se vuelven aún más relevantes. Ignorar esto es como jugar al ajedrez sin mirar el tablero. Puede parecer divertido, pero termina mal.

El efecto de un mal diseño NUMA

Cuando un servidor tiene múltiples sockets físicos, es muy probable que cada socket represente un nodo NUMA. Pero algunos sistemas operativos y BIOS permiten desactivar o modificar esta topología. Resultado: servidores con 256 núcleos que se ven como un único nodo NUMA. ¿Y eso qué implica? Pues, para empezar, que SQL Server no puede distribuir sus schedulers de forma eficiente. El escalado se resiente, la contención de recursos aumenta y las consultas paralelas empiezan a hacer cosas raras.

¿Has visto alguna vez una consulta que parece ir más lenta cuanto más CPUs tiene disponibles? Bienvenido al infierno del mal NUMA. Y sí, hay admins que creen que poner más CPUs siempre mejora el rendimiento. También hay quien piensa que una tabla de log no necesita índices. Vivir para ver.

Las virtualizaciones y sus trampas con NUMA

Ah, la virtualización. Ese mundo donde puedes tener 64 vCPU repartidas en 2 nodos NUMA virtuales y no saber por qué tu SQL Server tiene el rendimiento de un 486 con resaca. Los hipervisores serios (como VMware, Hyper-V o, incluso, Proxmox) permiten configurar el número de nodos NUMA expuestos a la máquina virtual. Pero si dejas esto en manos de un “especialista” que nunca ha leído una página del “whitepaper de arquitectura NUMA en SQL Server” (sí, no solo existe, cada fabricante tiene uno propio), lo normal es que termines con un entorno virtualizado más caótico que una tabla sin clave primaria.

Por eso, cuando trabajamos con entornos virtualizados, conviene revisar cuidadosamente cómo están asignados los núcleos físicos, cuántos nodos NUMA ve la VM y cómo se está presentando la memoria. SQL Server lo detectará, pero no puede arreglar por sí solo una chapuza.

¿Y qué hay del NUMA en SQL Server en Azure?

Pues aquí el tema se vuelve más oscuro. Microsoft no publica (con detalle) la topología NUMA exacta de sus VMs, pero en general puedes asumir que, en las series más potentes, hay más de un nodo. Las VMs con más de 16 vCPU casi siempre están divididas en al menos dos nodos NUMA virtuales. ¿Cómo lo comprobamos? Ejecutando SELECT * FROM sys.dm_os_nodes y observando el campo memory_node_id. Si ves más de un nodo con memory_node_id distinto de 64 (el de DAC), estás en terreno NUMA.

Por tanto, cuando afinamos instancias en Azure, conviene monitorizar la distribución de la carga entre nodos. A veces, ciertas consultas intensivas pueden estar trabajando siempre sobre el mismo nodo, provocando un cuello de botella local mientras el resto del servidor está de paseo.

Configuraciones de NUMA recomendadas

Si el servidor tiene una topología NUMA bien definida, lo mejor que podemos hacer es dejar que SQL Server gestione sus schedulers y memoria. No toques la afinidad de CPU salvo que tengas un motivo muy claro. Y por favor, no uses MAXDOP sin entender cómo afecta a los nodos. Un mal MAXDOP puede anular por completo los beneficios de NUMA, provocando saltos de memoria y escalado ineficiente.

También hay que considerar Resource Governor, que puede fijar workloads a ciertos nodos, o las nuevas opciones de Soft-NUMA (a partir de SQL Server 2016), útiles cuando el hardware ofrece más núcleos por nodo de los que SQL Server gestiona de forma eficiente por defecto.

Y si alguien propone usar lock pages in memory sin revisar la topología NUMA antes, haceos un favor: quitadle los permisos.

Conclusión

NUMA no es un problema. Es una característica muy potente. Pero como toda característica avanzada, si no la entendemos puede convertirse en un dolor de cabeza. En entornos de producción con alta carga, especialmente con muchos núcleos y grandes volúmenes de memoria, ignorar NUMA es como hacer tuning con los ojos vendados.

La solución no es complicarse la vida configurando todo a mano sin necesidad, sino entender cómo se comporta SQL Server en nuestro entorno y dejar que optimice… siempre que el terreno no esté lleno de minas.

No lo digo yo, lo dice la ciencia.

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.