Esta é uma pergunta muito geral, por isso não dou muitas informações específicas. Estou mais interessado em paralelismo e suas possíveis desvantagens. Geralmente sou a favor do paralelismo como algo útil e positivo.
Parece que me deparo com mais e mais sistemas que possuem um ou mais procedimentos armazenados que apresentam problemas com muito paralelismo. Existe uma boa maneira de descobrir se esse é realmente o problema ou se há algo mais à espreita?
Normalmente o sql é um pouco complexo com talvez 5 ou mais junções e também alguns udf e ainda mais complexidade. Até agora, encontrei esses problemas examinando tudo, desde problemas de desempenho comuns, mas também de situações mais extremas com mensagens de erro como "Não foi possível criar thread ..." e também bloqueios de várias cópias simultâneas do mesmo procedimento de armazenamento.
Estou muito curioso para saber como vocês fazem para encontrar problemas como esses e também como resolvê-los. Recodificação? Jogando com MAXDOP(grau máximo de paralelismo)? E assim por diante...
Escrevi sobre seis possíveis problemas com paralelismo aqui:
Isso foi há três anos, e tenho certeza que outros bugs igualmente perigosos surgiram desde que escrevi isso. Não examinei e validei nenhum que foi relatado como corrigido, mas a solução alternativa é quase sempre usar
MAXDOP 1.E tem outro que ainda está dando problema no SQL Server 2012, e que não foi corrigido no CU1:
https://stackoverflow.com/questions/9523213/possible-bug-with-range-option-of-window-aggregates-and-parallel-plans-in-sql-se
http://connect.microsoft.com/SQLServer/feedback/details/728932/parallelism-bug-with-sum-over-and-range
A solução nesse caso é, novamente, usar
MAXDOP 1.Existem outras questões que podem ser atribuídas ao paralelismo que não são realmente culpa do paralelismo. Por exemplo, se suas estatísticas estiverem muito erradas, você poderá observar o comportamento em que o paralelismo é empregado, mas um único thread está fazendo todo o trabalho. É o caso em que as pessoas soam os alarmes porque estão vendo
CXPACKETesperas e acham que o paralelismo está causando o problema, quando na verdade é a vítima. A reação instintiva nesses casos é tipicamente empregarMAXDOPem vez de investigar mais e resolver o problema de estatísticas ou outra causa raiz.Não está claro o que você quer dizer com "muito paralelismo" ou se seus impasses e outros problemas estão de fato relacionados de alguma forma ao paralelismo. Em geral, concordo que o paralelismo é uma coisa positiva, mas é importante estar ciente dos possíveis problemas acima e também ser capaz de discernir o sintoma da causa.
Ser capaz de comprometer mais núcleos de CPU para o processamento de uma solicitação é bom, até que o tempo necessário para remontar os resultados exceda o ganho obtido com a distribuição da carga de trabalho.
Verifique se você tem um tempo de espera CXPACKET alto. Se você não fizer isso, então não se preocupe. Esse artigo fornece algumas coisas para tentar se você quiser obter mais compreensão sobre o assunto.