Não consigo usar o ssh em um servidor remoto quando ele fica sem memória, mesmo que a troca não seja totalmente usada

Question

Eu tenho um servidor godaddy que vem ficando sem resposta periodicamente. Foi difícil solucionar o problema porque não consigo entrar nele quando ele não responde. Eu descobri o que estava acontecendo, adicionando uma tarefa cron que canalizava a saída de "top" para os arquivos de log a cada 5 minutos. A próxima vez que eu desliguei o ciclo depois que ele parou de responder, verifiquei os logs e descobri que o RAM estava no máximo, mas a troca não estava sendo usada.

Estou trabalhando na redução do uso de RAM pelos dois servidores de aplicativos nessa máquina (muitas conexões foram abertas. Cada uma consumiu 30m, por isso, depois que 40 foram abertas, o servidor ficou sem memória RAM), mas o que eu realmente gostaria de saber é como garantir que eu possa entrar na máquina.

Se o arquivo de troca não estiver cheio, eu pensaria que haveria espaço suficiente para o servidor responder, mesmo que isso acontecesse lentamente. Existe alguma maneira que eu possa reservar um pouco de memória ram para que eu possa sempre ssh na máquina?

Aqui está um exemplo do que parece quando o servidor está funcionando normalmente:

top - 15:13:21 up  3:12,  2 users,  load average: 0.15, 0.30, 0.33
Tasks: 127 total,   1 running, 126 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.4%us,  1.8%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   2064980k total,  1611252k used,   453728k free,    45852k buffers
Swap:  2096472k total,        0k used,  2096472k free,   790212k cached

Este é o último log principal que foi registrado antes que o servidor parasse de ser executado:

top - 14:45:08 up 15:20,  0 users,  load average: 0.27, 0.16, 0.10
Tasks: 141 total,   2 running, 139 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.7%us,  1.9%sy,  0.0%ni, 95.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2064980k total,  2007652k used,    57328k free,    60496k buffers
Swap:  2096472k total,      100k used,  2096372k free,   689584k cached

Observe que a tarefa do cron que registra a saída "top" também pára de ser executada quando o servidor fica sem memória RAM, portanto, todo o servidor simplesmente fica paralisado aparentemente.

    

Answer 1

Já tive problemas semelhantes a isso antes e eles podem ser um incômodo para rastrear. Como você forneceu muitas informações para continuar, eu vou ter que soletrar algumas coisas para verificar e também qual foi o meu problema.

Primeiro, verifique seus registros. Mais notavelmente neste caso, a saída do dmesg (este é o buffer do anel do kernel, onde ele armazena os dados do log). Isso é liberado periodicamente para um arquivo (s) em / var / log, embora dependa exatamente de seu sistema operacional. Por exemplo, a Red Hat possui um arquivo / var / log / dmesg. Você está procurando por algo que pareça incomum, especialmente relacionado ao processo assassino da OOM . Isso termina os programas quando a RAM começa a ficar cheia em uma tentativa de manter o servidor ativo e responsivo. O sshd deve estar isento disso, mas isso é específico da distribuição de como é definido. A forma moderna de especificar uma exceção OOM é dar ao sshd uma pontuação informando ao kernel como ele é precioso para o servidor como um todo (o que deve colocá-lo longe na lista de processos para matar se ocorrer uma situação crítica de RAM). Sua distro deveria ter configurado isso corretamente.

A outra coisa a verificar é que o seu servidor tem entropia suficiente com o seguinte:

cat /proc/sys/kernel/random/entropy_avail

Um valor OK está acima de aproximadamente 1000-1500. Abaixo e sua corrida baixa. Só vai até aproximadamente 4000-5000 nas minhas máquinas (estas são baseadas nas minhas observações dos meus servidores).

Eu tive problemas para fazer login em servidores onde a entropia era tão baixa (e a geração era lenta) que os aplicativos ficavam pendurados esperando que mais entropia estivesse disponível. Existe um bug infame do Debian Exim que destacou isso. O Exim usou o GNU TLS no Debian, que usava apenas / dev / random e usava massas de entropia para cada conexão. Veja aqui . Quando a entropia estava esgotada, o Exim simplesmente se pendurava. Isso também faria com que outros programas que dependessem da entropia começassem a recusar conexões também.

Como as chaves de sessão são geradas a cada sessão, o sshd precisa de uma boa fonte de números aleatórios. Embora deva estar usando / dev / urandom para coletar números pseudo-aleatórios se / dev / random estiver bloqueando, não tenho certeza se o sshd estará fazendo isso.

Esse problema pode ser bastante severo em sistemas virtuais, pois muitas das fontes de números aleatórios não são passadas para a máquina virtual. A principal fonte de entropia é a E / S de disco, mas isso normalmente não é passado para a VM. Os geradores de números aleatórios de hardware que podem estar incorporados no chipset / CPU da máquina física provavelmente também não serão passados para a máquina virtual.

Este é um bom artigo sobre o assunto.

Eu corro rngd em segundo plano no meu servidor para alimentar / dev / random com dados de / dev / urandom com isto:

rngd -r /dev/urandom -o /dev/random

Esta não é uma ótima solução, mas é útil para manter as coisas juntas enquanto você procura por fontes de números aleatórios melhores. Estou procurando alimentar rngd com dados de uma fonte diferente, mas ainda não tive muita chance de fazê-lo.