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
???
???
!!!!
!!!!
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
Nenhum comentário:
Postar um comentário