Você pode definir um tamanho mínimo de buffer de disco linux?

Eu tenho uma máquina Linux bastante antiga com 2 GB de RAM, sem troca, e está funcionando muito bem, com o sistema usando todas as partes de memória não utilizadas para fazer cache com grande efeito.

No entanto, quando estou quase estressando a memória (por exemplo,> 1950 MB alocados), ela fica lenta; Eu suspeito que é porque não há buffers de disco restantes. Eu sei que o assassino da OOM logo entraria em vigor, mas geralmente não chega lá - está ficando tão lento que as cargas disparam para 30-40, nenhum processo progride (portanto, não aloca mais memória) e Eu tenho que reiniciar.

Quando tento simplesmente matar um processo para fazer com que a máquina responda, por exemplo, indo ao console (via Alt-F1, efetuando login e apenas executando um "processo ruim de killall"), geralmente funciona, exceto que tenho que esperar ~ 10 minutos entre usuário / senha e obter um prompt - enquanto houver atividade no disco.

Mais uma vez, não há troca, por isso não está trocando - é simplesmente emocionante porque não há buffers restantes.

Eu teria mais ou menos 100 MB dedicados exclusivamente aos buffers de disco, o que acionaria o killer do OOM mais cedo (afinal, menos memória para programas), mas, por outro lado, deixaria a máquina sempre responsiva.

Existe uma maneira de fazer isso? Não consegui encontrar uma entrada / proc / kernel ou / sys / vm que faça esse tipo de coisa.

linux cache

— HopelessN00b
fonte

Eu também tenho o mesmo problema e, infelizmente, nenhuma das respostas até hoje ajuda nesse assunto.

— Krišjānis Nesenbergs

Respostas:

Dê uma olhada em / proc / sys / vm / min_free_kbytes . É o limite de kbytes livres que aciona o oom-killer. Também seria bom checar nos registros a palavra-chave oom-killer para saber o que está sendo morto {provavelmente você não quer matar ssh , é melhor renitá- la}

— Nikolaidis Fotis
fonte

Obrigado. Aumentei, mas isso não parece resolver o problema - uma vez que a memória física estava quase esgotada, não havia mais memória buffer e a máquina diminuiu a velocidade.

Também não ajuda aqui, o sistema ainda não responde.

— Tronic

Isso realmente me ajudou, eu também tenho 2 GB de RAM e defino-o para quase 500 MB - por enquanto não há lentidão / interrupções

— Krišjānis Nesenbergs

No momento, estou testando essa configuração na minha estação de trabalho. Tenho 8 GB de RAM e, na maioria das vezes, não uso mais do que 5 ... exceto quando, por algum motivo, tenho que iniciar uma VM do Windows que requer cerca de 4 GB de RAM. Eu tenho o ZRAM configurado no SO host porque meu disco rígido é mecânico, mas ainda fica bastante lento com a RAM quase cheia devido precisamente ao pouco espaço de RAM para buffers e caches do sistema de arquivos. Usei vm.min_free_kbytes para garantir que eu sempre tenha pelo menos 2 GB de espaço livre e que o restante seja paginado para RAM compactada (que é muito mais rápida que o espaço de troca normal). Poste mais tarde com resultados.

— RAKK 8/17/17

Esperar o assassino liberar memória é um pouco como esperar que o motor pare no seu carro para lhe dizer quando é a hora de encher o tanque de gasolina. O assassino é uma ferramenta pesada, de último recurso e desespero por uma máquina carente de recursos. Ele mata o próximo programa em que toca, sem levar em consideração como isso afetará seu aplicativo, acessibilidade, confiabilidade e assim por diante. Quando o oom-killer é chamado, seu servidor está ofegante e em estado crítico.

Em vez disso, é muito melhor adotar uma abordagem ativa para gerenciar o uso da memória no ambiente do aplicativo. Você pode monitorar / proc / meminfo quanto a problemas e tomar as medidas apropriadas e acelerar a carga de trabalho antes que uma situação séria fique feia.

— tylerl
fonte

A situação que descobri é exatamente a hora em que meu servidor está sem fôlego e em estado crítico. Uma máquina totalmente responsiva leva menos de 20 segundos para levar 1 minuto para responder ao Ctrl-Alt-F1 (alternar de X para console). E o logon é impossível, porque o tempo limite é excedido após 1 minuto, sem que seja necessário solicitar uma senha. Esta é uma máquina que possui muitos processos em execução; cada um independentemente não é o problema. Além disso, isso é estritamente um problema de memória - a CPU está boa e o disco está bom, desde que restem cerca de 50 MB de buffers de disco.

e se você usar ulimit e se um aplicativo usar acima de um limite para executar uma ação?

— Nikolaidis Fotis

O problema é a soma de todos os aplicativos; 20 ou mais estão em execução, cada um com 20 a 100 MB alocados. Funciona bem por semanas, até meses, mas quando todos querem ter ~ 100 MB alocados ao mesmo tempo, tudo trava e queima; Prefiro que oom_killer mate um deles do que ter que reiniciar a máquina. De qualquer forma, ativei a troca por enquanto - a maioria dos aplicativos não usa toda a memória o tempo todo, portanto a máquina permanece estável mesmo quando estressada no final da memória física; no entanto, eu preferiria não ter nenhuma troca por esta máquina, se puder.

Não resolve o problema real, que é uma combinação de não definir limites de uso de memória adequados (os ulimits não são muito úteis), os aplicativos estragam facilmente as alocações de memória, o assassino do OOM falha ao disparar cedo o suficiente e o enorme lixo no disco e a falta de resposta causado por tudo isso. Acabei de desperdiçar 30 minutos do tempo do meu empregador porque a máquina de desenvolvimento lixeira o disco por meia hora enquanto compilava meu código, em vez de simplesmente matar os processos do Chromium necessários para matar (ou a própria compilação) em menos de um segundo e depois seja feito com isso.

— Tronic

Se você definir oom_adjcorretamente, poderá fazer com que seu sistema de desktop funcione um pouco como o Android, onde o sistema está sempre rodando contra o OOM killer (tecnicamente, existe um "killer com pouca memória" e é ajustado via /sys/module/lowmemorykiller). A lógica é marcar continuamente processos em segundo plano não críticos como possíveis vítimas do assassino de OOM e procurar processos mortos e reiniciar lentamente os programas mortos necessários para evitar sobrecarregar o sistema. Apenas verifique se o processo que continua reiniciando outros processos está marcado fora dos limites do OOM killer.

— Mikko Rantalainen