Mejores prácticas de paralelismo

¿Cuáles son las mejores prácticas para establecer paralelismo en general? Sé que SQL Server 0usa de manera predeterminada todos los procesadores disponibles, pero ¿en qué caso le gustaría cambiar este comportamiento predeterminado?

Recuerdo haber leído en alguna parte (tendré que buscar este artículo) que para las cargas de trabajo OLTP debe desactivar el paralelismo (establezca maxdop en 1). No creo entender completamente por qué harías esto.

¿Cuándo mantendría maxdop hasta SQL Server (0)? ¿Cuándo apagarías el paralelismo (1)? ¿Cuándo declararías explícitamente el maxdop a un número particular de procesadores?

¿Qué causa el paralelismo?

Por lo general, no desea deshabilitar el paralelismo, ya que eso también lo deshabilitará para las tareas de administración. Su mejor opción es corregir las consultas que están causando el paralelismo agregando o arreglando índices o completando los cambios de esquema.

Según sus preguntas actualizadas ...

Algunas personas cambiarán MAXDOP a 1 para las aplicaciones creadas por el proveedor porque no pueden controlar la base de datos o el esquema y no desean que una sola consulta se haga cargo de todo el sistema.

Personalmente, siempre mantengo MAXDOP en 0, excepto en algunos casos raros.

El paralelismo es causado por una sola operación dentro de un plan de ejecución que tiene un costo de ejecución que supera una configuración preestablecida (el umbral de costo para la configuración del paralelismo). Cuando esto sucede, el Servidor SQL iniciará el paralelismo para que pueda enhebrar la solicitud en un intento de acelerar el proceso. El valor predeterminado para el umbral de costo para el paralelismo es 5. En muchas plataformas OLTP, querrá elevarlo hasta 30 o 40 para que el paralelismo solo sirva para las consultas realmente costosas.

Nunca he visto la necesidad de apagar o modificar ninguna configuración de paralelismo en todo mi tiempo con SQL Server (último milenio, SQL Sever 6.5)

Siguiendo con la respuesta de @StanleyJohns ...
Un sistema OLTP con consultas cortas y agudas nunca debería alcanzar el umbral de costo ( "umbral de costo para paralelismo" ), por lo que no debería importar. Si tiene algunas consultas que van paralelas, ¿por qué lo restringiría en función de algo no comprobado?

Todavía tengo que ver un sistema OLTP puro también. En el extremo, tal vez los hay, pero el sistema promedio también tiene informes al respecto; ya sea durante el día o durante la noche. Es más probable que estas consultas sean paralelas y se beneficien de ello.

Con tantos núcleos de CPU disponibles en la actualidad, podría decirse que existe un caso para establecer el "grado máximo de paralelismo" global si puede medir y notar una diferencia.

Como dije, mi sugerencia es no hacer nada . Similar a @mrdenny, pero incluiría "no existe un sistema OLTP puro"

Dicho esto, puede haber algo de kilometraje que deshabilita los núcleos hiperprocesados ​​a nivel de BIOS, pero esa es una pregunta diferente ...

Además, por favor vea

• mi docena más o menos SO responde: https://stackoverflow.com/search?tab=votes&q=user%3a27535%20parallelism
• Procesamiento de consultas paralelas en MSDN

¿Qué causa el paralelismo ?: Hay un ajuste llamado cost threshold for parallelism. Una vez que se supera este umbral, se utiliza el paralelismo (si se cumplen los requisitos previos).

La naturaleza de un sistema OLTP es tener una gran cantidad de transacciones rápidas y cortas. El uso del paralelismo a veces aumenta el tiempo de procesamiento de la consulta, ya que la consulta se dividirá para procesarse en paralelo y luego se unirá nuevamente antes de ser devuelta. Por lo tanto, verá sugerencias para establecer maxdop en 1.

Una ventaja de establecer maxdop en 1 es que el paralelismo está desactivado de forma predeterminada, pero puede habilitarlo en el nivel de consulta mediante query hints.

Para los sistemas de almacenamiento de datos o sistemas OLAP donde se devuelven conjuntos de resultados grandes, puede ser beneficioso dividir la consulta usando paralelismo. Esto permite que la consulta aproveche los núcleos disponibles para reducir el tiempo de procesamiento de la consulta.

He visto una consulta compleja dividida en múltiples procesos que tarda horas en ejecutarse; por lo general, puede ver esto en sp_who2 como entradas múltiples con el mismo spid.

Cambiándolo a maxdop 1 y la consulta se ejecutó en menos de un minuto.

La lección aquí es que el motor no siempre funciona correctamente cuando se trata de paralelismo.

Tenemos muchos servidores con 4 núcleos y algunos con 8 núcleos. Recomiendo con tan pocos núcleos que el paralelismo (MAXDOP) se establezca en 1 para evitar esperas en la CPU (y también problemas de tiempo de espera) para los usuarios de sistemas OLTP. Para OLAP o servidores de informes, con tan pocos núcleos, recomiendo establecer MAXDOP en 2 y establecer el Umbral de costos en 30 (esto puede ser más alto o un poco más bajo para su escenario) para que solo las consultas más pesadas usen paralelismo.