A virtualização é muito popular para as organizações:permite que elas utilizem melhor o hardware combinando vários servidores em um único host, fornece recursos de alta disponibilidade e reduz vários custos, como aquecimento/resfriamento, licenças do SQL Server e hardware. Estive envolvido em vários projetos com organizações para ajudá-las a migrar de ambientes físicos para virtuais e as ajudei a experimentar esses benefícios.
O que quero compartilhar com você neste artigo é um problema peculiar que encontrei ao trabalhar com o Hyper-V no Windows Server 2012 R2 usando memória dinâmica. Devo admitir que a maior parte do meu conhecimento de virtualização foi com VMware, mas isso está mudando agora.
Ao trabalhar com o SQL Server no VMware, sempre recomendo definir reservas de memória, portanto, quando encontrei esse recurso de memória dinâmica com o Hyper-V, tive que fazer algumas pesquisas. Encontrei um artigo (Guia de configuração de memória dinâmica do Hyper-V) que explica muitos dos benefícios e requisitos do sistema para usar a memória dinâmica. Esse recurso é bem legal na forma como você pode fornecer uma máquina virtual com mais ou menos memória sem que ela precise ser desligada.
Brincando com o Hyper-V, descobri que o provisionamento de máquinas virtuais é simples e fácil de aprender. Com pouco esforço, consegui construir um ambiente de laboratório para simular a experiência que meu cliente estava tendo. O crédito vai para o meu chefe por me fornecer um hardware incrível para trabalhar. Estou executando um Dell M6800 com um processador i7, 32 GB de RAM e dois SSDs de 1 TB. Esta fera é melhor do que muitos servidores em que trabalhei.
Usando o VMware Workstation 11 no meu laptop, criei um convidado do Windows Server 2012 R2 com 4 vCPUs, 24 GB de RAM e 100 GB de armazenamento. Depois que o convidado foi criado e corrigido, adicionei a função Hyper-V e provisionei um convidado no Hyper-V. O novo convidado foi construído com o Windows Server 2012 R2 com 2 vCPUs, 22 GB de RAM e 60 GB de armazenamento executando o SQL Server 2014 RTM.
Executei três conjuntos de testes, cada um usando memória dinâmica. Para cada teste, usei o SQL Data Generator da Red Gate no banco de dados AdventureWorks2014 para preencher o pool de buffers. Para o primeiro teste, comecei com 512 MB para o valor de RAM de inicialização, pois essa é a quantidade mínima de memória para iniciar o Windows Server 2012 R2 e o pool de buffers parou de aumentar em cerca de 8 GB.
Para cada teste, eu truncaria minha tabela de teste, desligaria o convidado, modificaria as configurações de memória e iniciaria o backup do convidado. Para o segundo teste, aumentei a RAM de inicialização para 768 MB e o pool de buffers aumentou apenas para pouco mais de 12 GB.
Para o terceiro e último teste aumentou a RAM de inicialização para 1024 MB, executou o gerador de dados e o pool de buffers foi capaz de aumentar para pouco menos de 16 GB.
Fazer um pouco de matemática nesses valores mostra que o pool de buffers não pode crescer mais de 16 vezes a RAM de inicialização. Isso pode ser muito problemático para o SQL Server se a RAM de inicialização for menor que 1/16 do tamanho da memória máxima. Vamos pensar em um convidado Hyper-V com 64 GB de RAM executando o SQL Server com um valor de RAM de inicialização de 1 GB. Observamos que o pool de buffers não poderia usar mais de 16 GB com essa configuração, mas se definirmos o valor de RAM de inicialização para 4096 MB, o pool de buffers poderá aumentar 16 vezes, permitindo usar todos os 64 GB.
As únicas referências que encontrei sobre por que o pool de buffers é limitado a 16 vezes o valor da RAM de inicialização estavam nas páginas 8 e 16 do whitepaper, Práticas recomendadas para executar o SQL Server com HVDM. Este documento explica que, como o valor do cache do buffer é calculado no momento da inicialização, é um valor estático e não cresce. No entanto, se o SQL Server detectar que há suporte para Hot Add Memory, ele aumentará o tamanho reservado para o espaço de endereço virtual do pool de buffers em 16 vezes a memória de inicialização. Este documento também afirma que esse comportamento afeta o SQL Server 2008 R2 e anteriores, no entanto, meu teste foi realizado no Windows Server 2012 R2 com SQL Server 2014, então entrarei em contato com a Microsoft para atualizar o documento de práticas recomendadas.
Como a maioria dos DBAs de produção não provisionam máquinas virtuais ou trabalham muito nesse espaço, e os engenheiros de virtualização não estão estudando a melhor e mais recente tecnologia do SQL Server, posso entender como essas informações importantes sobre como o pool de buffer lida com a Memória Dinâmica são desconhecidas para muitos de pessoas.
Mesmo seguindo os artigos pode ser enganoso. No artigo Guia de configuração de memória dinâmica do Hyper-V, a descrição da RAM de inicialização diz:
Especifica a quantidade de memória necessária para iniciar a máquina virtual. O valor precisa ser alto o suficiente para permitir que o sistema operacional convidado seja iniciado, mas deve ser o mais baixo possível para permitir a utilização ideal da memória e taxas de consolidação potencialmente altas.
Utilização ideal da memória para quem, o host ou o convidado? Se um administrador de virtualização estivesse lendo isso, provavelmente determinaria que isso significa a memória mínima permitida para iniciar o sistema operacional.
Ser responsável pelo SQL Server significa que precisamos conhecer outras tecnologias que podem influenciar nosso ambiente. Com a introdução de SANs e virtualização, precisamos entender completamente como as coisas nesses ambientes podem impactar negativamente o SQL Server e, mais importante, como comunicar efetivamente as preocupações às pessoas responsáveis por esses sistemas. Um DBA não precisa necessariamente saber como provisionar armazenamento em uma SAN ou como provisionar ou ser capaz de administrar um ambiente VMWare ou Hyper-V, mas deve saber o básico de como as coisas funcionam.
Conhecendo o básico sobre como uma SAN funciona com matrizes de armazenamento, redes de armazenamento, caminhos múltiplos e assim por diante, bem como como o hipervisor funciona com o agendamento de CPUs e alocação de armazenamento na virtualização, um DBA pode se comunicar melhor e solucionar problemas quando surgirem problemas . Ao longo dos anos, trabalhei com sucesso com vários administradores de SAN e virtualização para criar padrões para o SQL Server. Esses padrões são exclusivos do SQL Server e não se aplicam necessariamente a servidores Web ou de aplicativos.
Os DBAs não podem realmente confiar nos administradores de SAN e virtualização para entender completamente as práticas recomendadas para o SQL Server, independentemente de quão bom isso seria, portanto, precisamos nos educar o melhor que pudermos sobre como suas áreas de especialização podem nos afetar.
Durante meus testes, usei uma consulta da postagem do blog de Paul Randal, Problemas de desempenho de memória de pool de buffer desperdiçada, para determinar quanto pool de buffer o banco de dados AdventureWorks2014 estava usando. Incluí o código abaixo:
SELECT
(CASE WHEN ([database_id] = 32767)
THEN N'Resource Database'
ELSE DB_NAME ([database_id]) END) AS [DatabaseName],
COUNT (*) * 8 / 1024 AS [MBUsed],
SUM (CAST ([free_space_in_bytes] AS BIGINT)) / (1024 * 1024) AS [MBEmpty]
FROM sys.dm_os_buffer_descriptors
GROUP BY [database_id]; Esse código também é ótimo para solucionar problemas de quais bancos de dados estão consumindo a maior parte de seu pool de buffers, para que você possa saber em qual banco de dados deve se concentrar no ajuste das consultas de alto custo. Se você for uma loja do Hyper-V, verifique com seu administrador se a Memória Dinâmica pode ser configurada de forma a impactar negativamente seu servidor.
