Monitorando a Memória do SQL Server

Monitorando a Memória do SQL Server

  • Comments 19

Hoje recebi um comentário sobre a utilização de memória no SQL Server e comecei a pensar um pouco mais sobre o assunto. Será que esse é um assunto interessante?

Comentei com um amigo sobre o assunto e ele (que não trabalha em TI) disse que vale a pena. Minha motivação do blog será mostrar um pouco mais sobre os mecanismos de gerenciamento de memória usados no SQL Server.

Para começar a série de artigos, compartilho a imagem de uma utilização crescente de memória e que resultou numa degradação horrível de performance.

 

image

O primeiro conceito importante é falar sobre memória física ou memória RAM. Como vocês sabem, o Windows utiliza memória virtual, que permite colocar as informações em RAM e movê-las para o Paging File quando necessário. Entretanto, no mundo SQL Server estamos interessados somente na memória RAM porque a paginação em disco é muito lenta (não faz sentido fazer cache de dados usando o Page File).

Na linguagem técnica, dizemos que working set (veja o artigo Memory- Working Set) corresponde a quantidade de memória RAM usada por um processo.

Atenção: Apesar do Windows mostrar o working set dos processos, essa medida não contabiliza a memória alocada via AWE. Em outras palavras, evite utilizar o Task Manager para monitorar a quantidade de memória utilizada. Verifique os contadores do Performance Monitor chamados “Total Server Memory”.

No próximo artigo, pretendo introduzir o conceito de Buffer Pool – principal componente que interage com o Sistema Operacional.

  • Poderias citar também sobre ring buffer, e alternativas para encontar contenção de memória no SQL Server?

    Abraço

  • Olá Fabrício tudo bem ?

    Você comentou sobre a não utilizar o task manager para verificar a memória devido  AWE não ser mostrado.

    E em um servidor 64 bits posso garantir a utilização de memória pelo task manager ou ainda assim é mais garantido analisar pelos contadores.

    Abs

    Alexandre

  • Anotado! Vou comentar sobre o ring buffer.

    Aproveito para adiantar que a sys.dm_os_ring_buffer não é documentada e pode sofrer alterações após mudança de versão ou service packs. Essa DMV é uma forma interessante de acompanhar os últimos eventos que ocorreram nos Memory Clerks, Memory Broker e Buffer Pool. Vale a pena comentarmos sim..

    Obrigado pela dica

    Fabricio

  • Oi Alexandre!

    Usar ou não usar o Task Manager para monitorar a memória? (ótima pergunta!)

    A resposta é NÃO.

    Já vi muitos servidores de 64-bits que o Task Manager reportam que o SQL está usando apenas 300MB.

    O motivo é que o SQL Server ainda pode utilizar alocação de memória via AWE na plataforma 64-bits. Nesse caso, o Task Manager reportaria uma quantidade incorreta de memória. O ideal é sempre utilizar o Performance Monitor - Memory Manager:Total memory.

    Abraços

    Fabricio

  • Fabricio,

    Mas no caso o SQL Server poderia utilizaria AWE se o processo SQL Server estiver sobre WOW. Não é isso?

  • Olá Leivio,

    Correto, o mecanismo AWE pode ser usado debaixo do WOW.  Mais do que isso: AWE pode ser usado no próprio modo nativo 64-bits (fora do WOW). Como o toda a memória AWE não contabiliza do ponto de vista do Task manager, então não é recomendado usa-lo para acompanhar o consumo de memória do servidor SQL.

    Abraços

    Fabricio

  • Fabricio,

    Só para esclarecer o que seria AWE em 64 bits;

    O AWE em modo nativo 64-bits(fora do WOW) não seria o privilegio do "lock pages in memory" para a conta do serviço MSSQLSERVER X64? Ou seja, teriamos uma modificação na alocação\localização das paginas utilizadas pelo processo "working set e PFN database" com isso o SO ira ignorar essas "paginas" no processo de paginação e teriamos o acesso mais rapido as paginas ja que o mapeamento da paginas virtuais seria direto com as paginas fisicas.

  • Oi Leivio!

    Exatamente!!! Perfeito!!! Ao habilitar o Lock Pages in Memory, o SQL Server passa a usar AWE para evitar a paginação em disco. Isso afeta diretamente na alocação\localização das páginas e consequentemente no working set do processo. A estrutura de diretorio de PFN se altera principalmente ao usar Large Pages. Em ambos os casos, os PTE passam a usar referência a memória física e não podem ser paginados. Aproveitei para escrever um pouco mais no post:

    Lock Page: blogs.msdn.com/.../lock-pages-in-memory.aspx

    Obrigado pelos comentários. Fabricio

  • Senhores,

    Até onde sei em WOW o SQL Server 32 bits não ultrapassa a barreira dos 4 GB. Mesmo com AWE. Então, não vejo muita razão em usar AWE em Win 64 + SQL 32

    Abraço

  • Olá!

    SQL Server 32-bits rodando em um Windows 64-bits (x64) é possível usando o WOW mode. Nesse caso é possível usar toda a memória RAM através do AWE limitado a 64GB. Segue uma referência:

    blogs.msdn.com/.../575152.aspx

    Por outro lado, não encontrei nada que falasse sobre o AWE não poder ser usado com WOW. Se tiver mais informações, coloque seu comentário e farei uma pesquisa mais cuidadosa. Obrigado pelo comentário!

    Abraços, Fabricio

  • Acredito que me enganei no link:

    msdn.microsoft.com/.../aa384209%28v=VS.85%29.aspx

    Abraço

  • Agora está tudo claro: a memória não pode ser alocada através do AWE na plataforma Itanium (64-bits) quando rodando em WOW mode. Isso ocorre porque as páginas de memória são de 8kb, enquanto que no 32-bits, são 4kb.

    Esse é uma grande explicação porque a Microsoft nunca permitiu misturar SQL 32 e 64 bits dentro do Itanium. Felizmente, a plataforma x64 permite usar AWE sempre. :)

    Excelente link e comentário! :)

  • Foi isso. É que me enganei , não li corretamente que era apenas Itanium. Mas valeu. Fico no aguardo do RING BUFFER.

    Abraço

  • Estou procurando algum bom exemplo para falar sobre RING BUFFER. Alguma sugestão? Algo parecido seria falar com XEvents, que tem muitas aplicações práticas.

  • Olá Frabricio,

    Antes de tudo gostaria de parabeniza-lo pelo excelente conteúdo em seu blog. Ando acompanhando os posts e estão me servindo de muito aprendizado.

    Fiquei com uma dúvida, você deixou claro que o Working Set do processo não contabiliza a memória alocada pelo mecanismo AW e por isso é indicado monitorar a memória do SQL Server utilizando o contador Total Server Memory. Mas olhando em outras fontes li que o contador Total Server Memory contabiliza apenas a memória utilizada pelo Buffer Pool e alocações de memória como MPA,Linked Servers, etc não são contablizadas. Por isso dizem que o contador SQL Server Private Bytes mostra uma quantidade superior ao Total Server Memory.

    Apenas li essas informações mas nao testei ainda, gostaria de saber se é isso mesmo, e qual definitivamente é o contador que irá mostrar a memória como um todo alocada pelo SQL Server.

    Muito obrigado!

Page 1 of 2 (19 items) 12
Leave a Comment
  • Please add 2 and 2 and type the answer here:
  • Post