none
Com que frequência se deve reiniciar um servidor. RRS feed

  • Pergunta

  • Srs., boa tarde!

    Na empresa em que trabalho temos dois servidores, um é o servidor de DB (SqlServer 2008) e o outro é um servidor de aplicações. Sou desenvolvedor e não trabalho diretamente na infraestrutura, mesmo assim estou constantemente acessando-os. A questão é que a intervalos irregulares, digamos, a cada 25, 30 dias começam a ocorrer erros de toda espécie e que parecem "sumir" após um reboot.

    Hoje ocorreu, só para se ter ideia, o SqlServer estava ocupando 30GB de ram. Após o reboot há quase 3 horas atrás ele está com 12,5GB em uso. Tive a impressão que parte desta memória era "sujeira"...

    Minha pergunta é: Há uma frequência que devemos nos basear para reiniciar um server? 

    Me perdoem se estiver falando bobagens, porém realmente não sou da área de infra, sou desenvolvedor e curioso...

    Att,

    segunda-feira, 24 de setembro de 2012 17:22

Respostas

  • Meu caro, não há nada de errado com sua pergunta, e realmente ela é feita por grande parte dos profissionais, e até mesmo os de Infra!

    Mas como todos os outros colegas citaram, não há um parecer de ultimato para este evento, pois cada ambiente é individual.

    Servidores físicos são máquinas altamente complexas, com hardwares desenhados para suportar cargas elevados e períodos altos de atividade, então ao meu ver nem deveriam ser desligados. Já vivenciei inúmeras experiências em grandes DataCenters de antigos servidores que eram desligados, e nunca mais voltavam a funcionar...

    Mas já existe um ponto dos servidores virtuais, que não requerem o mesmo nível de atenção ao hardware, visto que podem ser migrados ao vivo, sem serem desligados, para outro hardware de destino. Então, qual o ponto crítico deste?

    Entendo que o Sistema Operacional também tem sua limitações e dependências, mas que os SO's preparados para suportar alto desempenho e trabalhar em largas escalas, como DataCenters, também foram desenhados para fluxo contínuo de dados, exceto quando as próprias atualizações de segurança ou as Mudanças de ambiente o obrigarem a isso.

    Mas como todos já disseram, isso vai variar e depender de cada ambiente!

    E de cada aplicação! E no seu caso, o SQL Server pode estar preservando ativas conexões à database por mais tempo do que necessário. Verifique como isso funciona, e alinhe com a Infra de sua empresa. Grupos de DEV e de Infra tem que estar sempre alinhados, pra agregar ainda mais valor ao negócio, e se fortalecerem como equipe de TI!

    Abços,

    sábado, 22 de dezembro de 2012 17:33
  • Eu acho engraçado aquele povo que se vangloria dizendo "Meu serivdor nao é desligado a mais de 6 meses"... Ou seja, o servidor é um poço de falhas de segurança e está com certeza vulnerável.

    Resumindo. Minha recomendação é reiniciar no mínimo quando houver atualizações críticas de segurança. Se a empresa disser que uma parada dessas é inviável para o serviço, começe a planejar uma redundancia para isso.


    Essa opnião acima do nosso amigo Allan resume tudo. Na minha empresa reinicio os servidores da seguinte maneira (sem contar de quanto em quanto tempo): as atualizações são feitas de forma assistida (WSUS) e quando temos algo crítico fazemos a atualização e reiniciamos sim o servidor, isso não nos impacta em nada. Outra coisa, a criação de um plano de redundância é muito importante mesmo.
    • Marcado como Resposta Richard Juhasz quarta-feira, 27 de fevereiro de 2013 14:36
    sábado, 12 de janeiro de 2013 11:40
  • Acredito que as respostas dadas até o momento são bastante corretas (reiniciar o mínimo possível, fazer tuning do banco de dados, etc).

    Todo bom investigador deve começar olhando para os sintomas e tentar descobrir a causa. Reiniciar o servidor em um caso de erro deve ser evitado pois apaga grande parte da evidência que seria útil para resolver o problema definitivamente.

    Se a situação da empresa permitir, é melhor ficar com o problema momentaneamente enquanto evidências suficientes são coletadas (não só consumo de memória mas mensagens de erro, registros do event viewer, etc). Mesmo que seja necessário reiniciá-lo como última saída (já sabendo que resolve, mas não definitivamente) pelo menos você terá mais informações para investigar o problema melhor e definir uma solução final.

    Acho que essa época de reiniciar servidores periodicamente sem nenhum motivo ("só para evitar um problema futuro") já faz parte do passado remoto da maioria dos sistemas operacionais (e DBs).


    • Editado gtirloni domingo, 13 de janeiro de 2013 21:18
    • Marcado como Resposta Richard Juhasz quarta-feira, 27 de fevereiro de 2013 14:36
    domingo, 13 de janeiro de 2013 21:17

