Início / dba / Perguntas / 96346
Accepted
Tom
Asked: 2015-03-27 08:03:08 +0800 CST

CXPACKET SUSPENDED e tipo de espera NULL

  • 772

Eu estava executando a consulta neste artigo:

http://sqlity.net/en/708/why-cxpacket-waits-are-not-your-performance-problem/

Para ver o que meus threads estavam esperando em relação a uma consulta suspensa com um tipo de espera de CXPACKET.

No entanto, para o SPID em questão, os threads em execução estavam mostrando tipos de espera de NULL com todos os outros threads em um estado SUSPENDED com um tipo de espera de CXPACKET.

Eu esperava que um dos threads tivesse algum tipo de espera diferente de CXPACKET, alguém pode me explicar o que está acontecendo nessa situação?

Obrigado

sql-server wait-types

2 respostas

  1. O CXPACKET sempre foi o tipo de espera confuso para DBAs mais jovens e algumas reações previsivelmente erradas são geralmente esperadas. Existem vários aspectos do tipo de espera CXPACKLET e eu tentei no artigo Solução de problemas do tipo de espera CXPACKET no SQL Server para trazer à mesa a maioria dos motivos para CXPACKET alto, mas também para explicar o histórico do CXPACKET, como o entendimento adequado de paralelismo no SQL Server é a chave para entender

    Então, para aqueles que não querem entrar em detalhes, vou postar o resumo do artigo aqui (mas definitivamente sugiro a leitura do artigo para obter informações completas sobre o tipo de espera do CXPACKET):

    • Não defina MAXDOP como 1, pois isso nunca é a solução

    • Investigue a consulta e o histórico do CXPACKET para entender e determinar se é algo que ocorreu apenas uma ou duas vezes,
      pois pode ser apenas a exceção no sistema que normalmente está
      funcionando corretamente

    • Verifique os índices e estatísticas das tabelas utilizadas pela consulta e verifique se estão atualizados

    • Verifique o limite de custo para paralelismo (CTFP) e certifique-se de que o valor usado seja apropriado para o seu sistema

    • Verifique se o CXPACKET vem acompanhado de um LATCH_XX (possivelmente com PAGEIOLATCH_XX ou SOS_SCHEDULER_YIELD também). Se for esse o
      caso, o valor MAXDOP deve ser reduzido para se adequar ao seu hardware

    • Verifique se o CXPACKET é acompanhado por um LCK_M_XX (geralmente acompanhado por IO_COMPLETION e ASYNC_IO_COMPLETION). Se for esse
      o caso, então o paralelismo não é o gargalo. Solucionar problemas dessas
      estatísticas de espera para encontrar a causa raiz do problema e a solução

    • 5
  2. Best Answer

    O que você está vendo é que os encadeamentos com esperas CXPACKET são realmente concluídos com qualquer trabalho que tiveram que fazer e agora estão aguardando a conclusão dos outros encadeamentos ativos (aqueles com NULL como o tipo de espera).

    Brent O fez uma ótima analogia usando uma sala de aula. O professor distribui várias pilhas de papel para a turma e pede que encontrem uma palavra nelas. O que precisamos levar em consideração é o fato de que 1) as pilhas de papel podem ser de tamanhos diferentes 2) alunos diferentes leem mais rápido/lento do que outros 3) um aluno pode encontrar a palavra 1 vez na primeira página, enquanto o próximo pode encontre-o 400 vezes em 3.000 páginas.

    Você está vendo um comportamento natural e intencional quando lida com o paralelismo, alguns threads terminam mais rápido que outros e são forçados a esperar até que os outros threads sejam concluídos, reúna todos os threads e forneça uma saída.

    http://www.brentozar.com/archive/2013/08/what-is-the-cxpacket-wait-type-and-how-do-you-reduce-it/

    • 4

relate perguntas