Por que a configuração do SQL Server recomenda o MAXDOP 8 aqui?

A configuração está recomendando MAXDOP 8

A instalação calcula o MAXDop da seguinte forma:

Step 1: Calculate Hardware NUMA and Soft NUMA
Step 2: Decide whether Hardware or Soft NUMA will be used
Step 3: Divide the total logical processors by the NUMA used
Step 4: If > 15 LPs/NUMA, MAXDop = (LPs/NUMA)/2, otherwise MAXDop = LPs/NUMA

No seu caso específico:

64 LPs total
HW NUMA = 2
Soft NUMA = 4

Soft NUMA será usado, 64 LPs/4 (Soft) = 16. 16 > 15, pegue 16 / 2 = 8.

Se as pessoas concordam com o /2 extra ou não, dado >15 LPs/NUMA é um ponto de discussão. Independentemente disso, é o que existe atualmente e se encaixa nas recomendações do artigo MSDN TechNet BOL Docs Learn.

Entendo seu desejo de entender por que a configuração do SQL Server está recomendando 8 para MAXDOP. Infelizmente, sob condições padrão (auto soft-NUMA habilitado), a documentação recomendará um intervalo aceitável para MAXDOP para quase todos os servidores em vez de um valor único exato.

A documentação diz o seguinte:

O nó NUMA na tabela acima refere-se a nós soft-NUMA criados automaticamente pelo SQL Server 2016 (13.x) e versões superiores, ou nós NUMA baseados em hardware se o soft-NUMA tiver sido desabilitado.

Seu servidor tem dois soquetes com hyperthreading habilitado. Existem 16 núcleos físicos por soquete e 32 núcleos lógicos por soquete. Auto soft-NUMA também está habilitado. Aqui está um gráfico estimado de como o auto soft-NUMA lida com essa situação, com a coluna A como o número de agendadores por soquete:

Para o seu servidor, você terá 4 nós soft-NUMA de 16 processadores lógicos cada. Isso significa que a orientação da linha 3 se aplica à sua situação:

Mantenha MAXDOP igual ou abaixo de # de processadores lógicos por nó NUMA

Um valor MAXDOP de 8 é menor que seu valor de 16 processadores lógicos por nó soft-NUMA, portanto, não há conflito com a documentação.

A documentação não parece ser projetada para fornecer orientação exata para a maioria dos cenários quando o auto soft-NUMA está ativado. Apenas as linhas 2 e 4 fornecem orientação precisa em vez de uma faixa MAXDOP aceitável. Para a linha 2, a única maneira de obter esse resultado com auto soft-NUMA é um servidor de soquete único com hyperthreading habilitado que tenha entre 10 e 16 núcleos lógicos. Para a linha 4, não é possível obter esse resultado com auto soft-NUMA habilitado.

Voltando a como a configuração do SQL Server funciona e por que ele escolhe 8, pode não estar documentado em nenhum lugar. Não estou mais em condições de testar com grandes servidores, então não posso procurar configurações de servidor que levem a um valor padrão maior que 8. Com isso dito, a Microsoft ao longo dos anos recomendou não exceder 8 em vários lugares. Por exemplo :

No Banco de Dados SQL do Azure, a configuração MAXDOP padrão para cada novo banco de dados único e banco de dados de pool elástico é 8. Esse padrão evita a utilização desnecessária de recursos, enquanto ainda permite que o mecanismo de banco de dados execute consultas mais rapidamente usando threads paralelos. Normalmente, não é necessário configurar ainda mais o MAXDOP nas cargas de trabalho do Banco de Dados SQL do Azure, embora possa fornecer benefícios como um exercício avançado de ajuste de desempenho.

Em setembro de 2020, com base em anos de telemetria no serviço de Banco de Dados SQL do Azure, o MAXDOP 8 tornou-se o padrão para novos bancos de dados, como o valor ideal para a mais ampla variedade de cargas de trabalho do cliente. Esse padrão ajudou a evitar problemas de desempenho devido ao paralelismo excessivo.

Essas cotações são para o Banco de Dados SQL do Azure, portanto, não são diretamente aplicáveis ​​à sua situação, mas acho que ilustram a mentalidade geral da Microsoft de que ir acima do MAXDOP 8 é um "exercício de ajuste de desempenho avançado".

Pessoalmente, o MAXDOP 8 para a configuração de hardware do seu servidor parece um ponto de partida razoável. Eu não começaria com MAXDOP 16 a menos que houvesse algum fator de carga de trabalho. Considere o melhor resultado de desempenho geralmente acreditado para a distribuição paralela de trabalhadores: todos os trabalhadores devem estar em diferentes núcleos físicos no mesmo nó NUMA rígido. Sem TF 2467 ou truques de hipervisor, aqui estão as probabilidades de como seus threads de trabalho serão distribuídos:

MAXDOP 16 só garante o melhor resultado 9% das vezes.

Pessoalmente, não acredito que a documentação da Microsoft nesta área seja muito boa. Há uma série de declarações ambíguas, enganosas ou simplesmente incorretas contidas nele. Pensamentos detalhados sobre isso estão aqui .