Conhecimento atual sobre SQL Server e Hyperthreading?

Muitos artigos por aí (consulte o artigo original do SQL 2000 do Slava Oks e a atualização do SQL 2005 de Kevin Kline ) recomendam desativar o hyperthreading nos servidores SQL ou pelo menos testar sua carga de trabalho específica antes de habilitá-la em seus servidores.

Esse problema está gradualmente se tornando menos relevante à medida que os verdadeiros processadores multi-core substituem os com hyperthread, mas qual é a sabedoria atual sobre esse assunto? Este conselho altera alguma coisa com o SQL 2005 de 64 bits, SQL 2008 ou Windows Server 2008?

Idealmente, isso deve ser testado com antecedência em um ambiente de armazenamento temporário, mas e os 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 pode me indicar nessa direção, em oposição a todas as outras coisas que normalmente busco ao trabalhar para melhorar o desempenho do SQL?

Editar : Este é especialmente atraente por causa do potencial para um através da placa melhoria para alguns dos meus servidores de alta CPU, mas o cliente vai querer ver algo concreto que me ajuda a identificar quais servidores realmente poderia beneficiar de desabilitar hyperthreading. Obviamente, a solução de problemas de desempenho convencional está em andamento, mas às vezes ajuda um pouco.

No SQLOS, um agendador é criado para cada processador lógico que o SQL Server vê. Com o hyperthreading ativado, isso equivale a dobrar os agendadores. Um dos objetivos do SQLOS é minimizar e impedir a alternância de contexto, razão pela qual apenas um planejador é criado para cada processador lógico. Depois que o SQLOS cria os agendadores, o número total de trabalhadores é dividido entre os agendadores. O SQLOS implementa uma forma de agendamento cooperativo, em que os trabalhadores produzem o agendador, pois requer recursos indisponíveis, ou atingem seu quantum de execução, permitindo que outros trabalhadores executem no agendador. Isso mantém a alternância de contexto no mínimo, uma vez que o agendador está fazendo o trabalho e eles são vinculados um a um.

Entendendo esse pano de fundo, o hyperthreading funciona de maneira oposta à maneira como o SQLOS é projetado especificamente para funcionar. Especificamente, o paralelismo pode ser problemático com o hyperthreading e resultar em altas esperas do CXPACKET, já que o SQLOS pode tentar executar uma consulta no DOP 8 sobre o que é realmente um sistema DOP 4. Se a utilização da CPU for baixa, você poderá não perceber, mas quanto maior a utilização da CPU, mais problemático poderá se tornar. Recentemente, tive uma discussão no twitter sobre isso, e o consenso era "Depende" de saber se ajudaria ou não.

Se você tiver muitas esperas de sinal no servidor, mas tiver baixa utilização da CPU, poderá ver o benefício de habilitar o hyperthreading, que duplicará seus agendadores internos e espalhará mais os trabalhadores, o que significa que eles não esperam para executar na fila executável enquanto No entanto, se sua carga de trabalho utilizou muito o paralelismo, você aguarda o CXPACKET em sys.dm_os_wait_stats, pode desabilitar o hyperthreading para ver se ele reduz suas esperas.

Na verdade, o hyperthreading não desapareceu, os novos chips quad-core Nehalem da Intel têm hyperthreading. Quanto a ser 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 a 60 segundos, e obtendo CPU, comprimento da fila de discos nos dados e discos de log, a expectativa de vida da página é uma boa medida para saber se você tem memória suficiente. Se você tem consistentemente mais de 80% da CPU ou se as filas de disco estão com três dígitos, encontrou o seu problema.

SQL Server 2000 em um HP DL360 G3:

Fiz um relatório seis vezes, joguei a primeira corrida e gravei as últimas cinco. Reiniciei o banco de dados novamente e ativei o Hyperthreading. Fiz 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 aleatória seja executado 5,2% mais rápido (em média).

Execuções repetidas do relatório:

Com Hyperthreading: 20,95%, 21,1%, 21,9%, 20,8%, 20,5%
Tempos de execução em ms: 20282, 21141, 20188, 22297, 25282. Média 21838

Sem Hyperthreading: 29,4%, 28,2%, 29,1%, 28,2%, 27,1%
Tempos de execução em ms: 20125, 20156, 19937, 21656, 21656. Média 20706