Tipo de espera CXPACKET alto no SQL Server mesmo com MAXDOP = 1

1

Eu sempre tive um tipo de espera CXPACKET muito alto, e me disseram que ele deriva do processamento paralelo, e eu deveria manter o MÁXIMO GRAU DE PARALELISMO = (Nº Processadores / 4), ou 1 no meu caso. / p>

Mas as esperas do CXPACKET ainda são muito altas, em 32.78% de todas as esperas. Alguma sugestão?

    
por Lynx Kepler 14.07.2011 / 23:04

4 respostas

1

Você limpou as estatísticas de espera depois de baixar o grau máximo de paralelismo para 1?

Mas realmente não existe uma regra universal simples válida sobre como essa configuração deve ser configurada, além de medir o impacto de quaisquer alterações feitas. Além dos URLs acima, recomendo ler este post de Paul Randal.

Também sugiro reconsiderar o foco nos outros principais tipos de espera - muitas vezes descubro que as esperas do CXPACKET são um grande problema e estão ocorrendo devido a consultas complexas que são paralelizadas em trabalhos simples que são concluídos rapidamente e partes maiores de trabalho vinculadas a E / S que demoram muito para serem concluídas. As esperas do CXPACKET aparecem quando os trabalhos pequenos e rápidos são concluídos e aguardam que os trabalhos maiores sejam concluídos.

Se você deseja ajustar consultas específicas, o plano de execução deve mostrar quais partes da consulta estão demorando para serem concluídas e, em seguida, você pode ajustar o problema. Estatísticas desatualizadas ou índices mal escolhidos são muitas vezes os culpados.

    
por 15.07.2011 / 01:11
1

Isso não significa realmente que exista um problema ... o paralelismo é uma coisa boa, e o tipo de espera do CXPacket está sendo mostrado apenas porque o SQL Server precisa sincronizar entre os diferentes tipos de trabalho.

Quando você alterna para maxdop = 1, o tempo de execução desse código é mais lento do que quando ele é paralelo? Esta é a prova real do pudim, por assim dizer.

Há muitos artigos contraditórios por aí, mas esses dois são escritos por pessoas da SQL que sabem do que estão falando! (ok, um deles desertou para a Oracle!)

link

link

    
por 14.07.2011 / 23:38
1

O tipo de espera CXPACKET provavelmente não é o que está causando o seu problema, mas uma conseqüência disso.

Esse tipo de espera significa que o trabalhador está aguardando que alguma outra operação seja concluída antes que possa continuar. Você deve verificar a sessão que é responsável pelo CXPACKET e ver exatamente o que está esperando:

SELECT session_id, wait_type, wait_time, start_time, *
FROM SYS.dm_exec_requests
WHERE session_id > 50
GO

SELECT * 
FROM sys.dm_os_waiting_tasks AS t
WHERE session_id > 50
GO

Somente depois de diagnosticar a causa real do problema, você deve tomar uma ação para tentar atenuá-la.

    
por 20.01.2012 / 19:26
0

Definir MAXDOP cegamente em uma instância sem considerar a carga de trabalho é, IMO, um grande erro. Pode não necessariamente acabar prejudicando, mas é uma boa idéia (tm) para apoiar uma mudança da configuração padrão com uma explicação muito boa. Se você não pode explicar, não faça isso.

Do que eu vi na prática até agora, uma alta porcentagem de esperas do CXPACKET é uma indicação de grandes varreduras de tabelas paralelas.

Use o SQL Profiler para analisar as consultas em execução na instância: há uma boa chance de elas precisarem ser indexadas ou possivelmente até mesmo reescritas para serem mais eficientes. As esperas do CXPACKET são meramente um sintoma de um problema (possível).

    
por 15.07.2011 / 02:42