Melhores práticas de paralelismo

Quais são as melhores práticas para definir o paralelismo em geral? Eu sei que o SQL Server usa como padrão 0todos os processadores disponíveis, mas em que instância você deseja alterar esse comportamento padrão?

Lembro-me de ler em algum lugar (precisarei procurar este artigo) que, para cargas de trabalho OLTP, você deve desativar o paralelismo (defina maxdop como 1). Acho que não entendo completamente por que você faria isso.

Quando você manteria o maxdop no SQL Server (0)? Quando você desligaria o paralelismo (1)? Quando você explicitamente declararia o maxdop para um número específico de processadores?

O que causa o paralelismo?

Você geralmente não deseja desativar o paralelismo, pois isso também o desativará para tarefas administrativas. Sua melhor aposta é corrigir as consultas que estão causando o paralelismo, adicionando ou corrigindo índices ou fazendo alterações completas no esquema.

Com base nas suas perguntas atualizadas ...

Algumas pessoas alteram o MAXDOP para 1 para aplicativos criados pelo fornecedor, porque não podem controlar o banco de dados ou esquema e não desejam que uma única consulta assuma o controle de todo o sistema.

Pessoalmente, eu sempre mantenho o MAXDOP em 0, exceto em alguns casos raros.

O paralelismo é causado por uma única operação em um plano de execução com um custo de execução que ultrapassa uma configuração predefinida (o limite de custo para a configuração de paralelismo). Quando isso acontece, o SQL Server inicia um paralelismo para que ele possa multiencadear a solicitação na tentativa de acelerar o processo. O valor padrão para o limite de custo do paralelismo é 5. Em muitas plataformas OLTP, você desejará aumentar esse número para 30 ou 40, para que o paralelismo apenas entre nas consultas realmente caras.

Eu nunca vi a necessidade de desligar ou modificar as configurações de paralelismo o tempo todo com o SQL Server (último milênio, SQL Sever 6.5)

Seguindo a resposta da @StanleyJohns ...
Um sistema OLTP com consultas curtas e nítidas nunca deve atingir o limite de custo ( "limite de custo para paralelismo" ), portanto não deve importar. Se você tiver algumas consultas paralelas, por que você a restringiria com base em algo não comprovado

Ainda estou para ver um sistema OLTP puro também. No extremo, talvez exista, mas o sistema médio também apresenta relatórios; seja intra-dia ou durante a noite. É mais provável que essas consultas sejam paralelas e se beneficiem dela.

Atualmente, com tantos núcleos de CPU disponíveis, é possível definir o "grau máximo de paralelismo" global se você puder medir e notar uma diferença.

Como eu disse, minha sugestão é não fazer nada . Semelhante ao @mrdenny, mas incluiria "não existe um sistema OLTP puro"

Dizendo isso, pode haver alguma quilometragem desativando núcleos com hyperthread no nível do BIOS, mas essa é uma pergunta diferente ...

Além disso, consulte

• mais ou menos uma dúzia de respostas SO: https://stackoverflow.com/search?tab=votes&q=user%3a27535%20parallelism
• Processamento de consultas paralelas no MSDN

O que causa o paralelismo ?: Existe uma configuração chamada cost threshold for parallelism. Depois que esse limite é excedido, o paralelismo é usado (se os pré-requisitos forem atendidos).

A natureza de um sistema OLTP é ter um grande número de transações rápidas e curtas. Às vezes, o uso do paralelismo aumenta o tempo de processamento da consulta, pois a consulta será dividida para ser processada em paralelo e depois unida novamente antes de ser retornada. Portanto, você verá sugestões para definir o maxdop como 1.

Uma vantagem de definir maxdop como 1 é que o paralelismo está desativado por padrão, mas você pode ativá-lo no nível da consulta usando query hints.

Para sistemas de armazém de dados ou sistemas OLAP em que grandes conjuntos de resultados são retornados, pode haver um benefício em dividir a consulta usando paralelismo. Isso permite que a consulta aproveite os núcleos disponíveis para reduzir o tempo de processamento da consulta.

Vi uma consulta complexa dividida em vários processos que leva horas para ser executada - normalmente você pode ver isso em sp_who2 como várias entradas com o mesmo spid.

Alterando-o para maxdop 1 e a consulta executada em menos de um minuto.

A lição aqui é que o mecanismo nem sempre acerta quando se trata de paralelismo.

Temos muitos servidores com 4 núcleos e alguns com 8 núcleos. Eu recomendo com tão poucos núcleos que o paralelismo (MAXDOP) seja definido como 1 para evitar esperas na CPU (e também problemas de tempo limite) para usuários de sistemas OLTP. Para servidores OLAP ou de relatório, com tão poucos núcleos, recomendo configurar MAXDOP como 2 e Cost Cost threshold como 30 (isso pode ser maior ou um pouco menor para o seu cenário), para que apenas as consultas mais pesadas usem paralelismo.