none
SQL Server ultrapassando MAX Memory RRS feed

  • Pergunta

  • Bom dia pessoal.

    Hoje aconteceu algo estranho em um dos ambientes SQL Server que administro.

    A Versão do SQL Server é 2012 SP1.

    Tenho uma instancia configurada com o MAx Memory de 55 GB, hoje pelo gerenciador de tarefas esta instancia estava alertando o consumo de 155 GB de RAM.

    Consultando pela DMV sys.dm_os_performance_counters  tudo aparentava normal, porém na DMV sys.dm_os_process_memory apontava os 155 GB em uso, infelizmente fomos obrigados a reiniciar o serviço para liberar a memória, alguém ja passou por isso ? Saberia explicar da onde vem essa diferença ?

    Obrigado desde já.

    Reginaldo Silva

    segunda-feira, 30 de novembro de 2015 13:57

Respostas

  • Reginaldo,

    Veja o que o Books On-Line descreve sobre a sys.dm_os_process_memory:

    "A maioria das alocações de memória que são atribuídas ao espaço de processo do SQL Server são controladas através de interfaces que permitem o acompanhamento e contabilização dessas alocações. No entanto, as alocações de memória podem ser executadas no espaço de endereço de servidor de SQL que ignora as rotinas de gerenciamento de memória interna. Valores são obtidos por meio de chamadas para o sistema operacional base. Eles não são manipulados por métodos internos para SQL Server, exceto quando ele ajusta para alocações de página bloqueada ou grande."

    Na verdade acredito que este valor de memória que você esta obtendo provavelmente não são totalmente relacionandos ao SQL Server, mas sim chamadas e consumo de memória do próprio Windows.


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 8 de dezembro de 2015 12:32
    Moderador

