Eu tenho um único nó do SQL2012 SP4 executando vários bancos de dados.

O servidor possui 20 GB de memória disponível, 14 GB alocados ao SQL (nada mais está sendo executado na caixa).

A cada poucos minutos, o SQL despeja todo o cache do buffer. A expectativa de vida da página chega a zero, os descritores do cache do buffer mostram que não há nada no cache.

Eu dei uma olhada nas notificações do monitor de recursos e as notificações estão saltando de alta / constante / baixa a cada poucos milissegundos:

RESOURCE_MEMPHYSICAL_HIGH RESOURCE_MEM_STEADY RESOURCE_MEMPHYSICAL_LOW

Com registros de data e hora com vários milissegundos de diferença. O PLE é essencialmente um padrão de dente de serra.

Já vi isso acontecer antes com o SQL2012 SP1 e esta pergunta:

Páginas gratuitas do SQL Server 2012 no cache de buffer não sendo usadas

Parece ser um problema semelhante, embora eu já tenha atualizado para o SP4.

Tentei ativar o LPIM para a conta de serviço e tentei mexer com a configuração de memória máxima. A redução da memória máxima parece ter causado o cache do buffer com mais freqüência.

Alguma idéia do que verificar em seguida?

A carga de trabalho do servidor é literalmente nada (estou percorrendo as listas de itens em um sistema ERP e chega a cerca de 40 a 50 MB antes que o cache caia novamente).

É interessante porque atualizei o SP1 para tentar corrigir isso - o cache estava chegando a cerca de 500 MB. Desde então, reduzi a configuração de memória máxima para 14 GB, o que parece ter piorado.

Eu estou querendo saber se o Windows está entrando em pânico e emitindo notificações incorretas para pressão de memória no SQL - segue-se que o servidor com memória máxima configurada como ilimitado parecia funcionar bem, mas nunca preenche o cache mais do que algumas centenas de MB - mas agora mal chega a 50 ...

Mais informações: para quem pediu

Número de cores: 4

Tamanho do banco de dados: 80GB

O log de erros mostra: A significant part of sql server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 247928, committed (KB): 495656, memory utilization: 50%.

Resultados da execução de scripts neste link: https://www.sqlskills.com/blogs/jonathan/identifying-external-memory-pressure-with-dm_os_ring_buffers-and-ring_buffer_resource_monitor/

Não sei como interpretá-los - parece que há pressão de memória interna e externa em vários momentos.

Ainda mais informações:

Este é um convidado do Hyper-V sentado em um host com 96 GB de RAM total, dos quais cerca da metade é alocada para os convidados.

Os sintomas parecem semelhantes a este:

SQL Server 2012 x64 - não é possível alocar com segurança mais de 50% de RAM

No entanto, quando aloquei 14 GB no SQL, os sintomas entraram em ação imediatamente (apenas 3 GB da memória do servidor foram confirmados)

Ontem à noite, instalei a memória de convidado em 32 GB e o problema foi resolvido, mas vejo apenas 14 GB de comprometimento da memória total do servidor (e os negócios que executam o banco de dados estão ocupados hoje de manhã e é quando eles geralmente têm problemas de desempenho).

Cerca de 8 a 9 GB de dados no cache no momento parecem estar estáveis.

Parece sugerir que 20 GB são suficientes para a carga de trabalho nessa caixa. Estou feliz por deixá-lo com 32 GB por enquanto, mas eu realmente gostaria de entender isso para que eu possa configurar melhor as VMs / SQL.

Vou continuar pesquisando e atualizando se encontrar a resposta!

Ainda mais informações:

Não reiniciei o SQL depois de ativar o LPIM (sem perceber que era um requisito), mas deixei essa configuração ativada e reiniciei para atualizar a memória. Agora, não tenho certeza se o aumento na memória ou no LPIM aliviou os problemas.

Irá pular esta noite quando o servidor estiver ocioso e verificar como ele fica com 20 GB novamente.

Ainda Mais Mais Informações:

Atualmente, o servidor está funcionando bem, com 32 GB alocados e não vimos o problema desde então. Se isso aparecer novamente, voltarei a esta pergunta e continuarei cavando.

