none
Memória em excesso prejudica performance do SQL Server 2008 R2? RRS feed

  • Pergunta

  • Tenho um cliente que tem um base de dados de 300 GB e tem em média, nos horários de pico, 200 batch request por segundo. A máquina, DELL, tem um processador com 16 core XEON, array de discos com 15 RPM e 64 GB de memória. Sempre tivemos uma boa performance, sem problemas de processos sendo read locks, crônicos. Mas o cliente contratou um DBA e este disse ao cliente que poderia diminuir a memória, pois o SQL Server, com muita memória perde performance. Segundo palavras dele "fica bobo". Então diminuíram a memória do servidor para 38 GB. Logo em seguida começaram os problemas de processos sendo read locks,  como por exemplo, algumas procedures que realmente estavam utilizando muito IO. Claro que tivemos de refazer a procedure com as boas práticas de desenvolvimento de queries para diminuir o IO. Tem resolvido, mas tem sido de uma forma muito dolorosa, pois, volta e meia, o cliente fica parado por causa de processos sendo read locks. Então, é verdade o que este DBA afirmou, ou ele poderia ter achado as procedures com problemas sem ter de diminuir a memória? O cliente pediu para diminuir a memória, pois queria utilizar a máquina para criar outra virual.
    quarta-feira, 1 de novembro de 2017 14:26

Respostas

  • Jorge,

    Em todo o tempo que trabalho com SQL Server nunca ouvi falar e nem presenciei tal situação.
    O acesso a dados na memória é muito mais rápido que em disco, então não consigo pensar em uma situação onde "muita memória prejudica o desempenho do SQL Server".
    Tenho um ambiente com 2 TB de memória e não tive problemas com o SQL ficando "bobo".

    Sobre a pergunta: é fato que é possível achar as procedures e consultas que mais consomem com ou sem muita memória. Ofensor é ofensor. Monitorando da maneira correta é possível achar e alterar essas queries assim como você disse que vem fazendo.
    Apesar de ser um processo "doloroso" como disse, é necessário. Eu, particularmente, discordo que pra  cobrir queries ruins devemos aumentar hardware (tem gente que simplesmente manda aumentar máquina para sanar problemas de desempenho).

    Se o cliente precisa mesmo limitar a 38 GB, o único caminho é alterar as queries que mais consomem recursos.


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

    quarta-feira, 1 de novembro de 2017 15:26
  • Jorge,

    Melhoria de código deve ser uma constante. Costumo dizer que tuning é algo que nunca acaba. Você faz hoje, estabiliza, fica tudo lindo!
    Amanhã o perfil de utilização do seu usuário muda, ele começa a usar novas rotinas, novos filtros nos relatórios.. novas rotinas são implementadas e pronto! Tuning novamente.

    Então eu faria uma baseline desse ambiente com os 64 GB e com os 38GB. Depois alteraria as consultas e mediria novamente o ambiente.

    Talvez você consiga viver tranquilamente com os 38GB.


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

    quarta-feira, 1 de novembro de 2017 20:40

Todas as Respostas

  • Jorge,

    Em todo o tempo que trabalho com SQL Server nunca ouvi falar e nem presenciei tal situação.
    O acesso a dados na memória é muito mais rápido que em disco, então não consigo pensar em uma situação onde "muita memória prejudica o desempenho do SQL Server".
    Tenho um ambiente com 2 TB de memória e não tive problemas com o SQL ficando "bobo".

    Sobre a pergunta: é fato que é possível achar as procedures e consultas que mais consomem com ou sem muita memória. Ofensor é ofensor. Monitorando da maneira correta é possível achar e alterar essas queries assim como você disse que vem fazendo.
    Apesar de ser um processo "doloroso" como disse, é necessário. Eu, particularmente, discordo que pra  cobrir queries ruins devemos aumentar hardware (tem gente que simplesmente manda aumentar máquina para sanar problemas de desempenho).

    Se o cliente precisa mesmo limitar a 38 GB, o único caminho é alterar as queries que mais consomem recursos.


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

    quarta-feira, 1 de novembro de 2017 15:26
  • Muito obrigado, Mariana!

    Concordo, mas vc não acha que antes de diminuir a memória deveríamos ver, primeiro, quais as procedures que mais consomem IO? Concerta-las e ai sim diminuir a memória? Desde já, obrigado.

    quarta-feira, 1 de novembro de 2017 17:05
  • Jorge,

    Melhoria de código deve ser uma constante. Costumo dizer que tuning é algo que nunca acaba. Você faz hoje, estabiliza, fica tudo lindo!
    Amanhã o perfil de utilização do seu usuário muda, ele começa a usar novas rotinas, novos filtros nos relatórios.. novas rotinas são implementadas e pronto! Tuning novamente.

    Então eu faria uma baseline desse ambiente com os 64 GB e com os 38GB. Depois alteraria as consultas e mediria novamente o ambiente.

    Talvez você consiga viver tranquilamente com os 38GB.


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

    quarta-feira, 1 de novembro de 2017 20:40