Monitorando Memória com os Clerks

No último post, comentei sobre um erro relacionado à falta de memória no servidor SQL Server. Essa era a mensagem de erro:

Msg 6624, Level 16, State 7, Procedure sp_xml_preparedocument, Line 1
XML document could not be created because server memory is low. Use sp_xml_removedocument to release XML documents.

Como próximo passo, minha sugestão foi investigar as sessões do servidor.

select session_id, memory_usage from sys.dm_exec_sessions
where status = 'sleeping' and is_user_process = 1

Assim, suspeitamos que a sessão 56 era culpada porque estava alocando 3080 páginas de 8Kb alocadas (24MB).

Algo Estranho!

Repetindo:

“… suspeitamos que a sessão 56 era culpada porque estava alocando 3080 páginas de 8Kb alocadas (24MB)”

Esse parece um comportamento diferente…

Como que 24MB pode afetar causar falta de memória em um servidor com GB de memória?

Algo estranho…

Monitorando Memória

Monitorar o consumo de memória usando a sys.dm_exec_sessions não é um método confiável. Essa DMV apresenta toda a memória consumida de forma exclusiva por uma sessão. A palavra “exclusiva” é chave no entendimento, porque isso significa que parte da memória não é considerada. Na realidade, a maior parte da memória é compartilhada. Por exemplo:

• Buffer Pool
• Procedure Cache
• Security Token Cache
• Pools de Memória
• Caches em geral

A forma correta é acompanhar o consumo de memória é utilizar os Memory Clerks.

select * FROM sys.dm_os_memory_clerks

Aqui descobrimos que o problema está relacionado com o MEMORYCLERK_SQLGENERAL (normalmente associado ao compilador).

No próximo post, vamos abordar o MemObj – esse é o subcomponente do Memory Clerk. Vamos concluir com 100% de certeza que o problema está relacionado com os documentos XML.