SQL Server e Windows Large Pages Allocation

Um dos principais pontos para manter seu servidor SQL Server funcionando bem é saber fazer bom uso da memória do servidor. Para isso, um dos recursos que temos é configurá-lo para que use SMALL ou LARGE page allocations.

Antes então de continuar, vou falar um pouco sobre page allocations.

O Virtual Address Space (VAS) é formado por páginas de dois tipos pequenas (small) de 4kb e grandes (large) de 2mb. Para controlar o uso/acesso a estas páginas existe a Page Table (tabela de páginas) onde para cada página é registrada uma Page Table Entry (registro na tabela de páginas) apontando para aquela Page Table.

Então, qual as vantagens/desvantagens de utilizarmos uma página pequena ou grande? Se temos páginas maiores, teremos uma quantidade menor de Page Table Entry o que fará com que a busca por dados em memória seja mais rápida, mas esse processo tende a consumir a memória de forma mais rápida, já que teremos sempre que consumir 2mb da mesma. Já com páginas menores, temos o processo inverso, uma maior quantidade de Page Table Entry, fazendo com que a procura pelos dados em memória seja um pouco mais lenta, mas a tendência é que se faça um uso um pouco melhor da memória, já que o “desperdício” será menor.

* Na verdade o processo acima é um pouco mais “complicado”, pois existe um cache de Translation Look-Aside Buffer (TLB) que faz a tradução da Page Entry, mas não vamos entrar nesse nível de detalhe, mas segue uma figura abaixo para ilustrar um pouco

Translation Look Aside Buffer
Translation Look Aside Buffer

Sabendo disso, podemos concluir que o uso de Large Pages depende do seu ambiente e como uma linha geral isso só trará benefícios para ambientes com uma carga considerável.

Agora que já sabemos o que são as Page Tables precisamos saber como configurar o SQL Server para utilizar Small ou Large Page Tables.

Por padrão o SQL Server utiliza Small Page tables, então para utilizar as Large Page você deve ativar o trace flag 834. Esse recurso só é disponível para ambientes SQL Server 64 bits e é necessário que a conta de serviço possua a permissão de “Lock Pages in memory”.

Caso você tenha este recurso ativado verá a seguinte mensagem no log do SQL Server:

Large Page Extensions enabled.
Large Page Granularity: 2097152
Large Page Allocated: 32MB
Using large pages for buffer pool.
10208 MB of large page memory allocated

E caso ele não esteja ativado, será algo desse tipo:

Cannot use Large Page Extensions: lock memory privilege was not granted.

Agora devemos correr para nossos servidores e ativar este recurso?! Não!! Como tudo, este recurso tem suas considerações.

Ao ativar este recurso, o SQL Server ao inicializar vai tentar alocar toda a memória de uma ÚNICA vez, pois seria custoso alocar apenas parte da memória e depois ir aumentando a quantidade. Além disto, esta região de memória precisa ser CONTÍNUA, por isso só é recomendado utilizar este recurso em máquinas dedicadas ao SQL Server.

Outro ponto importante é que o SQL Server vai tentar alocar a quantidade de memória especificada em “Max Server Memory” (você tem isso configurado em seu servidor, correto?!) e, caso este valor não tenha sido configurado, ou seja é igual a 0 (zero), ele vai tentar alocar TODA a memória do servidor.

Caso ele não consiga alocar a quantidade de memória especificada em “Max Server Memory”, são feitas várias tentativas para alocar uma quantidade “menor” (não sei qual o algoritmo para essa quantidade menor, mas acredito que ele vá diminuindo a quantidade em algo como 1GB. Se alguém conhecer melhor o processo, gostaria de conhecer) de memória, e este processo pode deixar a inicialização do serviço bem lenta! Caso ele consiga uma quantidade “menor”, o serviço é iniciado e tal quantidade é registrada no log do SQL Server.

Caso o SQL Server NÃO consiga alocar uma quantidade razoável de memória (também não sei qual este valor “mínimo”) o serviço não será iniciado e será registrado um erro no log também.

Segue um exemplo de entrada de log onde houve esse problema:

2009-06-04 12:18:32.41 Server      Large Page Extensions enabled.
2009-06-04 12:18:32.41 Server      Large Page Granularity: 2097152
2009-06-04 12:18:32.41 Server      Large Page Allocated: 32MB
2009-06-04 12:18:32.46 Server      Using large pages for buffer pool.
2009-06-04 12:18:32.88 Server      0 MB of large page memory allocated.
2009-06-04 12:18:39.21 Server       Failed allocate pages: FAIL_PAGE_ALLOCATION 1
2009-06-04 12:18:39.22 Server

Segue também um exemplo onde “apenas” 2GB de memória foram alocados

2009-06-04 14:20:31.13 Server      Large Page Extensions enabled.
2009-06-04 14:20:31.13 Server      Large Page Granularity: 2097152
2009-06-04 14:20:31.14 Server      Large Page Allocated: 32MB
2009-06-04 14:20:40.03 Server      Using large pages for buffer pool.
2009-06-04 14:27:56.98 Server      2048 MB of large page memory allocated.

Por fim, uma situação interessante. Este recurso pode ser ativado AUTOMATICAMENTE em seu servidor, desde que este atenda 3 requisitos:

1) Enterprise Edition (64 bits!)

2) Computador tem 8GB de RAM ou mais

