Estouro da memória do servidor web do CentOS - não é possível efetuar login

1

Alguns dias atrás, meu servidor Web CentOS 6.2 com o ISPconfig 3 diminuiu até o ponto em que eu não consegui logar via SSH nem usar um console. O console estava cheio de mensagens "sem memória, matando o processo, sacrificando crianças" ou algo parecido. O prompt de login via SSH apareceu após um minuto de espera, solicitação de senha após outro minuto ou dois, e assim por diante. O sistema estava claramente sobrecarregado. Eu não fui capaz de reiniciá-lo de forma limpa, então eu o reformei. Eu pensei que era algum fracasso isolado, mas a mesma situação se repetiu algumas horas atrás. É um servidor de produção e eu não tinha condições de experimentar, então eu apenas aumentei a RAM (é uma máquina virtual Hyper-V) de 1 GB para 2 GB e a reiniciei mais uma vez. Agora está tudo bem por dois dias ou algo assim. No dia seguinte a mesma situação se repetiu com outra máquina similar, o CentOS 6.3. Acabei de reiniciá-lo sem aumentar a RAM e agora tudo corre bem.

Não sei o que é, por que ocorreu e como evitá-lo. Parece-me que havia muita memória RAM alocada para que o sistema começasse a exibir tudo, o que reduzia o desempenho ao ponto de virtualmente parar a máquina. Este é um log de sar da segunda máquina:

12:03:14 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
06:40:52 AM     all      0.10      0.00      1.59     98.31      0.00      0.00
07:37:29 AM     all      0.09      0.00      1.37     98.54      0.00      0.00
09:51:37 AM     all      0.07      0.00      1.34     98.59      0.00      0.00
11:01:13 AM     all      0.05      0.00      1.35     98.61      0.00      0.00
12:57:39 PM     all      0.09      0.00      1.60     98.31      0.00      0.00

É possível que tenha sido algum tipo de ataque do DOS? Ambas as máquinas têm endereços IP numericamente consecutivos, então talvez seja algo que leva endereços um por um? Isso aponta para alguma fraqueza na configuração de segurança? Existe alguma maneira de saber com mais precisão o que aconteceu e por quê?

A maior surpresa foi que não consegui fazer login e operar o sistema. O Linux deveria fazer isso? Ou significa que minha configuração está de alguma forma errada? Eu tenho que ter algumas configurações para não permitir que qualquer processo coma muita memória? É algo que pode acontecer, ou significa que eu estraguei a instalação?

EDIT - mais informações sobre configuração:

Ambas as máquinas têm as seguintes instaladas: ISPConfig 3, Apache, MySQL, PHP, Postfix, Courier, PureFTPd, Bind (a instalação padrão do ISPConfig no CentOS). Eles atuam como servidores da web, com carga bastante baixa - a segunda máquina, da qual é o trecho de sar, serviu 8000 arquivos no dia em que aconteceu.

O sar log foi o trecho para o período de tempo em que o problema ocorreu. Imediatamente após a reinicialização, ele reverteu para a operação normal que se parece com isso (atual sar log, iotop mostra quase 0 leituras 0 escreve agora):

07:20:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
07:30:01 AM     all      1.15      0.00      0.27      0.38      0.00     98.20
07:40:01 AM     all      0.96      0.00      0.23      0.24      0.00     98.57
07:50:01 AM     all      1.71      0.00      0.37      1.86      0.00     96.07

De acordo com os logs do Apache, não houve carga incomum ou contagem de solicitações excepcional. Eu encontrei apenas essa linha incomum no log de erros:

[Tue Feb 19 05:39:30 2013] [error] server reached MaxClients setting, consider raising the MaxClients setting

Esta parece ser a raiz dos problemas, não é?

    
por Jan Svab 20.02.2013 / 22:00

1 resposta

0

Ok, sem mais dicas ou respostas, então a pergunta provavelmente não é específica o suficiente. Eu provavelmente tomarei "sobrecarga do servidor web" como a conclusão. No entanto, ainda não sei por que isso ocorreu ou se pode ser algum tipo de ataque do DOS. Talvez seja uma característica do Apache que ele fique sem MaxClients permitido quando ele está ativo por muito tempo? No entanto, a solução "reiniciar servidor, aumentar a RAM" é provavelmente algo que eu possa viver com (ou pelo menos eu vou ter que).

    
por 22.02.2013 / 10:19