Memory

Configurando dinamicamente Max/Min Memory de seus clusters SQL Server

Quando temos um ambiente em cluster, uma das principais preocupações é manter o ambiente devidamente balanceado, de modo que o consumo de CPU e memória RAM fique parecido entre os nós do cluster. O problema é que no momento de … Continuar lendo

Analise o cenário e me diga qual o problema…


Ontem um amigo MVP me mandou um e-mail de uma possível consultoria em SQL Server, falando de um cliente com alguns problemas de desempenho no SQL Server e como poderíamos ajuda-lo. Não fui ao cliente e nem vi o ambiente, não temos nem proposta de trabalho, só conseguimos bater um papo hoje com o cliente, o que corroborou ainda mais minhas teorias, então resolvi escrever este post sobre o assunto.

Junto com o e-mail tinha algumas informações do ambiente e montei uma análise (rápida e suja) sobre um dos problemas que o cliente está tendo, então compartilho com vocês o cenário e minha análise. Sugestão: leia o problema e tente entender qual é a zica e qual seria sua sugestão...

Cenário


Acho que não dava para ser mais breve, vamos lá...

Servidor com 64GB de RAM e 16 processadores
SQL Server 2005 SP4 x86 Standard Edition
AWE Habilitado
Max Server Memory = 60.000
Max Worker Threads = 0

Além disso, o cliente mostrou uma tela com uma série de requisições bloqueadas por um wait type bem divertido: RESOURCE_SEMAPHORE_QUERY_COMPILE.

Em um call que fizemos hoje, ele mencionou que já trabalharam em um servidor com 32GB de RAM e fizeram um acréscimo de hardware com mais processadores e 64GB, porém o comportamento não mudou. Então eu pergunto:

O que justifica o cliente estar vendo o wait type RESOURCE_SEMAPHORE_QUERY_COMPILE? Como você atacaria o problema?



TEMPO
PARA
VOCÊ
PENSAR
UM
POUCO,
OK
???
???
!!!!
!!!!

Explicação

RESOURCE_SEMAPHORE_QUERY_COMPILE - Este é o semáforo de compilação do SQL Server, é a forma que ele tem para impedir que a otimização de consultas acabe com a memória do servidor, então ele cria alguns gateways (small, medium e large) que controlam o número de compilações simultâneas dentro de cada grupo. Os thresholds e número de compilações são definidos de acordo com os recursos disponíveis para o SQL Server... Então está ótimo, pois o SQL Server têm definido 60.000MB para o Buffer Pool!


Opa opa opa, calma lá! Aqui temos um probleminha, pois estamos trabalhando com o AWE (pois o SQL Server é 32 bits) e sabemos que somente o data cache pode se beneficiar dessa extensão. E o resto dos memory clerks, como ficam? Bom, eles têm que disputar o que sobra dentro dos 2GB de endereçamento virtual de user mode, isto é, tirando o MemToLeave temos aproximadamente 1.6 para todos os outros clerks, provavelmente até menos se descontarmos outras coisinhas.


Como também o plan cache está nessa pressão, caso ele não esteja sendo bem utilizado, provavelmente está forçando ainda mais o número de compilações, aumentando a probabilidade de vermos mais do wait type em questão. Realmente um daqueles problemas de cobertor curto.


Aproveitando, acho que aí fica claro porque não houve grande ganho com o upgrade de hardware, pois a contenção está em uma área de memória que não se beneficia de mais memória utilizada através de AWE.


Sugestões...


A sugestão padrão é migrar para arquitetura de 64 bits, pois aí o endereçamento virtual é capaz de suportar todos os memory clerks e dividir melhor a proporção utilizada por cada um deles.


Outra opção, mais limitada, é tentarmos aliviar pontualmente a dor que eles estão sentindo, tentando aumentar a eficiência do plan cache, parametrização de consultas, etc. De forma que consiga aliviar um pouco a pressão entre os clerks e minimizar o número de compilações necessárias.


Muitos poderiam sugerir habilitar o /3GB, mas aí com 60GB de BPool o problema seria outro e o cliente provavelmente experimentaria o problema de PTE starvation. 



No fundo não é um problema muito trivial, mas acho que o diagnóstico está bacana para um cliente onde nem tocamos no ambiente. Tomara que ele consiga esperar por um buraco na nossa agenda, estou querendo “sujar as mãos” e fazer um tuning pesado com eles. Afinal, nos disseram que duas empresas de consultoria já passaram por lá...

Assunto show! E que os alunos do Internals já sabem, afinal falamos sobre isso nos módulos 01 e 02! Curiosamente estamos com outro e-mail discutindo outro ambiente x86, dois no mesmo dia, para quem pensou que não veria muito mais casos de 32 bits.

Abraços,



Luciano Caixeta Moreira - {Luti}

luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br

Analise o cenário e me diga qual o problema…

0
Ontem um amigo MVP me mandou um e-mail de uma possível consultoria em SQL Server, falando de um cliente com alguns problemas de desempenho no SQL Server e como poderíamos ajuda-lo. Não fui ao cliente e nem vi o ambiente, não temos nem proposta de ...
Go to Top