Introdução
Uma das configurações mais mal-interpretadas, na minha opinião, é a configuração “MAX SERVER MEMORY” no SQL Server. Isso se deve ao fato da Microsoft ter colocado no nome da configuração a palavra “SERVER”.
Até o SQL Server 2008 R2, a configuração “MAX SERVER MEMORY” definia o quanto de memória seria utlizado, essencialmente, para o Buffer Pool, ou Cache de Dados. O que não fizer parte do Buffer Pool vai ser utilizado “além” desta configuração, ou seja, “MAX SERVER MEMORY” não define o total de memória alocado para o servidor, mas somente para o Buffer Pool.
No SQL Server 2012 isso mudou. E não foi somente esta configuração que mudou. A intenção deste artigo é explicar um pouco mais em detalhes como se deu esta alteração de configuração e a partir de agora como iremos configurar o consumo de memória do SQL Server.
SQLOS e o Memory Manager
Para ser breve, SQLOS é o sistema operacional do SQL Server. Ele é composto por diversos componentes (veja imagem abaixo) e um deste componentes é o Memory Manager.
O Memory Manager é responsável por cuidar de todas as alocações de memória no SQL Server. Ele é formado por alguns componentes como os memory nodes, memory clerks, memory caches e memory objects. O Memory Manager é formado por estes componentes pois o acesso à memória do servidor não é feita de maneira direta. É através deste componentes que o Memory Manager faz acesso à memória e a entrega por assim dizer a quem a solicitou.
Memory Nodes são estruturas internas do SQLOS. Seu papel é fornecer a localização de uma alocação de memória. Há três tipos principais de alocação que podem ser realizadas (obs: para não tentar “aportuguesar” as coisas por aqui, irei manter os termos em inglês mesmo =D) :
- Page Allocator
- Virtual Allocator
- Shared Memory Allocator
O que mais nos interesse neste momento é o tipo Page Allocator. Este tipo de alocação é chamada de alocação de páginas pelo que você deve estar imaginando mesmo (!), a alocação é feita em estruturas de 8K, o mesmo tamanho das páginas de dados do SQL Server.
Há quatro tipos de Page Allocators:
- Single Page Allocator
- Multi Page Allocator
- Large Page Allocator
- Reserved Page Allocator
Vamos dar maior atenção para Single e Multi Page Allocator. Como era de se imaginar, as alocações de memória são feitas, respectivamente, em páginas individuais e em multiplas páginas. Estas duas estruturas são a base fundamental das alterações ocorridas no Memory Manager no SQL Server 2012. Logo voltaremos a falar destas estruturas.
Outro componente importante do Memory Manager são os Memory Clerks. Os Memory Nodes não ficam disponíveis para acesso direto. Para que seja feita uma alocação de memória, o solicitante antes cria um Memory Clerk para ter acesso a um Memory Node. Quatro são os tipos de Clerks gerados:
- Generic
- Cache Store
- User Store
- Object Store
A esta altura do campeonato, você, leitor, deve estar se perguntando: e a configuração MAX SERVER MEMORY, o que tem a ver com tudo isso?! Vamos ver qual a relação das estruturas citadas acima com esta configuração.
Novo Memory Manager
O Memory Manager foi reescrito no SQL Server 2012 e a principal alteração se deu através da junção das estruturas de alocação Single Page Allocator (SPA) e Multi Page Allocator (MPA). Uma imagem vale mais que mil palavras, vejam abaixo as mudanças estruturais que o Memory Manager sofreu.
No diagrama do lado esquerdo temos o Memory Manager até o SQL Server 2008 R2. Veja que nele tínhamos ambas as estruturas, SPA e MPA. O Buffer Pool estava ali na parte de baixo e ele representava boa parte da memória consumida pelo SQL Server, sendo alocada através da SPA. Alocações da MPA e outras alocações eram consumidas em outra parte da memória.
Já no novo formato, o Memory Manager consolidou a SPA e a MPA e o Buffer Pool subiu. O que significa isso? O Buffer Pool e outras estruturas fazem uso de um único allocator, tanto single quanto multi e toda esta memória alocada ocupa uma mesma área de memória.
A partir de agora o Buffer Pool vai representar “praticamente” toda a memória do servidor (SQL Server), justificando o nome MAX SERVER MEMORY. Mas atenção, perceba o destaque para “praticamente” pois ainda não irá representar 100% do consumo de memória. Veja que no diagrama, CLR ainda fica de fora desta contagem. Mas temos de concordar que é uma mudança estrutural bem significativa.
Outra imagem que descreve bem as alterações é a que segue abaixo:
As mudanças não param por aqui. A MAX SERVER MEMORY também tem um valor mínimo que pode ser configurado. Não seria possível, apesar de totalmente non-sense, configurar MAX SERVER MEMORY com valor 0 (zero). Até o SQL Server 2008 R2 o valor mínimo de MAX SERVER MEMORY era de 16MB. A partir do SQL Server 2012 os valores mínimos são:
- Ambientes 32bits – 64MB
- Ambientes 64bits – 128MB
Ainda como consequência das alterações estruturais do Memory Manager, as DMVs sys.dm_os_memory_* sofreram alterações, bem como o DBCC memorystatus. Mas isso é assunto para outro post… =D
Referências
Memory configuration and sizing considerations in SQL Server 2012
http://support.microsoft.com/default.aspx?scid=kb;EN-US;2663912
SQL Server Memory Manager Changes in Denali
http://blogs.msdn.com/b/sqlosteam/archive/2011/01/04/sql-server-memory-manager-changes-in-denali.aspx
Memory Manager surface area changes in SQL Server 2012
http://blogs.msdn.com/b/sqlosteam/archive/2012/07/11/memory-manager-surface-area-changes-in-sql-server-2012.aspx
SQLOS’s memory manager and SQL Server’s Buffer Pool
http://blogs.msdn.com/b/slavao/archive/2005/02/11/371063.aspx
Memory Manager Configuration changes in SQL Server 2012
http://blogs.msdn.com/b/sqlosteam/archive/2012/07/12/memory-manager-configuration-changes-in-sql-server-2012.aspx
SQLOS Resources
http://blogs.msdn.com/b/sqlosteam/archive/2010/06/23/sqlos-resources.aspx
SQLOS and Memory Management
http://blogs.technet.com/b/pfelatam/archive/2011/11/03/sqlos-and-memory-management.aspx
Leituras Recomendadas
SQL Server Memory Management Explained
http://www.sqlservercentral.com/articles/Memory/74867/
DBCC MEMORYSTATUS (Parte I)
http://blogs.msdn.com/b/fcatae/archive/2010/07/26/dbcc-memorystatus-parte-1.aspx
DBCC MEMORYSTATUS (Parte II)
http://blogs.msdn.com/b/fcatae/archive/2010/11/08/dbcc-memorystatus-parte-ii.aspx
Cache de Dados
http://blogs.msdn.com/b/fcatae/archive/2010/06/25/cache-de-dados.aspx
Monitorando a Memória do SQL Server
http://blogs.msdn.com/b/fcatae/archive/2010/06/16/monitorando-a-mem-243-ria-do-sql-server.aspx
Memory: Working Set
http://blogs.msdn.com/b/fcatae/archive/2010/03/31/memory-working-set.aspx
Espero que tenham gostado da leitura. Bons estudos e até breve.
Erickson Ricci (@EricksonRicci)
Inside DBA's Life 