Início / dba / Perguntas / 113127
Accepted
msgisme
Asked: 2015-09-04 09:48:15 +0800 CST

Por que dm_os_memory_clerks tem valores MEMORYCLERK_SQLCLR em um nó NUMA?

  • 772

Estamos usando um procedimento armazenado SQLCLR para ativação do agente de serviços e desejo monitorar a memória usada pelo código CLR. Olhando para sys.dm_os_memory_clerks, vejo que apenas o nó NUMA 1 tem páginas associadas ao MEMORYCLERK_SQLCLRtipo. O servidor tem duas CPUs de 8 núcleos e está executando o SQL 2014 CU6.

Isso é esperado? Ou devo ver a memória usada em ambos os nós, como faço com MEMORYCLERK_SQLBUFFERPOOL?

Consulta:

SELECT DOMC.memory_node_id
    , DOMC.pages_kb
    , DOMC.virtual_memory_reserved_kb
    , DOMC.virtual_memory_committed_kb 
FROM sys.dm_os_memory_clerks DOMC where type = 'MEMORYCLERK_SQLCLR'

Resultados:

memory_node_id pages_kb             virtual_memory_reserved_kb virtual_memory_committed_kb
-------------- -------------------- -------------------------- ---------------------------
0              88232                12607744                   1408652
1              0                    0                          0
64             0                    0                          0
sql-server sql-server-2014

1 respostas

  1. Best Answer

    Infelizmente, não há muitas informações disponíveis sobre as especificidades do uso da memória SQLCLR. No entanto, achei os dois recursos a seguir úteis como ponto de partida:

    A partir deles e examinando vários DMVs e as páginas do MSDN explicando (bem, não é muito explicativo, mas tecnicamente é mais do que nada) como esses DMVs meio que funcionam, reuni as consultas mostradas abaixo. Ao executá-los em alguns sistemas diferentes, parece que a alocação de memória SQLCLR está concentrada em um memory_node_id, mas ainda há alguma alocação em outros nós, pelo menos em termos de Proc Cache. Portanto, por enquanto, a menos que alguém tenha evidências ou informações em contrário, o que você está vivenciando é "esperado".

    Esta consulta informa as informações básicas:

    SELECT domc.*
FROM   sys.dm_os_memory_clerks domc
WHERE  domc.[type] LIKE '%CLR%'
AND    domc.[memory_node_id] <> 64;

    Você notará que, ao não especificar um em particular [type], há mais alguns que podem ocupar um pouco da memória. Total de 4 tipos que eu vi são:

    • MEMORYCLERK_SQLCLR,
    • MEMORYCLERK_SQLCLRASSEMBLY
    • CACHESTORE_CLRPROC
    • CACHESTORE_CLRUDTINFO

    Se você está se perguntando por que estou filtrando [memory_node_id]64, execute isto:

    SELECT * FROM sys.dm_os_nodes;

    e você verá que node_id de 64 é DAC (Conexão Dedicada do Administrador).

    O seguinte lhe dará os totais para os dois campos importantes. Observe que os campos foram alterados no SQL Server 2012, então você precisa escolher aquele que é apropriado para a versão do SQL Server em que está sendo usado:

    -- SQL Server 2012, 2014, and 2016:
SELECT SUM(domc.pages_kb) AS [TotalPagesKb],
       SUM(domc.virtual_memory_committed_kb) AS [TotalVirtualMemoryKb]
FROM   sys.dm_os_memory_clerks domc
WHERE  domc.[type] LIKE '%CLR%'
AND    domc.[memory_node_id] <> 64;

-- SQL Server 2005, 2008, and 2008 R2:
SELECT SUM(domc.single_pages_kb + domc.multi_pages_kb) AS [TotalPagesKb],
       SUM(domc.virtual_memory_committed_kb) AS [TotalVirtualMemoryKb]
FROM   sys.dm_os_memory_clerks domc
WHERE  domc.[type] LIKE '%CLR%'
AND    domc.[memory_node_id] <> 64;

    A próxima consulta mostra a relação entre "memory_clerks" e "memory_objects":

    SELECT domc.*, N' █ ' AS [ █ ], domo.*
FROM   sys.dm_os_memory_clerks domc
LEFT JOIN sys.dm_os_memory_objects domo
        ON domo.page_allocator_address = domc.page_allocator_address
WHERE  domc.[type] LIKE N'%CLR%'
AND    domc.[memory_node_id] <> 64;

    As consultas a seguir são uma versão mais focada da primeira consulta (e mais parecida com a consulta na pergunta), mas os campos mudaram no SQL Server 2012, então você precisa escolher aquele que é apropriado para a versão do SQL Server que está sendo usado em:

    -- SQL Server 2012, 2014, and 2016:
SELECT domc.memory_node_id,
       domc.[type],
       domc.pages_kb,
       domc.virtual_memory_committed_kb
FROM   sys.dm_os_memory_clerks domc
WHERE  domc.[type] LIKE '%CLR%'
AND    domc.[memory_node_id] <> 64;

-- SQL Server 2005, 2008, and 2008 R2:
SELECT domc.memory_node_id,
       domc.[type],
       (domc.single_pages_kb + domc.multi_pages_kb) AS [pages_kb],
       domc.virtual_memory_committed_kb
FROM   sys.dm_os_memory_clerks domc
WHERE  domc.[type] LIKE '%CLR%'
AND    domc.[memory_node_id] <> 64;

    ATUALIZAR:

    Fiz alguns testes adicionais em um sistema de processador duplo criando 2 bancos de dados e, usando uma variável estática, carreguei 80 MB em cada um dos bancos de dados. Criei dois bancos de dados em vez de um para ver se um AppDomain tinha que ficar em um nó de memória, se poderia pelo menos colocar outro AppDomain em outro nó de memória para espalhar as coisas. Os resultados:

    • Todos os 160 MB em ambos os bancos de dados (e, portanto, em ambos os AppDomains) foram para o nó de memória 0
    • Todos os 160 MB foram para a memória virtual, não para a memória física. Foi apenas o [virtual_memory_committed_kb]campo em sys.dm_os_memory_clerksque aumentou. E a coluna "Tamanho do Commit" no "Gerenciador de Tarefas" também refletiu esse aumento.
    • 4

relate perguntas