O SQL Server se torna mais lento com o tempo, até que tenhamos que reiniciá-lo

Temos um banco de dados com uma carga de trabalho OLAP / OLTP mista. As consultas são bastante ad-hoc e são criadas dinamicamente no servidor de aplicativos de camada intermediária. Quando iniciamos o servidor, o desempenho é bastante aceitável, mas o consumo de memória aumenta cada vez mais até que toda a memória disponível (30 GB) se esgote. Depois disso, o sistema fica cada vez mais lento.

Comandos como Dbcc freeproccachenão têm efeito.

Não há muitas transações select * from sys.dm_tran_session_transactions(não mais do que quando o sistema está bom); algumas vezes essa lista está vazia.

O primeiro resultado de dbcc memorystatusé

VM Reserved               42136628
VM Committed               1487176
Locked Pages Allocated    24994048
Reserved Memory               1024
Reserved Memory In Use           0

Uma reinicialização do SQL Server resolve o problema por um tempo.

1. O que causa esse comportamento? Como isso pode ser evitado?
2. Se uma solução real para a causa for muito difícil, existe um comando que força o SQL Server a liberar toda a memória sem uma reinicialização completa do DBMS?

O servidor está sendo executado em hardware dedicado (não em uma VM). Tínhamos alguns trabalhos agendados, mas os desativamos por um tempo, sem alterações. Existem outros aplicativos de camada intermediária em execução no mesmo servidor, mas eles usam não mais que 2 GB de memória, CPU desprezível e quase nenhuma E / S. Reiniciámos todos esses aplicativos sem alterações.

Sugiro coletar métricas de desempenho neste servidor, para que você possa eliminar as suposições da solução desses tipos de problemas. Consulte este artigo para obter um guia mais completo, se você não souber por onde começar.

Em particular, eu verificaria os contadores de desempenho Memory\Available MBytese Paging File(_Total)\% Usageporque você disse que os problemas só começam a ocorrer quando o buffer pool está cheio. Os números que você recebe desses contadores podem indicar que a configuração máxima de memória do servidor precisa ser ajustada (para cima ou para baixo) para a quantidade de memória física alocada para o servidor. Como mencionei aqui , não recomendo basear a configuração de memória máxima na quantidade de memória física, exceto como um palpite para um ponto de partida . Sempre meça o resultado e ajuste a partir daí.

Se a quantidade de memória livre for muito baixa (<500) ou o uso do arquivo de paginação for superior a zero , isso pode indicar que a instância do SQL Server foi supercomprometida: no SQL Server 2008 R2, a configuração de memória máxima do servidor controla apenas o tamanho do buffer pool , e não outro uso de memória, como o cache do plano. O SQL Server também não se importa com outros aplicativos que você possa ter executando no sistema. Esse uso extra de memória pode pressionar a memória do Windows - ou de outros aplicativos - possivelmente levando à troca de disco. Isso é algo que você deseja evitar a todo custo, principalmente se o arquivo de paginação existir em um volume apoiado por apenas um simples espelho RAID 1. Meu sentimento é que esse é o problema, e o backup da configuração de memória máxima do servidor deve resolver o problema.

Se a quantidade de memória livre for alta (> 1000) e o uso do arquivo de paginação for zero, provavelmente você poderá aumentar um pouco a memória máxima do servidor (em incrementos de 256 MB) para maximizar o uso de memória do servidor. No entanto, isso provavelmente não resolverá o problema, e você precisará procurar em outro lugar, provavelmente nos contadores de disco físico e na expectativa de vida da página do buffer pool. Se as consultas estiverem debulhando o pool de buffers, nada poderá ser feito, exceto melhorar o desempenho do disco, aumentar a quantidade de memória física disponível para o servidor, para que todas as páginas de dados possam caber na memória de uma só vez ou modificar o banco de dados para não ocupar tanto espaço físico (talvez usando compactação de linha ou página ou reconstruindo índices com um valor mais alto FILLFACTOR).

Eu publiquei um artigo sobre este tópico aqui que aborda mais detalhadamente esse problema e como resolvê-lo.

Geralmente, a tendência de lentidão ao longo do tempo deve ser inversa, porque, à medida que as páginas dos bancos de dados se movem para o cache, o desempenho deve melhorar (a expectativa de vida da página e a taxa de acertos do buffer aumentam com o tempo), você configurou sua memória máxima para (total_physical_mem - 2GB)?

Parece que algumas das suas consultas estão fazendo com que o SQL Server pagine e pagine muitas coisas. Você pode tentar o Administrador de Recursos para limitar o consumo de memória das consultas grandes e médias, para que as consultas do aplicativo sempre tenham buffer suficiente disponível.