locked
Tunning de Server - Infra

    Frage

  • Amigos,

    Bom dia,

    Estamos implementando um cenário onde precisariamos de otimizar ao maximo a utilização de recursos em particular dos bancos de dados.

    Gostaria de saber se a comundiade pode me falar o que geralmente se aplicam nos cenarios para Tunning de ambiente utilizando aplicações comerciais por exemplo TOTVS RM,TOTVS RM.Em geral não conseguimos mexer muito na arquitetura dos BANCOS.A idéia é otimizar ao maximo na Infraestrutura dos servidores de BD.

    Podem me dar uma luz ?

    Existem magicas a serem feitas no MSSQL como ocorre com outros bancos de dados (Exemplo Progress) onde eu carrego todos os bancos para a memória, diminuindo o acesso a disco e coisas parecidas ?

    Gostaria de propostas de configurações que possam ser imediatamente aplicados numa nova infraestrutura.Ainda está em design.Os servidores de uma forma geral possuem um bom dimensionamento quanto a processadores e memória.

    Para discos será utilizada uma SAN sobre ISCSI.Cada servidor também possuirá alguns dicscos locais para demandas específicas (Exatamente 6 Discos SAS 300).

    Obrigado,

    Thiago.


    Analista de Sistemas e Tecnologia.

    Donnerstag, 19. April 2012 12:13

Antworten

  • Fala Thiago, boa tarde.

    Indo no mesmo sentido que os colegas Gustavo e Galvão, mas com uma dica que julgo ser importante. Construa um baseline e aprenda quais alterações trazem um benefício real no seu ambiente. A ferramenta que costumo utilizar é o Perfmon, onde você pode adicionar contadores para tudo o que você precisa saber e monitorar. Navegue entre os contadores do SQL Server e veja quanta informação você pode obter.

    Suponhamos que você já esteja monitorando tudo, e percebe que a quantidade de IOPS está elevada. A partir daí você olha a fila de disco pra ver se está dando conta ou se realmente está impactando. Percebe que há uma pequena fila mas caso a demanda aumente ou um job de backup inicie poderá ter problemas. Comparando a quantidade de transações por segundo com a quantidade de transações por segundo executadas em TempDB, você percebe que cerca de 30% ficam na TempDB. Aí você já pode pensar em colocar a TempDB no seu disco local, por exemplo.

    Daqui 2 anos você poderá olhar pra trás e ver quanto a demanda por recursos aumentou, sendo capaz até de estipular um crescimento pros próximos 2 anos.

    O recado aqui é que, através de um baseline de monitoramento, você será capaz de conhecer seu ambiente a ponto de dimensionar corretamente os ganhos e entender, por exemplo, se colocar os arquivos de TLog em volumes separados vão te ajudar ou não. É uma boa prática colocá-los separados dos arquivos da base pois um faz escrita sequencial e o outro leitura randômica mas num ambiente onde a base está alocada inteira na memória e não há esperas para escrever, não tenho justificativa pra mexer nisso mesmo sendo uma boa prática.

    Sugiro que você leia sobre os contadores do SQL Server para construir um baseline bem completo e assim consiga identificar onde seu ambiente pode ser melhorado.

    Abraços!




    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br


    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    Dienstag, 18. Juni 2013 17:03
  • Bom Dia,

    Interessante algumas dessas colocações.

    "Em geral não conseguimos mexer muito na arquitetura dos BANCOS".
    Me atrevo a dizer (sem citar nomes ou direcionar fornecedores, pois, existem exceções), que a grande maioria desses ERP é muito mal feita. Do ponto de vista de negócio, eles são sim capazes de entregar muita funcionalidade, mas do ponto de vista de banco de dados, são mal feitos, mal modelados e não fazem uso de diversas features disponíveis no banco. Não vou discorrer sobre o porquê que isso acontece (estaríamos desfocando). A partir do momento em que o banco é fechado, você tentará resolver com infraestrutura os problemas de desenvolvimento e embora possível confesso que nem sempre é uma estratégia eficaz ou barata. Claro que pelo fato do código ser fechado, não há muito o que fazer, mas não espere achar a configuração de parâmetros específicos de infraestrutura para milagrosamente fazer com que os problemas de desenvolvimentos sumam. Eles no máximo serão atenuados.

    Existem magicas a serem feitas no MSSQL como ocorre com outros bancos de dados (Exemplo Progress) onde eu carrego todos os bancos para a memória, diminuindo o acesso a disco e coisas parecidas ?
    Essa é uma colocação muito interessante. Os bancos de dados não possuem "mágica". Se houvesse uma opção "mágica" que tudo funcionasse melhor, essa opção "mágica" seria habilitada por padrão, ou seja, todo o produto já viria "enfeitiçado" para funcionar da forma mais rápida possível. Todos os bancos carregam os dados na memória e tentam manter na memória para evitar o acesso ao disco. Entretanto alguns deles permitem que "a contragosto do gerenciador", o DBA possa manter as tabelas em memória. É uma feature que existia no SQL Server, mas ao longo do tempo foi retirada, pois, entende-se que ela trás mais problemas que soluções efetivamente. Embora alguns bancos a tenham, não costumo ver esse recurso utilizado.

    Sem conhecer a estrutura do que será implementado, é muito difícil saber exatamente que configurações sugerir para o banco de dados. O que eu sugiro é que você cobre do seu fornecedor uma especificação mínima de hardware para que o software funcione corretamente. Isso lhe dará um respaldo, pois, em tese quem melhor conhece o software é o fornecedor.

    Podemos aguardar também a experiência de outras pessoas que tenham o software que você citou, pois, nada melhor do que a opinião de quem já passou por esses problemas. Ainda assim, adianto que não existe configuração mágica para que o SQL Server fique melhor para qualquer software. Seria bom cobrar também do fornecedor se há alguma configuração específica indicada para que o software funcione melhor.

    Do contrário ficaremos na indicações genéricas (tempdb em disco separado, filegroup pra índices, particionamento, etc) e que nem sempre melhoram o desempenho.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    Donnerstag, 19. April 2012 15:24