Todas as Respostas

  • Boa Noite Reginaldo,

    O servidor é virtual? Você está utilizando AWE?


    Att, Bruno Silva.

    terça-feira, 1 de dezembro de 2015 01:08
  • Boa noite,

    Não é virtual, é um servidor físico, também não utilizo AWE.

    Obrigado pela resposta.

    Att

    Reginaldo Silva

    terça-feira, 1 de dezembro de 2015 20:07
  • Reginaldo,

    Muito fora do comum isso, pois normalmente o Gerenciador de Tarefas do Windows mostra o quanto o serviço do SQL Server esta consumindo de memória e não o quanto a instância e seus objetos estão consumindo.

    Você chegou a verificar quais querys estavam em uso?


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quarta-feira, 2 de dezembro de 2015 12:28
    Moderador
  • Bom dia Junior Galvão.

    Obrigado pela resposta.

    Na verdade no momento eu não cheguei analisar as querys, analisei apenas a DMV que mostra os contadores, pelos contadores do SQL Server apontava tudo normal,

    olhei nos contadores Total Server Memory, Database Cache Memory, Stolen Server Memory, Free Memory, Granted Workspace Memory, Maximum Workspace Memory, Memory Grants Outstanding, Memory Grants Pending, Lock Memory, Connection Memory, na DMV sys.dm_exec_query_memory_grants...

    Aparentava tudo normal nessa instancia, porém no Task Manager apontava que esta instancia estava utilizando 155 GB sendo que o MAX Memory é de 55GB... 

    Muito estranho mesmo, na hora eu pensei no Non-BufferPool, mas será que chegaria num valor deste tamanho ?

    Att

    Reginaldo Silva

    quinta-feira, 3 de dezembro de 2015 13:35
  • Reginaldo,

    Acredito que o SQL Server não iria fazer o Non-Buffer Pool com este tamanho.

    Realmente é estranho, acredito você poderia identificar inicialmente o quanto de memória cada banco de dados esta consumindo, veja o exemplo abaixo:

    -- Buffer Pool de Memória por banco de dados --
    DECLARE @total_buffer INT;
    
    SELECT @total_buffer = cntr_value
       FROM sys.dm_os_performance_counters 
       WHERE RTRIM([object_name]) LIKE '%Buffer Manager'
       AND counter_name = 'Total Pages';
    
    ;WITH src AS
    (
       SELECT 
           database_id, db_buffer_pages = COUNT_BIG(*)
           FROM sys.dm_os_buffer_descriptors
           --WHERE database_id BETWEEN 5 AND 32766
           GROUP BY database_id
    )
    SELECT
       [db_name] = CASE [database_id] WHEN 32767 
           THEN 'Resource DB' 
           ELSE DB_NAME([database_id]) END,
       db_buffer_pages,
       db_buffer_MB = db_buffer_pages / 128,
       db_buffer_percent = CONVERT(DECIMAL(6,3), 
           db_buffer_pages * 100.0 / @total_buffer)
    FROM src
    ORDER BY db_buffer_MB DESC;
    
    
    -- Buffer Pool de Memória Por Banco e Seus Objetos --
    USE SQLSentry;
    GO
    
    ;WITH src AS
    (
       SELECT
           [Object] = o.name,
           [Type] = o.type_desc,
           [Index] = COALESCE(i.name, ''),
           [Index_Type] = i.type_desc,
           p.[object_id],
           p.index_id,
           au.allocation_unit_id
       FROM
           sys.partitions AS p
       INNER JOIN
           sys.allocation_units AS au
           ON p.hobt_id = au.container_id
       INNER JOIN
           sys.objects AS o
           ON p.[object_id] = o.[object_id]
       INNER JOIN
           sys.indexes AS i
           ON o.[object_id] = i.[object_id]
           AND p.index_id = i.index_id
       WHERE
           au.[type] IN (1,2,3)
           AND o.is_ms_shipped = 0
    )
    SELECT
       src.[Object],
       src.[Type],
       src.[Index],
       src.Index_Type,
       buffer_pages = COUNT_BIG(b.page_id),
       buffer_mb = COUNT_BIG(b.page_id) / 128
    FROM
       src
    INNER JOIN
       sys.dm_os_buffer_descriptors AS b
       ON src.allocation_unit_id = b.allocation_unit_id
    WHERE
       b.database_id = DB_ID()
    GROUP BY
       src.[Object],
       src.[Type],
       src.[Index],
       src.Index_Type
    ORDER BY
       buffer_pages DESC;
    


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    sexta-feira, 4 de dezembro de 2015 14:27
    Moderador
  • Boa tarde Junior Galvao,

    No momento que ocorreu eu verifiquei todos os contadores de memoria, estavam todos OK, a quantidade de memoria em cache estava na quantia normal, o unico lugar que me mostrava algo diferente era na DMV dm_os_process_memory  lá mostrava os 155 GB em uso... cara realmente não faço ideia da onde veio... se acontecer de novo tentarei investigar mais, o problema é que o servidor ficou no gargalo com a memoria não tive escolha a não ser reinicia a instancia...

    Obrigado

    Reginaldo Silva.

    sexta-feira, 4 de dezembro de 2015 17:51
  • Reginaldo,

    Veja o que o Books On-Line descreve sobre a sys.dm_os_process_memory:

    "A maioria das alocações de memória que são atribuídas ao espaço de processo do SQL Server são controladas através de interfaces que permitem o acompanhamento e contabilização dessas alocações. No entanto, as alocações de memória podem ser executadas no espaço de endereço de servidor de SQL que ignora as rotinas de gerenciamento de memória interna. Valores são obtidos por meio de chamadas para o sistema operacional base. Eles não são manipulados por métodos internos para SQL Server, exceto quando ele ajusta para alocações de página bloqueada ou grande."

    Na verdade acredito que este valor de memória que você esta obtendo provavelmente não são totalmente relacionandos ao SQL Server, mas sim chamadas e consumo de memória do próprio Windows.


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 8 de dezembro de 2015 12:32
    Moderador
  • Bom dia.

    Legal, pode ser também né, bom se acontecer novamente tentarei ir mais a fundo, se eu descobrir alguma novidade posto pra vocês.

    Muito obrigado pelas respostas.

    Att

    Reginaldo Silva

    quarta-feira, 9 de dezembro de 2015 12:08