CXPACKET alto e LATCH_EX aguardam


13

Estou tendo alguns problemas de desempenho em um sistema de processamento de dados no qual estou trabalhando. Reuni estatísticas de espera de um período de uma hora que mostram uma grande quantidade de eventos de espera CXPACKET e LATCH_EX.

O sistema consiste em 3 servidores SQL de processamento, que realizam muitos cálculos e cálculos de números e, em seguida, alimentam os dados em um servidor de cluster central. Os servidores de processamento podem ter até 6 trabalhos em execução, cada um de cada vez. Essas estatísticas de espera são para o cluster central, que eu acho que está causando um gargalo. O servidor de cluster central possui 16 núcleos e 64 GB de RAM. MAXDOP está definido como 0.

Eu acho que o CXPACKET é de várias consultas paralelas em execução, no entanto, não tenho certeza do que o evento de espera LATCH_EX está indicando. Pelo que li isso poderia ser uma espera sem buffer?

Alguém pode sugerir qual seria a causa desse tipo de estatísticas de espera e que curso de ação eu deveria tomar para investigar a causa raiz desse problema de desempenho?

Os principais resultados da consulta são as estatísticas totais de espera e o resultado inferior da consulta são as estatísticas do período de 1 hora Amostra de espera SQL


4
Você já deu uma olhada no blog de Paul Randal no Latch espera? sqlskills.com/blogs/paul/... Há um pouco de informação útil em determinar o que os meios de espera Trava selecionando de sys.dm_os_latch_stats
Mark Sinkinson

CXPacket é quando o thread principal da consulta está aguardando o retorno dos threads paralelos. Para uma boa explicação e algumas maneiras de reduzi-la ver post no blog do Brent Ozar sobre o assunto brentozar.com/archive/2013/08/...
RubberChickenLeader

Respostas:


8

O CXPACKET pode ser acompanhado com um LATCH_XX (possivelmente com PAGEIOLATCH_XX ou SOS_SCHEDULER_YIELD). Se for esse o caso (e acredito que seja, com base na pergunta), o valor MAXDOP deve ser reduzido para se adequar ao seu hardware.

Além disso, aqui estão algumas etapas mais recomendadas para diagnosticar a causa dos altos valores de estatísticas de espera do CXPACKET (antes de alterar algo no SQL Server):

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

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

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

  • Verifique o limite de custo para paralelismo (CTFP) e verifique se o valor usado é apropriado para o seu sistema

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

Se você realmente precisa entender o tipo CXPACKET espera em profundidade, eu aconselho a leitura da Resolução de problemas do tipo CXPACKET espera no SQL Server artigo



3

Além de ler os links fornecidos acima e provavelmente alterar a configuração "Máximo grau de paralelismo" de 0 para algo como 8, convém restringir quais de suas consultas estão paralelas e qual é o custo.

Depois de ver o impacto dessa alteração, você também pode modificar seu "Limiar de custo para paralelismo" para ajustar o que será paralelo.

Aqui está um ótimo vídeo de Brent Ozar que irá ajudá-lo: Dominar a arte do CXPACKET e MAXDOP

Sua meta é <= 50% por cento do tempo de espera para o CXPACKET. Boa sorte!!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.