A desativação do hyperthreading melhorará o desempenho em nossa instalação do SQL Server

Relacionado a: Conhecimento atual sobre SQL Server e Hyperthreading

Recentemente, atualizamos nosso servidor de banco de dados do Windows 2008 R2 de um X5470 para um X5560 . A teoria é que ambas as CPUs têm desempenho muito semelhante, se é que o X5560 é um pouco mais rápido.

No entanto, o desempenho do SQL Server 2008 R2 tem sido muito ruim nos últimos dias e o uso da CPU tem sido bastante alto.

A expectativa de vida da página é enorme, estamos recebendo quase 100% de acerto de cache nas páginas, portanto a memória não é um problema.

Quando eu corri:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

Eu tenho:

wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
WRITELOG 16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 1475699

(10 linha (s) afetada)

Eu também corri

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

E pegou

wait_type wait_time_s pct running_pct
CXPACKET 554821.66 65,82 65,82
LATCH_EX 184123.16 21,84 87,66
SOS_SCHEDULER_YIELD 37541.17 4.45 92.11
PAGEIOLATCH_SH 19018,53 2,26 94,37
FT_IFTSHC_MUTEX 14306.05 1.70 96.07

Isso mostra uma quantidade enorme de tempo sincronizando consultas envolvendo paralelismo (alto CXPACKET). Além disso, muitas dessas consultas de problemas estão sendo executadas em vários núcleos (não temos dicas do MAXDOP em nenhum lugar do nosso código)

O servidor não está sob carga há mais de um dia. Estamos enfrentando uma grande variação nas execuções de consultas, normalmente muitas consultas parecem mais lentas do que no nosso servidor de banco de dados anterior e a CPU é realmente alta.

A desativação do Hyperthreading ajudará a reduzir o uso da CPU e aumentar a taxa de transferência?

Ainda sinto que testar sua carga de trabalho específica , de acordo com a resposta original, é a única maneira de ter certeza. Não é uma resposta ideal quando você está tentando ajustar um sistema de produção (por isso, perguntaria se era possível obter um teste idêntico em sistemas onde o desempenho e a disponibilidade realmente importam), mas é o único que me sinto realmente confortável com.

Podemos falar sobre a teoria de se o Hyperthreading deve prejudicar ou melhorar as coisas em geral (acho que é mais provável que isso machuque do que ajudar nos servidores, portanto, para uma implantação "genérica" ​​eu provavelmente a desativaria), mas há apenas uma maneira de ver com certeza se isso fará diferença no seu caso específico, e é tentar e ver.

Eu concordo que

• na melhor das hipóteses, a recomendação é "experimente o HyperThreading na sua carga de trabalho e veja o que acontece". Estamos fazendo isso agora enquanto digito, e .. não é bom!
• você provavelmente deve sempre começar com o HyperThreading desativado, pois é mais seguro

Parece que deveríamos ajustar duas coisas:

1. MAXDOP (Graus máximos de paralelismo). Tudo o que li indica que ter isso sem limites provavelmente é uma má idéia, e a documentação da Microsoft diz:

   Definir esta opção [MAXDOP] para um valor maior [8] geralmente causa consumo indesejado de recursos e degradação do desempenho.

   qualquer coisa mais alta do que 8geralmente não é recomendada .. então eu a defino 4por enquanto. Era zero (ilimitado) inicialmente.

2. Limiar de custo para paralelismo. Aparentemente, o padrão 5aqui é considerado um padrão bastante baixo, de acordo com algumas postagens do SQL MVP que eu encontrei - podemos ajustá-lo para reduzir a quantidade de paralelismo que o planejador ainda tenta.

Mas, honestamente, essas parecem soluções alternativas; Eu acho que a verdadeira solução para nossa carga de trabalho (índice de texto completo) é desativar o HT.

Anandtech descobriu que, com a carga pura de leitura, doía um pouco e, com uma carga pesada de gravação, era uma vitória. Não vi nada que me fizesse pensar que isso causaria um golpe muito pior que -5%, ou uma vitória muito melhor que 15%. Observe o que com um Atom, é uma vitória enorme, mas essa é uma CPU muito estranha.

Tudo que você mudou foi a CPU? Você passou do cache de 12MB e 4 threads, para 3 MB de cache por thread, para 8 MB de cache e 8 threads, para 1 MB por thread. Agora, isso é simplista demais, mas aposto que é isso que está matando você. Você costumava executar consultas no cache e agora as executa na RAM porque elas precisam de mais de 1 MB, mas menos de 3 MB. Desativar o HT provavelmente ajudará, mas eu voltaria à antiga CPU. Desative o HT e você recebe 2 MB por thread, mas se sua carga de trabalho diminuir muito, isso não ajudará. Pode ser que o antigo processador de cache de 12MB seja extremamente mais rápido para sua carga de trabalho.

Eu tentaria desativar o HT e ver se isso é uma melhoria, mas suspeito que o cache seja o rei da sua carga de trabalho, e você pode precisar voltar ao chip de 12 MB.

O hyperthreading é, na melhor das hipóteses, apenas uma maneira de abstrair a alternância de tarefas do sistema operacional e colocá-lo na matriz, com acesso direto ao cache L1 e L2, o que torna a troca de tarefas um upload mais rápido.

Os testes com o VMWare indicaram que desabilitar o HT não fazia diferença discernível sob carga padrão e um aumento de 5% sob carga pesada, devido ao fato de que o ESXi é inteligente o suficiente para saber a diferença entre o segmento "real" e o "falso" (há muito mais do que isso, mas isso é em termos de laymens). O SQL Server 2005 não é tão inteligente, mas, combinado com um sistema operacional atualizado, deve haver pouca vantagem em desativar o HT.

