¿A más procesadores consulta más lenta?

Que paradojas tiene la informática… tendemos a suponer que tener más procesadores tiende ha hacer que nuestros procesos se realicen más rápido, pero esto no es cierto. Un proceso expandido entre varios procesadores, siempre tardará más en realizarse que si se realiza en un único procesador. Esto no quiere decir que tener muchos procesadores no sea ventajoso, pues lo que permite es realizar muchas tareas a la vez, cada una será un poco más lenta, debido al tiempo que los cambios de contexto consumiran, pero sin embargo transcurrido un tiempo tendremos muchas más tareas completadas lo que hará que la velocidad percibida sea mucho mayor.

Hay una situación en la que este problema se puede hacer patente de una manera cuando menos sorprendente: al migrar nuestro servidor de bases de datos a un servidor con muchos más procesadores. Es relativamente habitual que, una consulta, que en una máquina de dos procesadores tarda un tiempo razonable, al migrar nuesto Sql Server a una máquina con más procesadores tarda mucho más en completarse. ¡Lo peor es que esta situación es principio es un sinsentido!, tengo más máquina y mi aplicación va más lenta…

Javier Loria, me explicaba en el Summit la situación de una manera muy gráfica: que es más facil, que una persona cante una canción o que lo hagan ocho. Evidentemente ocho se tendrán que poner de acuerdo en que parte cantar cada uno, y tendrán que poner atención en no pisarse. A Sql Server le pasa exactamente lo mismo. Cuando ocho procesadores intentan ejecutar la misma consulta puede ser que se molesten entre ellos, estas ‘molestias’ tienen su origen, habitualmente en que los diferentes hilos ‘pelean’ entre si por bloqueos, en esencia es un problema de bloqueos.

La solución simple, pero un poco chapucera es usar el hint MAXDOP en la consulta para limitar el número de procesadores que como máximo se utilizarán para ejecutar un consulta. Teneís más información sobre cómo usar MAXDOP en esta entrada del Knowledge Base.

La solución que debemos buscar es evitar que los diferentes hilos se molesten entre si y eso pasa por reducir la cantidad de bloqueos y la manera más simple de lograrlo es establecer los índices adecuados para la consulta. Como siempre vuelve a aparece aquí la importancia que los índices tienen para que nuestras bases de datos rindan perfectamente.

Otra moraleja clara de este asunto es que existen errores en diseño de base de datos (y en general en el diseño de aplicaciones) que no se arreglan poniendo más máquina.

6 comentarios sobre “¿A más procesadores consulta más lenta?”

  1. Al final de tu propia entrada tu mismo das la solución, pero en lugar del diseño de las bases de datos tenemos que aplicarla al SQL Server: mala programación del servidor. En primer lugar mala programación del núcleo que no sabe partirse entre procesadores correctamente, y en segundo lugar mala programación de la arquitectura o como se llame, porque si se sabe que eso ocurre la solución es muy sencilla: pipelinear las consultas (un procesador decodifica y genera el código, el otro lo procesa, el siguiente opera con los ficheros, de forma que casi tras el mismo tiempo hemos resuelto n-consultas en lugar de una sola), o que cada procesador ejecute aquellas consultas que no se interfieran entre sí (con un procesador para precalcular y ordenar -en fin, hacer un pipeline- las consultas).

  2. Pero, a ver, Rafael, en serio piensas que los ingenieros del motor de ejecución de consultas de SQL Server son unos patanes… a veces me sorprende tu prepotencia… creo que deberías ir a trabajar a Redmond y acabar con todos nuestros problemas como usuarios de productos de Microsoft.

    Bueno, dejar claro que al motor de SQL Server (y al de Oracle, que el problema es el mismo) no les pasa nada. El tema es esencial al multiproceso.

    El coste de los cambios de contexto tambien cuenta. Hay veces que hacer una consulta paralelizada en demasiados procesadores no compensa por el número de cambios de contexto, el problema es que esto no lo puede nunca saber a priori el motor de SQL Server, pues depende de un gran número de factores muy cabiantes en el tiempo.

    El otro tema es la contención, unos pasos de la consulta deben esperar por otros, esto es de cajón, y además comparten recursos (principalmente bloqueos), esto hace que no sirva un pipeline sin más, necesitas sincronizar los pasos pues no son independientes y lo que es más compartir ciertos recursos (bloqueos). De hecho en patrón pipeline es esencialmente secuencial, y solo es paralelizable si los pasos son independientes y uno no espera los resulados del siguiente.

    Por cierto, creo que debes hecharle un vistazo a Inside SQL Server 2000 (A fondo SQL Server 2000 en castellano), de Kalen Dalaney, antes de volver a hablar a la ligera. En concreto seguro que encuentras interesante el capítulo 3. Verás como los ingenieros de Microsoft han sido espectacularmente creativos a la hora de resolver los problemas relacionados con la multitarea y el multihilo en Sql Server. Incluso tiene su propio planificador a parte del que tiene el sistema operativo.

    Saludos!!!

  3. 🙂

    ¿A que jode que se metan contigo y te lleven la contraria en algo que tu sabes fehacientemente que es cierto?

    xDDDDDDDDDDDDDDDDDDDDDD.

    No te enfades, que ha sido una broma… Además, ni borracho de agua se me ocurriría ir a Redmond a currar, más que nada porque entonces se meterían conmigo en lugar de yo con ellos…

  4. Nada nuevo bajo el sol, el problema de la parelización de tareas esta más que estudiado en las facultades de Informática (podemos elegir entre 9 creditos de Word o 9 de Arquitecturas Paralelas) y no es en absoluto sencillo determinar que tareas se pueden paralelizar y cuales no.

    Si fuese facil ya tendriamos FrameWorks que lo harian automaticamente no? 😉

  5. «Si fuese facil ya tendriamos FrameWorks que lo harian automaticamente no? ;)»

    Pues con el .NET es toda una gozada (¿He dicho yo eso? xDDDDD) trabajar con hilos… así que imagino que pasito a pasito…

    «podemos elegir entre 9 creditos de Word o 9 de Arquitecturas Paralelas»

    Estooooo… Ahora entiendo por qué tanta gente sabe manejar el Word y el SQL funciona tan mal… xDDDDDDDDDD. Yo hubiera elegido sin pensármelo los créditos de Arquitecturas Paralelas, pero conociendo a la gente…

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *