Paralelismo en SQL Server


El máximo grado de paralelismo, es como su nombre lo indica una medida que nos indica cuantos procesadores podemos usar, hoy en día es bastante común que un servidor (una pc o hasta una laptop) tenga varios procesadores físicos, SQL Server puede utilizar tantos como el servidor tenga y la licencia lo permita.

Pero por cuestiones de que Microsoft no conoce las configuraciones y ambientes de cada cliente, tiene que existir un valor por defecto en este caso seria 0, que es sin máximo y dejar que SQL Server lo administre, ahora bien esto es perfecto y uno supondría que siempre abría una ganancia en cuanto al desempeño al dejar que el servidor use tantos procesadores le sea posible, lamentablemente esto no es así en la vida real y puede acarrear problemas si los índices no están implementados o las consultas no son óptimas, y en algunos casos lo que se usa es como una instancia transaccional (OLTP), por lo cual el uso de paralelismo no brinda una ganancia sino solo un retraso ya que las instrucciones llegar de manera serializable (necesita terminar una para ejecutar otra).

Entonces, cual es el mejor valor... no se sabe, cada servidor tiene un comportamiento propio y que debe de ser evaluado por el administrador de base de datos u encargado de la misma. Hay que ser muy precavidos de que los procesadores deben ser físicos y no virtualizados (Hyperthreading).

  • Para 1 procesador o servidores transaccionales, así como SharePoint (1).
  • Por cada 2 procesadores 1 nivel de paralelismo.
  • Máximo 8 en el nivel de paralelismo.
  • El número máximo de paralelismo no debe ser mayor al numero de core físicos por nodo NUMA. 

Esto está relacionado en parte con el "Max threashold of parallelism" y aunque Microsoft recomienda no mover este valor de 5, el cambiarlo con conocimiento puede mejorar el desempeño del servidor, de la misma manera que un cambio sin conocimiento puede degradar su desempeño.

Como anécdota me encontré hace poco un cliente que había bajado este valor a 0 y puesto el paralelismo en 12, lo cual generaba que todo query fuera en paralelo y bloqueaba la base creando constantes cadenas de bloqueo.

Para cambiarla puede ser por medio de un query

sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 8;
GO
RECONFIGURE WITH OVERRIDE;
GO
 

O por medio de las propiedades de la instancia:

 

Más información:
 
https://technet.microsoft.com/en-us/library/ms181007

Ediciones:
Se quito la parte que hacia referencia al hyper threading como limitante, esto es solo para máquinas hechas antes del 2008.

Comentarios