Tudo isso dito, eu concordo com Ronald que provavelmente será o seu cache L2. Uma queda de 33% no tamanho do cache é substancial e, quando especificamos nossos SQL Servers, sempre buscamos o cache na velocidade bruta do relógio todas as vezes.

Com base na minha experiência, o HT fazia com que as operações de E / S demorassem para sempre nos meus nós ativos em um cluster do Windows 2008 R2 (executando o SQL Server 2008 R2). Um fato interessante foi que ele não estava refletido nas estatísticas de espera nem no pssdiag que eu solicitei para o suporte da Microsoft.

A maneira como notei baixa E / S foi apenas observando os contadores do SO em busca de disco físico. Como Sam apontou, escrevi sobre isso aqui e aqui

Se você NÃO tiver problemas de E / S e estiver ligado à CPU, sugiro que você comece desta maneira:

Identifique quais processos e blocos T-SQL estão causando a maior utilização da CPU. Em nossa experiência, depois que corrigimos o problema de E / S (desativando o HT), identificamos o código que estava com um desempenho horrível em 2008 R2 e se saindo bem em 2005. Escrevi sobre isso aqui .

Enquanto estiver sob alta carga, execute sp_whoisactive de Adam Machanic. Você pode baixá-lo aqui . Estávamos com uma utilização muito alta da CPU devido à quantidade excessiva de leituras lógicas (20 milhões por consulta) devido a um plano realmente ruim. Nossos processos estavam realizando junções anti-semi com tabelas que foram particionadas.

Minha próxima recomendação é executar o criador de perfil para identificar um conjunto de códigos T-SQL com alta leitura de CPU e lógica de E / S.

Com as etapas acima, conseguimos ajustar os processos ofensivos e passar de 85% da utilização sustentada da CPU para quase zero.

Boa sorte e sinta-se à vontade para me enviar uma linha, se você encontrar uma solução, pois eu gostaria de adicionar o caso ao meu blog.

obrigado

Oscar

É difícil determinar se o HT é bom ou ruim.

Realmente depende do padrão de carga do servidor com base na experiência e na leitura. Ou seja, quando afeta o desempenho, o desempenho é tão ruim : caso contrário, você não percebe.

A teoria que li foi que os encadeamentos compartilham cache, o que significa que, sob condições adversas, cada encadeamento pode substituir o cache do outro encadeamento. Se você não tiver muito paralelismo ou sua carga for muitas consultas curtas, isso poderá não afetá-lo.

Eu tentei com MAXDOP e afinidade de processador (de volta à minha última função real de DBA no SQL Server 2000), mas nunca consegui encontrar nada conclusivo: mas apenas para minha loja naquele momento.

Como um teste rápido, você pode definir a afinidade do processador para usar apenas núcleos físicos (os números mais baixos) e ver o que acontece.

No entanto, no máximo você perde metade dos seus núcleos. Hoje em dia isso pode não importar em comparação com o que eu estava jogando há alguns anos atrás, quando era 2 vs 4 ou 4 vs 8. Agora são 8 vs 16 ou 16 vs 32.

Edit: Um teste de Slava Oks

Infelizmente, acho que você não receberá nenhuma resposta mais definitiva do que "tente desativar o hyperthreading e veja se isso ajuda".

Apesar da resposta útil de Jonathan no meu tópico original (que você vinculou na sua pergunta), nunca consegui obter nenhuma evidência definitiva sobre o impacto do HT nos servidores específicos que estava investigando. No meu caso, os servidores já estavam agendados para substituição, portanto, simplesmente deixamos essas substituições "cuidar do problema", por assim dizer.

Meu conselho:

Tente uma configuração de grau de paralelismo MAX de nível de servidor igual a 1 . O paralelismo no SQL é mais útil para consultas maiores e mais longas de qualquer maneira, e sua carga (presumo) consiste em um número massivamente alto de consultas menores de qualquer maneira. Isso deve eliminar totalmente as esperas do CXPACKET. Isso pode fazer com que determinadas consultas individuais sejam executadas um pouco mais, mas deve permitir mais "taxa de transferência" do total de consultas no servidor.

Eu tive bons resultados fazendo isso nos servidores OLTP. Outros tipos de servidores (servidores de relatórios, servidores de processamento, data warehousing) definitivamente precisam do conjunto MAXDOP mais alto.

E, para ficar claro, essa configuração ainda permitiria que o SQL usasse vários encadeamentos para cada tabela individual em um JOIN, portanto, você não está realmente eliminando completamente o paralelismo.

Pelo menos vale a pena tentar, já que essa alteração na configuração entra em vigor imediatamente e nem exige a reinicialização do serviço SQL: http://msdn.microsoft.com/en-us/library/ms181007.aspx
Isso significa que você pode alternar de volta imediatamente se as coisas começaram a ir para o inferno.

Desativar o hyperthreading no BIOS exigiria uma reinicialização completa do servidor, por isso é um pouco mais arriscado.

Para constar, também tivemos um desempenho inesperadamente ruim após uma atualização do servidor. Acabou sendo devido a problemas com a economia de energia do BIOS e da CPU. A configuração padrão no servidor (HP) era ignorar o controle do SO da velocidade da CPU e usar seu próprio algoritmo. Alterar isso para o controle do SO e atualizar o BIOS resultaram em melhorias significativas. Havia algumas notas de versão (não é possível encontrá-las agora) de que havia um bug do BIOS que estava bloqueando a CPU no estado de desempenho mais baixo.

/server//a/196329/6390