Conhecimento atual sobre SQL Server e Hyperthreading?

8

Vários artigos disponíveis (consulte artigo original do SQL 2000 da Slava Oks e Atualização SQL 2005 de Kevin Kline ) recomenda desativar o hyperthreading em servidores SQL ou, pelo menos, testar sua carga de trabalho específica antes de ativá-lo em seus servidores.

Esta questão está gradualmente se tornando menos relevante à medida que verdadeiros processadores multi-core substituem os hyperthreaded, mas qual é a sabedoria atual sobre essa questão? Este conselho muda alguma coisa com o SQL 2005 64-bit ou SQL 2008 ou Windows Server 2008?

O ideal é que isso seja testado com antecedência em um ambiente de preparação, mas e quanto aos servidores que já entraram em produção com o HT ativado? Como posso saber se os problemas de desempenho que estamos enfrentando podem estar relacionados ao HT? Existe alguma combinação específica de contadores de perfmon que podem me apontar nessa direção, em oposição a todas as outras coisas que eu normalmente busco ao trabalhar na melhoria do desempenho de SQL?

Editar : Isso é especialmente atraente devido ao potencial de melhoria em toda a linha para alguns dos meus servidores de alta capacidade, mas o cliente vai querer veja algo concreto que me ajude a identificar quais servidores realmente poderiam se beneficiar da desativação do hyperthreading. Naturalmente, a solução de problemas de desempenho convencional está em andamento, mas algumas vezes ajuda um pouco.

    
por BradC 30.06.2009 / 00:24

3 respostas

16

No SQLOS, um agendador é criado para cada processador lógico que o SQL Server vê. Com o hyperthreading ativado, isso equivale a duplicar os agendadores. Um dos propósitos do SQLOS é minimizar e impedir que ocorra a troca de contexto, razão pela qual apenas um agendador é criado para cada processador lógico. Uma vez que o SQLOS cria os agendadores, o número total de trabalhadores é dividido entre os agendadores. O SQLOS implementa uma forma de planejamento cooperativo em que os operadores geram o planejador, já que ele requer recursos indisponíveis ou alcança seu quantum de execução, permitindo que outros funcionários executem no planejador. Isso mantém o contexto mudando para um mínimo, já que o agendador está fazendo o trabalho e eles estão ligados um a um.

Compreendendo esse plano de fundo, o hyperthreading funciona um pouco ao contrário de como o SQLOS é especificamente projetado para funcionar. Especificamente, o paralelismo pode ser problemático com o hyperthreading e pode resultar em esperas altas do CXPACKET, já que o SQLOS pode tentar executar uma consulta no DOP 8 sobre o que é um sistema DOP 4 da realidade. Se a utilização da CPU estiver baixa, talvez você não perceba, mas quanto maior a utilização da CPU, mais problemático ela pode se tornar. Recentemente, tive uma discussão no twitter sobre isso, e o consenso foi "Depende" de saber se isso ajudaria ou prejudicaria.

Se você espera muito sinal no seu servidor, mas tem pouca utilização da CPU, pode ver o benefício de ativar o hyperthreading, que duplicará seus agendadores internos e distribuirá mais os funcionários, o que significa que eles não esperarão para executar a fila executável por tanto tempo. No entanto, se a sua carga de trabalho utilizou muito o paralelismo que o CXPACKET aguenta em sys.dm_os_wait_stats, você pode desabilitar o hyperthreading para ver se ele reduz suas esperas.

    
por 30.06.2009 / 01:00
2

Na verdade, o hyperthreading não desapareceu, os novos chips de núcleo quádruplo Nehalem da Intel têm hyperthreading. Quanto a se é recomendado ou não, "depende" como sempre, cada situação é provavelmente diferente.

É improvável que o HT seja a causa raiz de qualquer problema de desempenho, mas sem mais detalhes, é difícil dizer o que é. Faça algumas sessões de perfmon, com taxas de amostragem razoavelmente longas, como uma vez a cada 30 - 60 segundos e obtendo cpu, tamanho da fila de disco nos discos de dados e log, a expectativa de vida da página é uma boa medida se você tem memória suficiente. Se você estiver consistentemente acima de 80% da CPU, ou se as filas de disco estiverem nos dígitos triplos, você encontrou o problema.

    
por 30.06.2009 / 00:36
1

SQL Server 2000 em um HP DL360 G3:

Eu fiz um relatório seis vezes, joguei a corrida inicial e anotei os últimos cinco. Em seguida, reiniciei o banco de dados novamente e liguei novamente o Hyperthreading. Eu executei o relatório mais seis vezes, mantendo os dados das últimas cinco execuções.

Observações:

  • Desativar o Hyperthreading não custa 2x no uso aparente da CPU, apenas cerca de 1,5x.
  • Desativar o Hyperthreading faz com que um relatório de execução demorada seja executado 5,2% mais rápido (em média).

Execuções repetidas do relatório:

With Hyperthreading:  20.95%, 21.1%, 21.9%, 20.8%, 20.5%
Run times in ms:      20282,  21141, 20188, 22297, 25282.  Average 21838

Without Hyperthreading: 29.4%, 28.2%, 29.1%, 28.2%, 27.1%
Run times in ms:        20125, 20156, 19937, 21656, 21656.  Average 20706
    
por 10.01.2011 / 21:22