3) Permissão de “Lock Pages in Memory” configurada para a conta de serviço do SQL Server (precisa reiniciar para que tenha efeito!)

* Para verificar, como dito anteriormente, basta ler o log do seu servidor!

** Se você usa SQL Server 2008 em diante, pode usar este comando para verificar o uso de Large Pages:

select large_page_allocations_kb from sys.dm_os_process_memory

*** Se você tem um ambiente virtualizado em VMWare, parece que este recurso causa problemas: http://www.gabesvirtualworld.com/large-pages-transparent-page-sharing-and-how-they-influence-the-consolidation-ratio/ (se alguém tiver informações sobre o uso deste recurso em ambientes virtualizados Hyper-V eu gostaria de saber!)

****Este recurso está disponível a partir do SQL Server 2005

Bem, espero que este post ajude a entender este recurso e gostaria de receber comentários e/ou correções!

Fonte inicial para esse post: http://www.sqldbadiaries.com/2011/03/04/configuring-sql-server-to-use-windows-large-page-allocations/

Mais informações:

http://blogs.msdn.com/b/psssql/archive/2009/06/05/sql-server-and-large-pages-explained.aspx

http://msdn.microsoft.com/en-us/library/aa366912(v=vs.85).aspx

Esse post foi publicado em Artigos, Virtual PASS BR. Bookmark o link permanente.

7 respostas para SQL Server e Windows Large Pages Allocation

  1. Madson disse:

    recurso muito interessante! legal o post. Parabens.

  2. Oi Vlad! Parabéns pelo artigo, espero que haja muitos outros nesse nível de detalhes. Ótima discussão sobre o assunto.. algumas considerações adicionais sobre Large Page: 1) É necessário habilitar o Trace Flag 834 para ter (quase) TODA a memória alocada usando o mecanismo de Large Pages do Windows. 2) Ao habilitar o TF, o gerenciamento de memória fica estático (Min Memory = Max Memory). 3) Quando o TF não está habilitado, o SQL ainda pode utilizar Large Pages para uma pequena porção da memória (geralmente o Buffer Hash) e isso não possui falhas. 4) E o mais importante de tudo é que não recomendamos o uso do Large Pages, a menos que exista uma necessidade de tuning extrema.
    Abraços, Fabricio

  3. Muito bom o post e o comentário do Catae. Conhecia muito superficialmente sobre large pages. Valeu galera!🙂
    Uma dúvida.. em um cenário de DW, será que não seria interessante a utilização de large pages?

  4. Leivio disse:

    Parabéns pelo artigo e pelo tema escolhido.

    Só complementando o artigo com alguns valores impiricos que obtive durante a minha
    experiência com a aplicação do LP.

    Não existe uma relação direta para quantidade de memoria e tempo para construção do mapa de paginas largas continuas. Por que isso depende mais da arquitetura do hardware(FSB, Clock, Procs e mecanismo de acesso a memoria local\estrangeira).

    * Hardware IBM 3650 35GB – 22 Minutos
    * Hardware IBM 3850 X5 2.0TB – 6 minutos
    * Hardware IBM 3950 X3 128GB – 50 Minutos

    Como podemos ver acima, temos valores diferentes para arquiteturas de acesso a memoria diferente.

    Quando a alocação do “Max Memoria” falha a instancia tenta alocar novamente alocar a memoria continua, porem aplica 0,75 ao valor da primeira tentativa. se falhar novamente será aplicado 0,75 a segunda tentativa…e assim por diante.

    Hoje no ambiente que administro temos apenas uma necessidade de usar LP para a área de cache de dados do SQL Server com TF 834 .

    abraços,
    Leivio Fontenele

  5. magalhaesv disse:

    Ae pessoal, muito obrigado pelos comentários.

    Catae, muito obrigado por mais estas informações, mas como perguntei por mail, estranho isso só ser recomendado em ambientes extremos e o SQL Server ativar isso automaticamente no cenário que falei.

    Zavaschi, quanto a DW não é minha especialidade, mas acredito que seja um ambiente mais propício ao uso desse recurso.

    Leivio, muito interessante os números que você apresentou, realmente a arquitetura fez MUITA diferença. Agora, como você conseguiu esse número de 0,75, através de testes?

  6. Leivio disse:

    Isso mesmo. Não encontrei nenhuma referencia em nenhuma documentação. Então realizei uma sequencia de testes em varaos maquinas com memoria e e arquitetura diferente. O valor 0,75 e impirico mesmo.

  7. Ótimos comentários de todos!!! Deixo tentar agregar algo novo..
    Também não sei a resposta para a pergunta do Zavaschi, mas meu palpite é que Large Pages (LP) seja indiferente a OLTP/DW. Como o LP otimiza o tempo de mapeamento das páginas e melhora a performance do TLB, então os ganhos não são em disco. Sinceramente, nunca apliquei esse Trace Flag para poder medir.. então não posso falar mais.
    Quanto ao comentário do Leivio, o algoritmo é um pouco complexo porque leva em conta fragmentos de memória de diferentes tamanhos. Infelizmente o Large Pages é feito sempre e somente no Startup do serviço. Legal esse valor empírico de 0,75, vale a pena fazer um teste para tentar saber melhor esse comportamento. Por outro lado, existem alguns comportamentos “estranhos” do Windows como a fragmentação de memória contínua, que pode causar falhas inexplicáveis e tornar o Large Pages um pouco arriscado.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s