Brent Ozar, Microsoft Certified Master, discutiu recentemente o paralelismo no SQL Server, especificamente os tipos de espera CXPACKET e CXCONSUMER em sua última parte da série de outono dos dias de treinamento de banco de dados da Quest. Em sua forma humorística e acessível de sempre, Brent desmistificou os conceitos de paralelismo e explicou como lidar com isso quando você vê muitas estatísticas de espera CXPACKET e CXCONSUMER.
Primeiro, o que é paralelismo e por que o SQL Server faz as consultas serem executadas em paralelo?
Simplificando, o SQL Server reconhece automaticamente que uma consulta específica tem uma grande carga de trabalho e determina que o trabalho pode ser feito com mais eficiência em vários processadores do que em apenas um. Geralmente, essa é uma decisão inteligente, mas pode ter problemas quando o SQL Server não equilibra a carga entre os threads que executam a tarefa.
Compreendendo os tipos de espera CXPACKET e CXCONSUMER
CXPACKET e CXCONSUMER são tipos de espera que indicam que o trabalho não está igualmente equilibrado. Quando você vir essas estatísticas de espera em seu servidor, saberá que o SQL Server está executando consultas em paralelo, mas não está fazendo um ótimo trabalho ao distribuí-las pelos processadores disponíveis.
Todo profissional de banco de dados está familiarizado com o conceito de “custo” para expressar o custo de execução de uma consulta em termos de consumo de recursos. Esses “valores de consulta” são uma medida aproximada de trabalho e um sinal importante para saber se a consulta será executada em paralelo ou não. Uma consulta barata não precisará ser executada em paralelo, mas uma consulta cara sim. O objetivo é executar a consulta da forma mais rápida e eficiente possível para que a próxima na fila possa começar. O SQL Server designa um encadeamento como um agendador, e esse encadeamento, que Brent considerou o “suserano do robô”, atribuirá partes da carga de trabalho paralela aos encadeamentos de trabalho ou aos “asseclas do robô”.
Paralelismo e o senhor do robô
Brent mergulhou em uma demonstração para mostrar como isso funciona. Usando o banco de dados Stack Overflow, ele criou uma pesquisa de banco de dados de baixo custo que foi muito rápida devido à presença de um índice. O plano de execução era bastante direto e não exigia paralelismo para ser executado.
Mas, quando ele introduziu uma pesquisa para algo que não estava no índice, as coisas mudaram, forçando uma pesquisa de chave para cada linha no índice clusterizado da tabela. O SQL Server reconheceu que isso daria muito trabalho, então introduziu o paralelismo e indicou como tal com um ícone no plano de execução. Se o plano de execução fosse tridimensional, você poderia ver os vários threads empilhados, mas como não é, você precisa visualizar as estatísticas para ver informações como as leituras lógicas realizadas por cada thread da CPU.
No entanto, o SQL Server atribuiu essa tarefa apenas a alguns threads, não a todos. Brent explicou que tudo o que acontece além do ícone paralelo está acontecendo apenas nos processadores atribuídos. Assim, os threads que realizaram as leituras iniciais agora são os únicos que também fazem as pesquisas de chave. O senhor do robô pediu apenas a alguns lacaios para realizar toda a tarefa, em vez de pedir a todos os lacaios que contribuíssem.
Ele continuou explicando que o SQL Server precisa explicar o que os threads estão fazendo, além de rastrear o que o robô está fazendo. Nos primeiros dias, todo esse trabalho era representado por uma estatística de espera, mas isso não fazia sentido porque não importa o que aconteça, o overlord ainda precisa esperar enquanto todos os threads estão funcionando. Então, um novo tipo de espera foi introduzido - este era CXCONSUMER e rastreia o que o encadeamento do agendador/suserano está fazendo, enquanto o CXPACKET rastreia o que os encadeamentos do trabalhador/servo estão fazendo.
Brent voltou à consulta para torná-la ainda mais complexa adicionando uma classificação. Agora, fica ainda mais claro que o paralelismo está causando um problema ao invés de tornar a operação mais eficiente. O trabalho tornou-se ainda mais desequilibrado nos poucos threads de trabalho, e alguns estão ficando sem memória e se espalhando para o disco. Ele acrescentou uma junção, sobrecarregando ainda mais os núcleos de trabalho que não estão recebendo nenhuma assistência dos não-trabalhadores. As estatísticas do CXPACKET continuaram a subir.
O que você pode fazer nesta situação? A decisão de paralelismo está ocorrendo no nível do servidor e não no nível da consulta, portanto, serão necessárias algumas alterações de configuração.
Avaliando as configurações de chave
Já aprendemos que, se o custo da consulta for maior que um determinado nível, isso fará com que o SQL Server seja paralelizado. Pequenas consultas são restritas a um único thread. Mas o que controla o limiar? É uma propriedade chamada Cost Threshold for Parallelism (CTFP). Por padrão, se o plano de execução determinar que o custo seja superior a 5 dólares de consulta, a consulta será paralelizada. Embora não haja orientação sobre como definir isso, Brent recomenda um número maior que 50. Isso eliminará o paralelismo para consultas triviais.
Outra configuração é o grau máximo de paralelismo (MAXDOP), que descreve o número de threads que o SQL Server atribuirá à consulta. O valor padrão aqui é zero, o que significa que o SQL Server pode usar todos os processadores disponíveis, até 64, para executar a consulta. Definir a opção MAXDOP como 1 limita o SQL Server a usar apenas um processador – na verdade, forçando um plano serial para executar a consulta. O SQL Server recomendará um valor de MAXDOP com base no número de núcleos de servidor que você possui, mas geralmente um MAXDOP mais baixo faz sentido, pois não haverá muitas vezes em que todos os núcleos serão necessários.
Brent fez ajustes nessas duas configurações e executou sua consulta novamente. Desta vez, pudemos ver que mais núcleos estavam engajados na operação paralela. As estatísticas de espera do CXPACKET eram mais baixas, o que significava que a carga estava mais equilibrada em mais núcleos do que antes.
Dicas para combater as estatísticas de espera CXPACKET e CXCONSUMER
Brent recomenda as seguintes etapas se você estiver vendo estatísticas de espera excessivas de CXPACKET e CXCONSUMER:
- Defina o CTFP e o MAXDOP de acordo com as práticas recomendadas do setor e deixe essas configurações durarem alguns dias. Isso limpa o cache do plano e força o SQL Server a reconstruir planos de execução de consulta (reavaliar o custo).
- Faça melhorias no índice que reduzirão o tempo em que as consultas são paralelas para fazer verificações e classificações. Deixe os novos índices funcionarem e, em seguida, procure as consultas que ainda estão fazendo muito trabalho.
- Ajuste essas consultas e deixe-as funcionar por alguns dias.
- Finalmente, se o paralelismo ainda for um problema sério, comece a procurar as consultas específicas com problemas de paralelismo.
Para obter ainda mais informações, você pode acompanhar toda a sessão de treinamento de Brent nas estatísticas de espera CXPACKET e CXCONSUMER sob demanda abaixo.