Atualmente permanece um mistério, mas meu palpite é que só estou ocultando os problemas no momento.

Embora você pareça ter resolvido o problema sozinho, aqui está um resumo das informações relevantes em torno da solução.

Memória do servidor Opções de configuração do servidor

A Microsoft escreve no artigo Opções de configuração do servidor de memória do servidor (Microsoft | SQL Docs) para a seção Definindo as opções de memória manualmente

_{( ênfase minha)}

Além disso, a configuração de um valor min_server_memory é essencial em um ambiente virtualizado para garantir que a pressão da memória do host subjacente não tente desalocar a memória do buffer pool em uma máquina virtual (VM) do SQL Server convidada além do necessário para um desempenho aceitável.

A seção referente a Bloquear páginas na memória (mesmo documento) possui um parágrafo atraente que se lê como:

_{( ênfase minha)}

Esta política do Windows determina quais contas podem usar um processo para manter os dados na memória física, impedindo que o sistema pagine os dados para a memória virtual no disco . O bloqueio de páginas na memória pode manter o servidor responsivo quando ocorre a paginação da memória no disco. A opção Bloquear páginas na memória é ativada nas instâncias do SQL Server Standard edition e superior quando a conta com privilégios para executar o sqlservr.exe recebe o direito de usuário do Windows Lock Pages in Memory (LPIM).

A seção LPIM continua explicando que:

_{( ênfase minha)}

A configuração desta opção não afeta o gerenciamento de memória dinâmica do SQL Server, permitindo a expansão ou redução a pedido de outros funcionários da memória. Ao usar o direito de usuário Bloquear páginas na memória, é recomendável definir um limite superior para a memória máxima do servidor, conforme detalhado acima.

... e em um comentário importante que:

_{( ênfase minha)}

A configuração dessa opção deve ser usada apenas quando necessário, ou seja , se houver sinais de que o processo sqlservr está sendo paginado . Nesse caso, o erro 17890 será relatado no log de erros, semelhante ao exemplo abaixo:

A significant part of sql server process memory has been paged out. 
This may result in a performance degradation. Duration: #### seconds. 
Working set (KB): ####, committed (KB): ####, memory utilization: ##%.  

A partir do SQL Server 2012 (11.x), o sinalizador de rastreamento 845 não é necessário para o Standard Edition usar Páginas Bloqueadas.

Solução

Com base nas descobertas acima e nas suas observações, a solução para o seu problema seria definir as seguintes configurações:

1. min_server_memory (5-10 GB?) Com base no seu comentário:

   Cerca de 8 a 9 GB de dados no cache no momento parecem estar estáveis.

   ... e a recomendação da Microsoft de definir a min_server_memory.

2. max_server_memory (20-32 GB) com base em sua observação:

   Parece sugerir que 20 GB são suficientes para a carga de trabalho nessa caixa. Estou feliz por deixá-lo com 32 GB por enquanto, mas eu realmente gostaria de entender isso para que eu possa configurar melhor as VMs / SQL.

   ... e a recomendação da Microsoft de definir a max_server_memory.

3. Bloquear páginas na memória: habilitado para a conta de serviço do SQL Server.
   Com base na entrada ERRORLOG da sua instância do SQL Server que você mencionou e na referência da Microsoft no artigo.

   A configuração dessa opção deve ser usada apenas quando necessário, ou seja , se houver sinais de que o processo sqlservr está sendo paginado .

Antes de continuar ...

(Um dos) benefícios de ter um ambiente virtualizado é que os recursos podem / devem ser compartilhados e possivelmente comprometidos demais. No entanto, ativar o bloqueio de páginas na memória (LPIM) pode ter um impacto negativo no seu ambiente Hyper-V, se o seu hardware estiver hospedando várias instâncias. Um comprometimento excessivo da RAM pode esgotar outras instâncias.

Antes de considerar mudar todas as alavancas, comece com as configurações 1. e 2. e se o ajuste fino dessas configurações de memória não funcionar, considere ativar o LPIM se você tiver hardware suficiente .