Todas as Respostas

  • Olá Bosscoder.
    É muito relativo essa questão, mas no geral o servidor não deve ser desligado, salvo algumas situações.
    mas já trabalhei em empresas sem missão crítica em que se desligava todo final de semana, mas pra levantar o monstro...que demora.
    Sobre a questão do SQL Server, ele é um bom comedor de memória.

    Veja se esse artigo pode te ajudar a fazer uns ajustes no seu BD: http://fabrizziocaputo.wordpress.com/2011/11/07/por-que-a-memoria-utilizada-pelo-sql-server-nao-diminui-por-que-a-memoria-do-sql-server-so-diminui-quando-eu-reinicio-o-servidor/

    Espero ter ajudado.

    []s


    Twitter: @caiado

    • Sugerido como Resposta M Thiago terça-feira, 25 de setembro de 2012 14:20
    • Não Sugerido como Resposta M Thiago terça-feira, 25 de setembro de 2012 14:20
    • Sugerido como Resposta Sandro Caiado quinta-feira, 11 de outubro de 2012 11:07
    segunda-feira, 24 de setembro de 2012 19:56
  • Boa tarde, Sandro!

    Ajudou sim.

    Assim que chegar em casa lerei o artigo.

    Att,

    Ramires.

    segunda-feira, 24 de setembro de 2012 20:24
  • Olá.

    Prezado o seu problema do SQL pode ser resolvido com um Tunning no seu SQL. Ele pode ser configurado para otimizar o uso de memória e evitar esses "lixos".


    erick Maquine

    terça-feira, 2 de outubro de 2012 17:55
  • Conforme mencionado anteriormente, cada caso é um caso.

    No meu ponto de vista as aplicações devem ser bem otimizadas e configuradas para nao sausarem nenhum tipo de indisponibilidade do serviço. O que no caso do SQL as vezes é bem complicado. Veja que nem sempre o problema pode estar no SQL e sim nas aplicações que acessam o banco. Como várias aplicações que após consultarem ou atualizarem o banco não encerram suas sessões, deixando milhares de conexões abertas.

    Voltando aos servidores, eles realmente são feitos para reiniciar o mínimo possível e garantir a alta disponibilidade. Mas em alguns casos isso é inevitável. Tudo depende do perfil de sua empresa, o que ela espera da disponibilidade dos dados? E a segurança?

    Eu acho engraçado aquele povo que se vangloria dizendo "Meu serivdor nao é desligado a mais de 6 meses"... Ou seja, o servidor é um poço de falhas de segurança e está com certeza vulnerável.

    Resumindo. Minha recomendação é reiniciar no mínimo quando houver atualizações críticas de segurança. Se a empresa disser que uma parada dessas é inviável para o serviço, começe a planejar uma redundancia para isso.

    terça-feira, 16 de outubro de 2012 19:12
  • Allan, concordo plenamente com seu post. No entanto, só gostaria de acrescentar que os recursos do servidor (quantidade de memória física principalmente) devem estar adequados às necessidades das funções dos servidores, para minimizar o gerenciamento do SWAP, maximizando o uptime.

    []´s

    Alexandre Biscaio

    quinta-feira, 8 de novembro de 2012 15:57
  • Srs, Boa noite!

    Muito boa a explicação do colega Alexandre Biscaio. Cada caso deve ser analisado conforme a infraestrutura e demanda no servidor. Você precisa ficar de olho nesse seu BD, muitas das vezes boa parte do consumo de RAM do SQL Server é lixo ou um servidor mal configurado, seu servidor de BD pode estar precisando de uma verificação para enxugar e retirar esses lixos que consomem memória. O ideal é consultar um DBA e realizar um Tunning no seu Banco. Outra coisa, um banco de dados mal projetado pode trazer sérios risco de performance e desempenho para seu servidor, mais como eu disse cada empresa tem seu caso particular de acordo com a demanda, infraestrutura e a carga de trabalho aplicado ao servidor, o ideal é você consultar um especialista em BD que analisará o BD de sua empresa e realizará tarefas de otimização e desempenho.

    Bem, qualquer dúvida estamos ae.

    Saúde e Paz!

    --

    Rodolfo Póvoa leal


    terça-feira, 27 de novembro de 2012 20:21
  • Meu caro, não há nada de errado com sua pergunta, e realmente ela é feita por grande parte dos profissionais, e até mesmo os de Infra!

    Mas como todos os outros colegas citaram, não há um parecer de ultimato para este evento, pois cada ambiente é individual.

    Servidores físicos são máquinas altamente complexas, com hardwares desenhados para suportar cargas elevados e períodos altos de atividade, então ao meu ver nem deveriam ser desligados. Já vivenciei inúmeras experiências em grandes DataCenters de antigos servidores que eram desligados, e nunca mais voltavam a funcionar...

    Mas já existe um ponto dos servidores virtuais, que não requerem o mesmo nível de atenção ao hardware, visto que podem ser migrados ao vivo, sem serem desligados, para outro hardware de destino. Então, qual o ponto crítico deste?

    Entendo que o Sistema Operacional também tem sua limitações e dependências, mas que os SO's preparados para suportar alto desempenho e trabalhar em largas escalas, como DataCenters, também foram desenhados para fluxo contínuo de dados, exceto quando as próprias atualizações de segurança ou as Mudanças de ambiente o obrigarem a isso.

    Mas como todos já disseram, isso vai variar e depender de cada ambiente!

    E de cada aplicação! E no seu caso, o SQL Server pode estar preservando ativas conexões à database por mais tempo do que necessário. Verifique como isso funciona, e alinhe com a Infra de sua empresa. Grupos de DEV e de Infra tem que estar sempre alinhados, pra agregar ainda mais valor ao negócio, e se fortalecerem como equipe de TI!

    Abços,

    sábado, 22 de dezembro de 2012 17:33
  • Eu acho engraçado aquele povo que se vangloria dizendo "Meu serivdor nao é desligado a mais de 6 meses"... Ou seja, o servidor é um poço de falhas de segurança e está com certeza vulnerável.

    Resumindo. Minha recomendação é reiniciar no mínimo quando houver atualizações críticas de segurança. Se a empresa disser que uma parada dessas é inviável para o serviço, começe a planejar uma redundancia para isso.


    Essa opnião acima do nosso amigo Allan resume tudo. Na minha empresa reinicio os servidores da seguinte maneira (sem contar de quanto em quanto tempo): as atualizações são feitas de forma assistida (WSUS) e quando temos algo crítico fazemos a atualização e reiniciamos sim o servidor, isso não nos impacta em nada. Outra coisa, a criação de um plano de redundância é muito importante mesmo.
    • Marcado como Resposta Richard Juhasz quarta-feira, 27 de fevereiro de 2013 14:36
    sábado, 12 de janeiro de 2013 11:40
  • Acredito que as respostas dadas até o momento são bastante corretas (reiniciar o mínimo possível, fazer tuning do banco de dados, etc).

    Todo bom investigador deve começar olhando para os sintomas e tentar descobrir a causa. Reiniciar o servidor em um caso de erro deve ser evitado pois apaga grande parte da evidência que seria útil para resolver o problema definitivamente.

    Se a situação da empresa permitir, é melhor ficar com o problema momentaneamente enquanto evidências suficientes são coletadas (não só consumo de memória mas mensagens de erro, registros do event viewer, etc). Mesmo que seja necessário reiniciá-lo como última saída (já sabendo que resolve, mas não definitivamente) pelo menos você terá mais informações para investigar o problema melhor e definir uma solução final.

    Acho que essa época de reiniciar servidores periodicamente sem nenhum motivo ("só para evitar um problema futuro") já faz parte do passado remoto da maioria dos sistemas operacionais (e DBs).


    • Editado gtirloni domingo, 13 de janeiro de 2013 21:18
    • Marcado como Resposta Richard Juhasz quarta-feira, 27 de fevereiro de 2013 14:36
    domingo, 13 de janeiro de 2013 21:17