Semelhante a esta questão , temos uma conta de computação servidor com 96 GB de RAM que é usado para executar trabalhos grandes em paralelo.
Ocasionalmente, a quantidade total de RAM física é excedida, o que faz com que o servidor pare de responder, forçando uma reinicialização. Para mim, isso não é um comportamento aceitável, então estou procurando maneiras de corrigir isso.
Sei que uma maneira seria definir limites usando "ulimit -v". No entanto, eu gostaria de evitar seguir esse caminho, se possível, pois ocasionalmente posso ter um processo muito grande (ao contrário de muitos pequenos), então definir um limite útil será difícil.
Eu suspeito que o problema pode vir do fato de que o sistema tem 20GB de troca: em vez de matar o (s) processo (s) ofensivo (s), o sistema irá alocar memória no disco, o que o tornará irresponsivo. Reduzir a quantidade de troca é uma boa ideia?
Qualquer percepção ou experiências com um problema semelhante altamente apreciado!
EDITAR
Eu fiz alguns experimentos usando o seguinte programa C ++ vazando:
#include <vector>
#include <unistd.h>
using namespace std;
int main(int argc,char * argv[])
{
while(true) {
vector<double>* a = new vector<double>(50000000);
sleep(1);
}
}
Eu corri pela primeira vez com um arquivo de swap de 256MB. O sistema ficou completamente pendurado por cerca de 5 minutos, do que voltou à vida. Nos logs, vi que o assassino da OOM havia matado com sucesso meu programa que vazou.
Eu corri uma segunda vez sem troca. Desta vez, a máquina não voltou a funcionar por pelo menos dez minutos, quando reiniciei a máquina. Isso foi uma surpresa para mim, como eu esperava que o assassino da OOM acesse antes em uma máquina sem swap.
O que eu não entendo é o seguinte: por que o Linux espera até que o sistema esteja completamente travado para fazer algo sobre o processo ofensivo? É demais esperar que um sistema operacional não seja completamente eliminado por um processo mal codificado?
Se você quiser que seu servidor continue respondendo, é necessário fazer o melhor para evitar a troca. No entanto, reduzir o valor de swap ou desativá-lo não resolverá seu problema.
Você precisa controlar o uso da memória de seus trabalhos ou instalar mais dispositivos de memória na máquina do servidor.
Você pode tentar cgroups (grupos de controle) para controlar seus processos CPU e uso de memória.
Você tem os logs do oom em / var / log / messages.
Sugiro verificar o /proc/meminfo e monitorá-lo nas horas de pico de uso. O parâmetro Committed_AS mostra quanta memória será necessária se o kernel permitir todas as solicitações de memória de todos os processos naquele momento. Se esse valor estiver abaixo da memória livre, existe uma possibilidade em potencial de que o sistema vá para a OOM.
Como sempre, ajuste a carga de trabalho que o hardware pode acomodar. É melhor aumentar a RAM ou reduzir a carga de trabalho.
Tags memory-usage memory linux