Usando os Memory Objects

  • Article

Tudo começou com a discussão de XML.

Memory Leak usando OPENXML
https://blogs.msdn.com/b/fcatae/archive/2014/02/18/sp-xml-preparedocument-leak.aspx

Existem duas procedures:

  • sp_xml_preparedocument
  • sp_xml_removedocument

A primeira serve para reservar a memória para o documento, enquanto que a segunda libera o recurso. Existe uma forma de causar um Memory Leak chamando várias vezes a procedure de “prepare” e esquecendo de liberar a memória com “remove”.

Em todos os problemas de alto consumo de memória, recomendo que utilize a monitoração de Memory Clerk.

Monitorando Memória com os Clerks
https://blogs.msdn.com/b/fcatae/archive/2014/02/25/monitorando-memoria.aspx

Se mesmo assim não for possível descobrir, podemos acompanhar o consumo de memória através dos MemObj.

Cada Memory Clerk é composto por uma série de alocações feitas pelo subcomponente chamado MemObj. Experimente rodar a query abaixo:

select *
from sys.dm_os_memory_objects mo join
     sys.dm_os_memory_clerks mc
on mo.page_allocator_address = mc.page_allocator_address
where mc.type = 'MEMORYCLERK_SQLGENERAL'
order by pages_in_bytes desc

Na query exemplo, estamos procurando os MemObj responsáveis pelo alto consumo do Memory Clerk.

O resultado apresenta os principais subconsumidores de memória:

image

Agora podemos afirmar com 100% de certeza que o principal responsável é o MEMOBJ_MSXML. Sim – o problema de Memory Leak foi causado pelo XML!