none
SQLServer usando memória RRS feed

  • Dotaz

  • Prezados,

    Tenho o SQLServer 2016 Standart instalado em meu Windows Server 2016 Standart e estou observando que o SQLServer esta consumindo memória em alguns recursos. 

    Temos planos de manutenção de integridade e backup que rodam diariamente, e observamos que a cada execução do plano, 1GB é adicionado ao uso de memória.

    Estou gerando a consulta abaixo:

    with cteSizeDB as ( 

       SELECT 'DB:'+DB_NAME(database_id) AS cDBName , 

              cast(COUNT(*) * 8 / 1024.0 as decimal(7,2)) as nSizeInMemoryMB 

         FROM sys.dm_os_buffer_descriptors 

        GROUP BY DB_NAME(database_id) 

        union all 

        select 'Mem:'+type , sum(pages_kb)/1024  

          from sys.dm_os_memory_clerks 

      where type <> 'MEMORYCLERK_SQLBUFFERPOOL' 

              group by type 

    )select * 

       from cteSizeDB 

       where nSizeInMemoryMB > 0 

      union 

     select 'Todos' , SUM(nSizeInMemoryMB) 

       from cteSizeDB 

       order by 2 desc;  

    E obtendo o seguinte resultado:

    cDBName nSizeInMemoryMB
    Todos 12164.44
    Mem:CACHESTORE_SQLCP 4237.00
    DB:Protheus_Prd 4117.71
    DB:CorporeRM 1041.43
    Mem:USERSTORE_DBMETADATA 382.00
    DB:Protheus_teste 317.05
    DB:RM_TSS 312.47
    DB:CORPORERM_AMBAR 267.09
    Mem:CACHESTORE_OBJCP 261.00
    Mem:CACHESTORE_PHDR 185.00
    Mem:USERSTORE_SCHEMAMGR 151.00
    DB:Protheus_Homologa 119.63
    DB:tempdb 88.09
    Mem:MEMORYCLERK_SQLSTORENG 88.00
    DB:Protheus_TSS 86.76
    DB:RM_TAF 80.34
    Mem:MEMORYCLERK_SOSNODE 72.00
    DB:RM_TAFREINF 46.36
    DB:CorporeRM_Teste 37.80
    Mem:USERSTORE_TOKENPERM 34.00
    DB:CORPORERM_AMBAR_TESTE 32.24
    Mem:MEMORYCLERK_SQLQUERYEXEC 32.00
    Mem:USERSTORE_OBJPERM 22.00
    NULL 20.33
    Mem:CACHESTORE_SYSTEMROWSET 17.00
    Mem:MEMORYCLERK_SQLCLR 16.00
    Mem:MEMORYCLERK_SQLTRACE 16.00
    Mem:OBJECTSTORE_LOCK_MANAGER 16.00
    DB:msdb 10.56
    Mem:MEMORYCLERK_SQLQERESERVATIONS 10.00
    Mem:OBJECTSTORE_SNI_PACKET 9.00
    Mem:MEMORYCLERK_SQLCONNECTIONPOOL 6.00
    Mem:MEMORYCLERK_SQLGENERAL 6.00
    Mem:MEMORYCLERK_SQLLOGPOOL 6.00
    DB:fluig 5.16
    Mem:CACHESTORE_SEHOBTCOLUMNATTRIBUTE 5.00
    DB:ReportServer$COTESA 2.01
    Mem:MEMORYCLERK_SQLOPTIMIZER 2.00
    Mem:MEMORYCLERK_XE 2.00
    DB:master 1.86
    DB:ReportServer$COTESATempDB 1.23
    Mem:USERSTORE_SXC 1.00
    DB:model 0.32

    Porque o uso excessivo em "Mem"?

    Existe alguma forma de não deixar utilizar a memória para "Mem"? 

    Existe alguma forma de diariamente reduzir o uso em "Mem"?

    čtvrtek 28. února 2019 19:48

Všechny reakce

  • Boa tarde. O que vc pode fazer é limitar a memória do sql.

    https://tadeuesteves.wordpress.com/2015/02/20/limitar-uso-de-memoria-do-sql-server-sqlservr-exe/


    Se útil, por favor Classifique João C.X.Macedo Specialist Platforms Microsoft MCP,MCT,MCSA,MCTS,MCITP, ENTERPRISE VIRTUALIZATION WINDOWS SERVER 2008 R2,MCSE WINDOWS SERVER 2012,MCSA WINDOWS SERVER 2016

    • Navržen jako odpověď José Diz neděle 3. března 2019 8:38
    čtvrtek 28. února 2019 20:55
  • Bom dia Lucas,

    Complementando a resposta do João, é uma boa prática sim limitar o uso de memória do SQL Server porque como eu costumo brincar, ele é um papa memória dos bons.

    Como acesso a dados na memória é muito mais rápido do que no disco, o SQL Server sempre vai ocupar memória a medida que suas consulta forem sendo executadas e isso é muito bom, já que permite o reaproveitamento na leitura desses dados sem acessar o disco (que é lento) novamente.

    Então limite a memória do SQL Server de acordo com a memória disponível na sua máquina e deixe o SQL Server pegar o resto e ser feliz.

    Ele sempre vai pegar toda a memória que você der pra ele e isso não é um problema. O problema é se essa quantidade de memória disponível pra ele for menor do que ele precisa. Aí sim teremos lentidão no sistema por conta de pressão/mau uso da memória.

    Espero ter ajudado!


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    • Navržen jako odpověď José Diz neděle 3. března 2019 8:38
    pátek 1. března 2019 12:16