Alle Antworten

  • Bom dia amigo, perdon de meu portugues no é muito bom, Trabalho para uma empresa financiera da Europa.

    Nos temos todos os Server em Cluster, os Windows 64bits e os SQL Server Enterprise Edition 64 bits. Depois no Storage a gente tem 2 discos para tempdb, um disco para Transacction Log, 4 discos para Data File depende a estructura dos bancos do dados e umo disco para Backups. Em memoria temos 64 GB com 62 GB didicados a SQL Server e 2 GB para o SO.

    Cualquier duvida envia para mi um mail

    nano0511@hotmail.com


    Carlos Ignacio Aguero. DBA SQL Server. Toda mi respeto al pueblo Peruano por la ayuda prestada en la guerra de Malvinas.

    Donnerstag, 19. April 2012 14:53
  • Bom Dia,

    Interessante algumas dessas colocações.

    "Em geral não conseguimos mexer muito na arquitetura dos BANCOS".
    Me atrevo a dizer (sem citar nomes ou direcionar fornecedores, pois, existem exceções), que a grande maioria desses ERP é muito mal feita. Do ponto de vista de negócio, eles são sim capazes de entregar muita funcionalidade, mas do ponto de vista de banco de dados, são mal feitos, mal modelados e não fazem uso de diversas features disponíveis no banco. Não vou discorrer sobre o porquê que isso acontece (estaríamos desfocando). A partir do momento em que o banco é fechado, você tentará resolver com infraestrutura os problemas de desenvolvimento e embora possível confesso que nem sempre é uma estratégia eficaz ou barata. Claro que pelo fato do código ser fechado, não há muito o que fazer, mas não espere achar a configuração de parâmetros específicos de infraestrutura para milagrosamente fazer com que os problemas de desenvolvimentos sumam. Eles no máximo serão atenuados.

    Existem magicas a serem feitas no MSSQL como ocorre com outros bancos de dados (Exemplo Progress) onde eu carrego todos os bancos para a memória, diminuindo o acesso a disco e coisas parecidas ?
    Essa é uma colocação muito interessante. Os bancos de dados não possuem "mágica". Se houvesse uma opção "mágica" que tudo funcionasse melhor, essa opção "mágica" seria habilitada por padrão, ou seja, todo o produto já viria "enfeitiçado" para funcionar da forma mais rápida possível. Todos os bancos carregam os dados na memória e tentam manter na memória para evitar o acesso ao disco. Entretanto alguns deles permitem que "a contragosto do gerenciador", o DBA possa manter as tabelas em memória. É uma feature que existia no SQL Server, mas ao longo do tempo foi retirada, pois, entende-se que ela trás mais problemas que soluções efetivamente. Embora alguns bancos a tenham, não costumo ver esse recurso utilizado.

    Sem conhecer a estrutura do que será implementado, é muito difícil saber exatamente que configurações sugerir para o banco de dados. O que eu sugiro é que você cobre do seu fornecedor uma especificação mínima de hardware para que o software funcione corretamente. Isso lhe dará um respaldo, pois, em tese quem melhor conhece o software é o fornecedor.

    Podemos aguardar também a experiência de outras pessoas que tenham o software que você citou, pois, nada melhor do que a opinião de quem já passou por esses problemas. Ainda assim, adianto que não existe configuração mágica para que o SQL Server fique melhor para qualquer software. Seria bom cobrar também do fornecedor se há alguma configuração específica indicada para que o software funcione melhor.

    Do contrário ficaremos na indicações genéricas (tempdb em disco separado, filegroup pra índices, particionamento, etc) e que nem sempre melhoram o desempenho.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    Donnerstag, 19. April 2012 15:24
  • Obrigado Gustavo pelo tempo de dicado,

    Quanto a primeira resposta tenho a mesma opinião que vc, apesar de não ser expert em desenvolvimento, já ví coisas feitas por fornecedor X de sistemas de gestão onde ao invés de corrigir o produto, gambiarram para o cliente, coisas do tipo IF CNPJ=XXXXXXXXXX Then... mas vamos lá não é o foco.Realmente temos que tentar trabalhar na Infraestrutura.O objetivo e a coleta de informações justamente para a atenuação dos problemas referentes a solução.

    A magica é justamente, quais as melhores práticas adotadas pelos DBAs para otimizar essa infra.Por exemplo em bancos Progress, posso mexer no tamanho do Block Size, Buffer Transacional e de Gravação em disco, Ajustes de Shared Memory e por ai vai...quais as praticas possíveis e aplicaveis na busca pelo mundo perfeito...na busca... documentação tem muita coisa, ok mas do que ela tem alí realmente é pratico, conhecido e validado pela comunidade ?

    Att,


    Thiago.


    Analista de Sistemas e Tecnologia.

    Donnerstag, 19. April 2012 18:45
  • Thiago,

    Cara sinceramente neste 16 anos de TI, posso dizer que não existe mundo perfeito, existem necessidades cenários, necessidades e muita mas muitas discussões e considerações que devemos analisar.

    Isso vai desde o Hardware, Software, Camadas de Acesso e muitas outras coisas.

    Sendo assim, eu normalmente costumo dizer que não existe mágica ou magia, existe as adaptações e detalhes técnicos que devemos procurar encontrar.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    Freitag, 20. April 2012 16:59
  • Fala Thiago, boa tarde.

    Indo no mesmo sentido que os colegas Gustavo e Galvão, mas com uma dica que julgo ser importante. Construa um baseline e aprenda quais alterações trazem um benefício real no seu ambiente. A ferramenta que costumo utilizar é o Perfmon, onde você pode adicionar contadores para tudo o que você precisa saber e monitorar. Navegue entre os contadores do SQL Server e veja quanta informação você pode obter.

    Suponhamos que você já esteja monitorando tudo, e percebe que a quantidade de IOPS está elevada. A partir daí você olha a fila de disco pra ver se está dando conta ou se realmente está impactando. Percebe que há uma pequena fila mas caso a demanda aumente ou um job de backup inicie poderá ter problemas. Comparando a quantidade de transações por segundo com a quantidade de transações por segundo executadas em TempDB, você percebe que cerca de 30% ficam na TempDB. Aí você já pode pensar em colocar a TempDB no seu disco local, por exemplo.

    Daqui 2 anos você poderá olhar pra trás e ver quanto a demanda por recursos aumentou, sendo capaz até de estipular um crescimento pros próximos 2 anos.

    O recado aqui é que, através de um baseline de monitoramento, você será capaz de conhecer seu ambiente a ponto de dimensionar corretamente os ganhos e entender, por exemplo, se colocar os arquivos de TLog em volumes separados vão te ajudar ou não. É uma boa prática colocá-los separados dos arquivos da base pois um faz escrita sequencial e o outro leitura randômica mas num ambiente onde a base está alocada inteira na memória e não há esperas para escrever, não tenho justificativa pra mexer nisso mesmo sendo uma boa prática.

    Sugiro que você leia sobre os contadores do SQL Server para construir um baseline bem completo e assim consiga identificar onde seu ambiente pode ser melhorado.

    Abraços!




    Luiz Mercante
    MCITP SQL 2008 | MCTS SQL 2008 | MCTS Windows Apps | MCTS Windows Network | MCP 2003
    sqldicas@outlook.com
    http://sqldicas.com.br


    Se a resposta foi útil de alguma forma, classifique como resposta ou vote como útil.

    Dienstag, 18. Juni 2013 17:03