Quando fazer alterações no limite de custo do paralelismo

Ao examinar um problema de desempenho, vi um influxo no CXPACKETS, sugerindo que talvez eu precise examinar o limiar de custo para o paralelismo e, talvez, o MAXDOP.

Antes de fazer alterações drásticas no MAXDOP, segui o conselho de muitos outros, incluindo o de @mrdenny na resposta ao CXPACKET Waits, ajuste de desempenho para o SQL Server 2008 e a resposta de @ aron-Bertrand em Lidando com o CXPACKET - definindo o limite de custo para paralelismo . Eu adicionei à manutenção para atualizar as estatísticas totalmente todas as noites. Parece um movimento sensato.

No entanto, fazer modificações no limite de custo ainda é algo que me incomoda.

Em que ponto o limiar de custo do paralelismo deve ser alterado? Alguém tem um exemplo de onde (depois de examinar o custo de suas consultas e carga de trabalho) eles fizeram alterações nesse custo?

Desculpa se isso é algo que foi respondido em uma pergunta anterior.

Obrigado!

Usar MAXDOP = 1 pode ser uma ajuda, mas é uma grande arma. Pode ser que o problema real seja a utilidade dos índices. Talvez um índice novo ou diferente resolva o problema.

Após os comentários do Sr. Denny e Aaron Bertrand, você descobriu quais outras esperas nessa conexão provavelmente foram a causa das esperas do CXPACKET?

Jonathan Kehayias sugeriu uma consulta que pode ajudá-lo a avaliar sua experiência de paralelismo e tomar uma decisão mais ponderada. Mas você também deve ler a conversa entre Jonathan e Paul White.

https://www.sqlskills.com/blogs/jonathan/tuning-cost-threshold-for-parallelism-from-the-plan-cache/

Eu sugiro que você examine primeiro as configurações do MAXDOP, pois a configuração padrão de 0 (usar todos os threads disponíveis) pode ser perigosa, pois uma consulta descontrolada que consome todos os threads disponíveis levará à inanição do thread.

Consulte a minha resposta aqui para saber como calcular a configuração MAXDOP para sua instância do servidor.

O limite de custo do paralelismo refere-se ao custo mínimo da consulta antes de o paralelismo ser considerado pelo otimizador.

Lembre-se de que o CXPACKET aguarda são apenas sintomas devido a algo estar errado relacionado a estatísticas desatualizadas da consulta ou falta de índice, resultando em um plano ruim ou diferente.

Você pode usar sys.dm_exec_cached_planse sys.dm_exec_query_planDMV à informação mina a partir do cache do plano, conforme descrito no Sintonia 'limite de custo para paralelismo' a partir do cache do plano de Jonathan e limite de custo para paralelismo .

Eu sugeriria manter o cost threshold for parallelismpadrão, a menos que você tenha esgotado os recursos, ajustando as consultas, fazendo a manutenção de índices e estatísticas e verificando se não há nenhum índice ausente, para que sua consulta possa se beneficiar.

Nota: A configuração do Maxdop também pode ser aplicada no nível da consulta usando o OPTION (MAXDOP n)que substituirá a configuração do servidor.