Estamos experimentando um crescimento lento de memória roubada em nossos servidores de banco de dados no espaço de vários dias. Parece atingir um platô em torno de 130-140 GB, momento em que começamos a ter problemas maiores, como erros de falta de memória, congelamentos de vários segundos e failovers de AG. Os problemas começam a se manifestar cerca de uma semana após a reinicialização. Comecei a registrar o histórico de memória roubada, que é mostrado abaixo:
Olhando para sys.dm_os_memory_clerks, parece que a maior parte disso vem da memória não-página registrada no buffer pool no nó NUMA 0:
O rastreamento do total pages_kbdo buffer pool ao longo do tempo mostra o declínio no número de páginas à medida que virtual_memory_committed_kbaumenta. (Em 13 de abril, o servidor foi reinicializado para atualizações do Windows. O pool de buffers chega a 400 GB em cerca de uma hora)
Alguém já viu esse comportamento antes?
Estamos executando o SQLServer 2016 CU12 13.0.5698.0 O servidor é uma instância AWS EC2 i3.16xlarge de 64 núcleos. Temos vários outros clusters do mesmo tamanho que estão apresentando esse problema. Também temos alguns clusters em instâncias i3.8xlarge de 32 núcleos que também mostram o crescimento da memória roubada, mas não acabam travando / gerando erros de falta de memória. A única diferença (além da escala) é que os servidores de 64 núcleos possuem 2 nós NUMA.
Atualização: MS indicou que a correção de bug no KB4536005 não está sendo portada para SQL2016.
eu tenho uma suspeita. Primeiro - você consegue abrir tíquetes de suporte com a Microsoft?
A maneira mais fácil de verificar minha suspeita é capturar [\SQLServer:Memory Node(*)\Stolen Node Memory (KB)] para ambos os nós NUMA e comparar a soma com [\SQLServer:Memory Manager\Stolen Server Memory (KB)]. Se minha suspeita estiver correta, quando o problema estiver se formando, a discrepância entre os dois - que parece que eles sempre devem concordar - será bastante alta. A outra característica reveladora: até N-1 nós SQLOS NUMA podem ter mostrado esta relação (onde N é a contagem de nós NUMA) [memória do nó do banco de dados] + [memória do nó roubado] + [memória livre do nó] > [total memória do nó]
eu descrevo o problema um pouco nestes posts.
https://sql-sasquatch.blogspot.com/2018/07/sql-server-2016-memory-accounting.html
https://sql-sasquatch.blogspot.com/2018/10/sql-server-2016-memory -parte-contabilidade.html
O problema básico de contabilidade é que, às vezes, o crescimento do buffer pool ocorre de uma maneira que os blocos descritores de buffer são alocados do nó SQLOS A, mas as páginas referenciadas no bdbs realmente vêm do nó SQLOS B. O resultado dessa condição é que uma parte da memória física controlada pelo SQLOS é contada duas vezes: a mesma memória é contabilizada no nó A (onde os bdbs vivem) como [Database Node Memory] E contabilizada no nó SQLOS B como [Stolen Node Memory]. Essa situação é confusa e ineficiente... mas ainda não é a plena floração do problema.
O problema floresce completamente quando tanto Nó B [memória de nó roubado] também é Nó A [memória de nó de banco de dados] que Nó B [memória de nó de banco de dados] cai para ~2% do Nó B [memória de nó de destino]. Quando isso acontece, a taxa de [\SQLServer:Buffer Manager\Free list stalls/s] dispara - vimos 2000/s quando isso aconteceu conosco. O SQL Server está tentando corrigir o problema (muito pouco [memória do nó do banco de dados]) no Nó B cortando vários tipos de cache no Nó B. Mas não pode!! Porque a [memória do nó roubado] não está em nenhum dos vários tipos de cache esperados.
Resolução temporária: quando [memória total do nó] se aproxima de [memória do nó alvo] mas [memória do nó do banco de dados] se aproxima de 2% da [memória do nó alvo], execute DBCC DROPCLEANBUFFERS.
kb4536005 resolve esse problema no SQL Server 2017 CU20 e SQL Server 2019 CU2. https://support.microsoft.com/en-us/help/4536005/improvement-fix-incorrect-memory-page-accounting-that-causes-out-of-me
Há uma correção de som semelhante no SQL Server 2016 SP2 CU5, kb4470916. https://support.microsoft.com/en-ca/help/4470916/fix-out-of-memory-error-occurs-when-database-node-memory-kb-drops-belo
No entanto, não acredito que kb4470916 resolva o problema com a contabilidade dupla. Portanto, embora possa melhorar a resposta do SQL Server a um único nó SQLOS com [memória do nó do banco de dados] no limite de ~ 2%, acho que deixa em aberto a possibilidade de cutucar o urso devido a essa contagem dupla. E essa pode ser a situação em que você se encontra.
No entanto, se a soma de [memória do nó roubado] nos dois nós sempre se alinhar com [memória do servidor roubada] na instância, você pode esquecer tudo isso como se fosse um pesadelo. :-)