DESAFIO DO GORDO – Numa Node X MaxDop

Galera,

Recentemente recebi um email com uma pergunta bem interessante sobre qual a melhor maneira de definirmos a propriedade Max Degree of Parallelism (MAXDOP) em uma instância de banco de dados SQL Server.

Quero propor então que essa pergunta faça parte de mais um DESAFIO DO GORDO!!!!!!!!

Como vocês definem a quantidade de processadores na propriedade MAXDOP?

Conto com a participação de todos nos comentários e também não deixem de inscreverem-se no blog, no canal do youtube e no grupo de discussão SQLManiacs.

Grande abraço a todos.

Anúncios
  1. 13/10/2015 às 0:24

    Grande Fava,

    A primeira opção é deixar com o valor default, ou seja, 0
    Assim o SQL Server vai gerenciar e ajustar o melhor valor para o Max Dop.
    Se é somente se você enfrentar algum problema relacionado a paralelismo, o valor de ver ser definido até o máximo de cores por numa node.

    Se você tem 2 Numa Nodes com 8 cores cada, seu maxdop deve ser no máximo 8…

    My 2 cents

    Att.

    Edvaldo Castro

    • 13/10/2015 às 9:40

      Grande Edvaldo, muito bacana sua resposta.

      🙂

      Obrigado pela participação.

  2. 13/10/2015 às 9:21

    Grande Fava,

    Como a maioria das configurações, acredito que a melhor prática é deixar sempre o default, ou seja, com o valor 0, para que o SQL Server gerencie o nível de paralelismo dinamicamente.

    Se você estiver enfrentando problemas de performance relacionado a paralelismo, aí deve-se definir um valor para a propriedade supracitada.

    Neste caso, é recomendado que o valor do MAXDOP seja configurado até o limite do número de cores por numa node.

    Exemplo.

    Em um servidor com 2 NUMA nodes com 8 cores cada, o valor máximo para o MAXDOP deve ser 8

    My 2 cents.

    Edvaldo Castro
    http://edvaldocastro.com (marketing gratuito =P )

  3. 13/10/2015 às 11:49

    comentei duas vezes e nem vi… hehehehehe

  4. Vitor Carra
    14/10/2015 às 0:37

    Vitor,

    eu acredito que o melhor seja deixar a configuração padrão para melhor gerenciamento do SQL Server. No entanto, quando há issues relacionadas a paralelismo, há queries para encontrar quais são as queries que mais estão utilizando paralelismo.
    Quando for possível, tentar realizar tuning localizado em tais queries e verificar se o problema com paralelismo foi resolvido. Há um hint MAXDOP que pode ser utilizado em queries para analisar performance com tal parâmetro modificado. Há situações em que menos processadores trabalhando em uma query tem melhor performance do que com todos.
    Além disso, há o parâmetro “cost threshold for parallelism” que deve ser levado em consideração durante a análise sobre alterar ou o não o MAXDOP.
    A Microsoft tem uma “Guide line” sobre o assunto que pode ajudar muito em uma análise: https://support.microsoft.com/en-us/kb/2806535

    Há uma publicação do grande Brent Ozar falando sobre esse parâmetro e que me ajudou muito a entender os problemas relacionados a paralelismo.
    http://www.brentozar.com/archive/2013/08/what-is-the-cxpacket-wait-type-and-how-do-you-reduce-it/

    Grande abraço

    • 14/10/2015 às 16:50

      Grande Vitor, tudo bem?

      Excelente resposta meu amigo.

  5. Anderson Souza
    14/10/2015 às 16:27

    Vitor, depende! kkk

    Alguns fatores que devemos levar em consideração é o hardware do servidor de banco de dados,o ambiente (OLAP ou OLTP) e a carga desse servidor.

    Existem algumas diretrizes a serem consideradas para a configuracao do MAXDOP:

    Se Processor Affinity estiver configurado no SQL Server: O MAXDOP não deve ser maior que o numero de nucleos disponiveis para a instancia.

    Hyper-Threading habilitado: o MAXDOP não dever ser 0 e nem maior que a metade do numero individual de processadores.

    Ambiente usando hard NUMA: o MAXDOP não deve ser maior que os nucleos por nó NUMA.

    Como em qualquer outra configuração, deve-se realizar muitos testes num ambiente que não seja de producao, assim evitamos quaisquer tipos de problemas.

    • 14/10/2015 às 16:51

      Grande Anderson,

      Muito bem detalhada a sua resposta meu amigo.

      Obrigado pela participação.

  6. Caio Amante
    19/10/2015 às 23:29

    Vitor… acredito que se estivermos falando de um ambiente OLTP, por mais que seja bacana mantermos o padrão. Sinceramente minhas experiências em consultoria sempre fizeram com que este valor tenha que ser alterado. A regra geral que utilizo é sim utilizar metade dos cores, até no máximo 8 no maxdop, mesmo em caso de servidores com mais de 16 cores. Ex: 4 cores maxdop=2, 16 cores maxdop = 8, 32 cores maxdop =8. Talvez não seja a resposta mais correta, no entanto, em todos os ambientes que atuo, me trouxeram melhor resultado. De fato, os casos que acabei me deparando relacionado ao Protheus, me fizeram ter como via de regra o maxdop sempre diferente de 0.
    Exemplo ocorrido comigo: Como todos sabem, os ambientes Protheus possuem uma ferramenta chamada APSTU que praticamente ”assassina” qualquer DBA. Em um dia destes (aconteceu em vários dias destes e em vários clientes rsrs), uma pessoa decidiu montar um relatório e simplesmente gerou um produto cartesiano, fato que é comum entre desenvolvedores Protheus (nada contra Protheus e muito menos contra desenvolvedores, mais que existem alguns ’’kamikazes’’ existe). Quando esta operação ocorreu, a query ”maligna” simplesmente parou todo ambiente SQL SERVER, pois somente essa query consumiu todo recurso de hardware (principalmente processador e memoria), para executar a consulta. Este caso, ainda pode agravar-se com problemas no tempdb e mesmo estouro de disco(tenho ciência que neste caso, não seria o maxdop a solução, estou apenas citando rsrs). Sei que utilizando o resource governor, poderíamos limitar o usuário, no entanto, para quem não sabe, o apstu utiliza normalmente o mesmo usuário da aplicação, sendo assim, fica bem mais difícil limitarmos um usuário que de fato precisa sim, utilizar o máximo possível de recursos.

    Conclusão: Para mim existe uma regra geral, mais que em todos os casos depende de inúmeras variáveis que somente nós DBAs, podemos com o tempo e entendimento dos ambientes verificar o que é melhor em cada caso. Na minha opinião o valor default seria muito bom em ambientes totalmente controlados e que o DBA conhece muito bem as querys da aplicação.

    Abraços!

    • 20/10/2015 às 8:59

      Grande Caio, tudo bem?

      Excelente análise meu amigo.

      Grande abraço.

  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: