Servidor Ubuntu falhando diariamente [fechado]

Question

Sintomas:

• O servidor não responde - Aumento de carga, todos os serviços são interrompidos
• Perda de conectividade - Ping / SSH
• Enxague os hosts do MySQL após a reinicialização - Como o MySQL recusa novas conexões
• Apache intermitente falha
• Geralmente acontece nas primeiras horas da manhã - no entanto, 2 dias da semana são excluídos

Alterações feitas:

• Atualizado o sistema operacional - para o Ubuntu 10.04.4 LTS
• Não tenho certeza se o servidor MySQL também foi atualizado no processo
• Versão atual do MySQL - mysql Ver 14.14 Distrib 5.1.63, para debian-linux-gnu (x86_64) usando readline 6.1
• Atualização do Plesk da 10.4.4 Atualização 47 a 11.0.9 Atualização 23
• Reiniciado quase diariamente
• Todos os crons pararam nos horários correspondentes às falhas do servidor
• Criamos um log do MySQL para monitorar os tempos de bloqueio em consultas

Causas possíveis:

• Falha no hardware
• Configuração de software incorreta (MySQL, Apache etc)

Responsabilidades:

• Pequeno servidor da Web
• Executa nosso sistema de faturamento - WHMCS
• Responsável por CRONs
• Solução de e-mail em massa - nenhum tempo de entrega coincide com falhas no servidor

Soluções propostas:

• Mover a máquina para a VM
• Formatar e restaurar o backup do servidor Plesk e tirá-lo de lá?

Notas laterais:

• Parece ser uma falha geral do Apache em todos os nossos servidores Linux - problema intermitente
• Estamos fazendo algo fundamentalmente errado na configuração do Apache? (Eu entendo que esta é uma questão secundária, apenas certificando-se que não é, possivelmente, mantendo qualquer relevância)

Answer 1

Eu nunca uso o prtg, mas se estou lendo o gráfico corretamente, você está ficando sem memória. E o seu problema no servidor durou, se não caiu completamente, por volta das 01:00 às 02:00. Embora o problema pareça começar a partir das 12h. A carga do seu servidor simplesmente salta para o telhado naquele exato momento.

Durante esse período:

• Gráfico Memória (Swap) Free 2 , uso de troca acumulado até 6G-7G, ou seja muito comparando com 1G de ram física
• Gráfico Memória (Real) Grátis 2 / SNMP Linux Meminfo 2 , todos os RAM são usados

Embora a memória parece ser a causa principal. É possível (ou parte do problema) causada pela falta de energia da CPU. Como o pedido anterior ainda está sendo processado, um novo pedido é enviado, e cada vez mais pedidos se acumulam no servidor.

Eu sugeriria aumentar a memória e também descobrir o que está sendo executado às 12h.

    

Answer 2

Parece que você precisa fazer uma análise real da (s) causa (s) raiz (es).

• Configure e monitore o status do servidor do apache para obter um sentir pela carga do servidor web.
• Configure o monitoramento do sistema para métricas básicas (CPU, memória, atividade de disco) para ver onde exatamente o afunilamento é
• Monitore dmesg de perto, tanto quando você reiniciar quanto durante a execução normal, para verificar se não há problemas de hardware óbvios.

Depois de ter alguns dias de dados sólidos, você pode dar o próximo passo (o que você pensou que estava fazendo agora - peça conselhos.)

    

Answer 3

99,9% do tempo em uma configuração como a que você tem é a configuração incorreta do mysql em uma caixa que é muito pequena para lidar com a quantidade de conexões designadas. Uma configuração do mysql muito média define o limite de conexão como 200, cada conexão que entra normalmente leva entre 10 ~ 100mb, dependendo das consultas / caching, etc.

Eu vi muitas empresas definindo seus limites de conexão sobre o máximo de memória que a máquina real baseou em como eles a configuram. Quando o MySQL tenta endereçar a memória e é designado para swap, isso faz com que o sistema trave. Normalmente você pode ver os traços no dmesg.

Poste sua configuração do MySQL + número de cpus / vcpus e memória, provavelmente é o MySQL que está configurado incorretamente. A documentação é difícil de seguir para o mysql, mas existem alguns scripts auxiliares para você ter uma ideia. Eu vou tentar encontrar um dos que eu usei no passado que é o mais preciso, infelizmente eu não lembro o nome do script fora do topo da minha cabeça.

Também tenha em mente que olhar os logs do mysql não mostrará a história verdadeira.