SQL Server - Alguém usa SUMA, sinalizador de rastreamento 8048 ou sinalizador de rastreamento 8015?

Recentemente, o Trace Flag 8048 de inicialização do SQL Server foi incluído para resolver um problema sério de contenção de spinlock em um sistema SQL Server 2008 R2.

Interessado em ouvir de outras pessoas que encontraram casos de uso em que o valor de desempenho foi entregue pelo sinalizador de rastreamento 8048 (promover estratégia de concessão de memória de consulta do nó por NUMA para por núcleo), sinalizador de rastreamento 8015 (SQL Server ignora NUMA físico) ou SUMA ( intercalou o acesso à memória suficientemente uniforme, uma opção do BIOS em algumas máquinas NUMA).

Sinalizador de rastreamento 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented-per-numa-node-may-need-trace-flag-8048.aspx

Sinalizador de rastreamento 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Detalhes sangrentos da carga de trabalho do sistema, métricas coletadas do sistema problemático e métricas coletadas do sistema após a intervenção.

O sinalizador de rastreamento 8048 foi uma 'correção', mas foi a melhor correção? O SQL Server ignorando o NUMA físico devido ao sinalizador de rastreamento 8015 teria realizado a mesma coisa? Que tal configurar o BIOS para intercalar memória, deixando o servidor com o comportamento SUMA que imita SMP em vez do comportamento NUMA?

Paz! tw: @sql_handle

Sobre o sistema: - 4 Xeon E7540 de núcleo hexadecimal a 2,00 GHz, com rosca hyperthread - 128 GB de RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

Sobre a carga de trabalho: - milhares de relatórios agendados / em fila do Lote, gerados por 2 servidores de aplicativos de relatório. - 3 tipos de lotes: diariamente, semanalmente, mensalmente - Todas as conexões de servidores de aplicativos de relatório ao SQL Server são feitas como uma conta de serviço única - Concorrência máxima de relatórios = 90

Principais descobertas no sistema problemático: - No Perfmon, intervalos de 15 segundos - - O sistema permanece com 95% -100% de CPU ocupada - - pesquisas na página de buffer do SQL Server <10000 por / segundo

• De DMVs de espera e spinlock, intervalos de 5 minutos
• • Garçons CMEMTHREAD altos e tempo de espera
• • SOS_SUSPEND_QUEUE rotações e backoffs altos

A postagem no Blog de engenheiro CSS de Bob Dorr no sinalizador de rastreamento 8048 indica que os sistemas com mais de 8 núcleos por nó NUMA podem apresentar sintomas semelhantes devido ao gargalo na concessão de memória de consulta. O sinalizador de rastreamento 8048 alterará a estratégia para por núcleo, em vez de por nó NUMA.

A intervenção

O MSSQL foi reiniciado com -T8048 no local. A diferença ficou imediatamente evidente: a taxa de pesquisa de páginas do buffer aumentou mais de 1 milhão e aumentou para 8 milhões por segundo. A carga de trabalho em lotes problemática, que anteriormente não podia ser concluída em 24 horas, foi concluída em menos de 4 horas. Outra carga de trabalho em lote que não era o foco da investigação ou intervenção foi enviada como parte da validação do valor corretivo do sinalizador de rastreamento 8048 (e da garantia de que seus efeitos colaterais indesejados fossem mínimos). Este lote de relatório foi concluído anteriormente em 2 horas; com o sinalizador de rastreamento 8048, o lote do relatório foi concluído em aproximadamente 20 minutos.

O ETL noturno também encontrou um benefício. O tempo de ETL caiu de aproximadamente 60 minutos para 40 minutos.

Reunindo informações de vários locais, especulo que o alto grau de enfileiramento de relatórios, a contagem de relatórios simultâneos seja superior à contagem de threads de hardware e a única conta de usuário para todos os relatórios combinados para pressionar um nó NUMA até que a pressão do thread do trabalhador o fizesse ser desfavorecido para a próxima solicitação de conexão recebida para a mesma conta de usuário; nesse ponto, o próximo nó NUMA obteria um número próximo de conexões instantaneamente. Cada nó NUMA acabaria com uma alta probabilidade de forçar o gargalo de concessão de memória de consulta.

A abertura de mais faixas para concessão de memória de consulta removeu o gargalo. Mas, não tenho certeza do custo. A postagem CSS de Bob Dorr deixa claro que há sobrecarga adicional de memória com o sinalizador de rastreamento 8048. Essa sobrecarga está localizada na região do alocador de página única governada pela memória máxima do servidor MSSQL 2008 R2? Nesse caso, acho que o sistema terá apenas um número menor de páginas do banco de dados no cache do buffer pool. Caso contrário, a memória máxima do servidor deve ser reduzida para acomodar?

Este é um post incrível.

Para responder sua pergunta final, eu especularia que sua resposta seja "sim".

Dito isto, eu provavelmente teria perseguido numa suave antes de recorrer às bandeiras de rastreamento. Eu acho que você está certo sobre a alocação de nó numa e isso pode estar na raiz do seu problema. Via soft numa, você pode escalar as solicitações, dependendo da contagem de nós numa (4?) - para 4, se esse for o número correto, e depois atribuir, via endereço IP, cada host a um nó numa, além de para isso, eu desativaria o hyper threading. Combinado, o problema provavelmente diminuiria, no entanto, faria isso ao custo de menos agendadores.

Em um pensamento separado, eu consideraria a parametrização forçada - o fato de sua carga estar elevando sua CPU tão alta é muito interessante e pode valer a pena investigar isso.

Por fim, em sistemas de nós multi-numa, normalmente tenho a saída das seguintes consultas despejando em uma tabela a cada N segundos. Faz algumas análises interessantes quando mudanças na carga de trabalho ou sinalizadores de rastreamento são implementadas:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

e

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC