Congelamento de computador em RAM quase cheia, possivelmente problema de cache de disco

Question

O problema que eu acho é um pouco semelhante a isso

Não importa se eu tenho a troca ativada ou desativada, sempre que a quantidade real de RAM usada estiver próxima do máximo e quase não houver espaço para o cache de disco, o sistema não responderá totalmente.

O disco está descontroladamente descontrolado e, às vezes, depois de muito tempo, aguarda de 10 a 30 minutos para descongelar e, às vezes, não (ou não fico satisfeito). Às vezes, se eu agir rapidamente, consigo abrir lentamente o console e matar alguns aplicativos de ram, como o navegador, e o sistema descongela quase instantaneamente.

Devido a esse problema, quase nunca vejo nada na troca, apenas algumas vezes há alguns MB e, logo depois, esse problema aparece. Meu palpite não tão instruído é que ele está conectado de alguma forma ao cache de disco sendo muito ganancioso, ou o gerenciamento de memória é muito brando, então quando a memória é necessária, ela não é liberada rapidamente o suficiente e morre de fome.

O problema pode ser alcançado muito rapidamente se estiver trabalhando com arquivos lagrge (500MB +) que são carregados no cache de disco e depois o sistema não consegue descarregá-los rápido o suficiente.

Qualquer ajuda ou idéias serão muito apreciadas.

Por enquanto eu tenho que viver com medo constante, ao fazer algo computador pode apenas congelar e eu geralmente tenho que reiniciá-lo, se ele está realmente ficando sem memória RAM eu gostaria muito mais para apenas matar alguns dos aplicativos de espaço do usuário, como broser (de preferência se eu pudesse de alguma forma marcar qual matar primeiro)

Embora o mistério seja o motivo pelo qual o swap não me salva nessa situação.

ATUALIZAÇÃO: Não parou por algum tempo, mas agora eu tenho várias ocorrências novamente. Agora estou mantendo o monitor de memória RAM na minha tela em todos os momentos e quando o travamento aconteceu ainda mostrou ~ 30% livre (Usado pelo cache de disco provavelmente). Sintomas adicionais: Se no momento eu estou assistindo vídeo (VLC player) o som pára primeiro, depois de alguns segundos a imagem pára. Enquanto o som parou eu ainda tenho algum controle sobre o PC, mas quando a imagem pára eu não posso nem mexer mais no mouse, então eu reiniciei depois de alguma espera. Btw, isso não aconteceu quando eu comecei a assistir ao vídeo, mas em algum momento (20min) e eu não fiz nada mais ativamente no momento, mesmo que o navegador e o oowrite estivessem abertos na segunda tela o tempo todo. Basicamente, algo apenas decide acontecer em um ponto e trava o sistema.

Como por pedido nos comentários eu corri dmesg logo após o jeito. Eu não notei nada de estranho, mas não sabia o que procurar, então aqui está:   link

    

Answer 1

Para corrigir esse problema, descobri que é necessário definir a seguinte configuração para algo em torno de 5% a 6% da sua RAM física total, dividida pelo número de núcleos no computador:

sysctl -w vm.min_free_kbytes=65536

Lembre-se de que essa é uma configuração por núcleo, por isso, se eu tiver 2 GB de RAM e dois Núcleos, calculei 6% de apenas 1 GB e adicionei um pouco mais apenas para estar seguro.

Isso força o computador a tentar manter essa quantidade de RAM livre e, ao fazer isso, limita a capacidade de armazenar em cache arquivos de disco. É claro que ainda tenta armazená-los em cache e imediatamente trocá-los, então provavelmente você deve limitar sua troca também:

sysctl -w vm.swappiness=5

(100 = troca sempre que possível, 0 = troca apenas por necessidade total)

O resultado é que o Linux não decide mais aleatoriamente carregar um arquivo de filme inteiro de aproximadamente 1 GB em memória RAM enquanto o assiste e mata a máquina ao fazê-lo.

Agora, há espaço reservado suficiente para evitar a falta de memória, o que aparrently foi o problema (visto que não há mais congela como antes).

Depois de testar por um dia - os bloqueios sumiram, às vezes há pequenas lentidões, porque o material fica em cache com mais frequência, mas eu posso viver com isso se não precisar reiniciar o computador a cada poucas horas.

A lição aqui é - o gerenciamento de memória padrão é apenas um dos casos de uso e não é sempre o melhor, embora algumas pessoas tentem sugerir o contrário - o ubuntu deve ser configurado de forma diferente do servidor.

Você provavelmente deseja tornar essas configurações permanentes adicionando-as ao seu /etc/sysctl.conf da seguinte forma:

vm.swappiness=5
vm.min_free_kbytes=65536

    

Answer 2

Isso aconteceu para mim em uma nova instalação do Ubuntu 14.04.

No meu caso, não tinha nada a ver com os problemas de sysctl mencionados.

Em vez disso, o problema era que o UUID da partição de troca era diferente durante a instalação do que era depois da instalação. Então minha troca nunca foi ativada, e minha máquina trava depois de algumas horas de uso.

A solução foi para verificar o UUID atual da partição swap com

sudo blkid

e, em seguida, sudo nano /etc/fstab para substituir o valor UUID da troca incorreta pelo reportado por blkid.

Uma simples reinicialização para afetar as alterações e voila.

    

Answer 3

Eu sei que esta pergunta é antiga, mas eu tive esse problema no Ubuntu (Chrubuntu) 14.04 em um Chromebook Acer C720. Eu tentei a solução Krišjānis Nesenbergs, e ela funcionou um pouco, mas ainda travava às vezes.

Eu finalmente encontrei uma solução que funcionava instalando o zram em vez de usar a troca física no SSD. Para instalá-lo eu apenas segui as instruções aqui , assim :

sudo apt-get install zram-config

Depois, consegui configurar o tamanho da troca do zram modificando /etc/init/zram-config.conf na linha 21.

20: # Calculate the memory to user for zram (1/2 of ram)
21: mem=$(((totalmem / 2 / ${NRDEVICES}) * 1024))

Eu substitui o 2 por um 1 para fazer o tamanho do zram do mesmo tamanho que a quantidade de memória ram que eu tenho. Desde então, não tive mais congelamentos ou falta de resposta do sistema.

    

Answer 4

Nada funcionou para mim !!

Então eu escrevi um script para monitorar o uso da memória. Ele primeiro tentará limpar o cache de RAM se o consumo de memória aumentar um limite. Você pode configurar esse limite no script. Se o consumo de memória ainda não estiver abaixo do limite, ele começará a matar os processos em um em ordem decrescente de consumo de memória até que o consumo de memória fique abaixo do limite. Eu configurei para 96% por padrão. Você pode configurá-lo alterando o valor da variável RAM_USAGE_THRESHOLD no script.

Concordo que matar processos que consomem muita memória não é a solução perfeita, mas é melhor matar UMA aplicação em vez de perder TODO o trabalho !! o script enviará uma notificação na área de trabalho se o uso da RAM aumentar o limite. Ele também irá notificá-lo se ele matar qualquer processo.

#!/usr/bin/env python
import psutil, time
import tkinter as tk
from subprocess import Popen, PIPE
import tkinter
from tkinter import messagebox
root = tkinter.Tk()
root.withdraw()

RAM_USAGE_THRESHOLD = 96
MAX_NUM_PROCESS_KILL = 100

def main():
    if psutil.virtual_memory().percent >= RAM_USAGE_THRESHOLD:
        # Clear RAM cache
        mem_warn = "Memory usage critical: {}%\nClearing RAM Cache".\
            format(psutil.virtual_memory().percent)
        print(mem_warn)
        Popen("notify-send \"{}\"".format(mem_warn), shell=True)
        print("Clearing RAM Cache")
        print(Popen('echo 1 > /proc/sys/vm/drop_caches',
                    stdout=PIPE, stderr=PIPE,
                    shell=True).communicate())
        post_cache_mssg = "Memory usage after clearing RAM cache: {}%".format(
                            psutil.virtual_memory().percent)
        Popen("notify-send \"{}\"".format(post_cache_mssg), shell=True)
        print(post_cache_mssg)

        if psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD:
            print("Clearing RAM cache saved the day")
            return
        # Kill top C{MAX_NUM_PROCESS_KILL} highest memory consuming processes.
        ps_killed_notify = ""
        for i, ps in enumerate(sorted(psutil.process_iter(),
                                      key=lambda x: x.memory_percent(),
                                      reverse=True)):
            # Do not kill root
            if ps.pid == 1:
                continue
            elif (i > MAX_NUM_PROCESS_KILL) or \
                    (psutil.virtual_memory().percent < RAM_USAGE_THRESHOLD):
                messagebox.showwarning('Killed proccess - save_hang',
                                       ps_killed_notify)
                Popen("notify-send \"{}\"".format(ps_killed_notify), shell=True)
                return
            else:
                try:
                    ps_killed_mssg = "Killed {} {} ({}) which was consuming {" \
                                     "} % memory (memory usage={})". \
                        format(i, ps.name(), ps.pid, ps.memory_percent(),
                               psutil.virtual_memory().percent)
                    ps.kill()
                    time.sleep(1)
                    ps_killed_mssg += "Current memory usage={}".\
                        format(psutil.virtual_memory().percent)
                    print(ps_killed_mssg)
                    ps_killed_notify += ps_killed_mssg + "\n"
                except Exception as err:
                    print("Error while killing {}: {}".format(ps.pid, err))
    else:
        print("Memory usage = " + str(psutil.virtual_memory().percent))
    root.update()


if __name__ == "__main__":
    while True:
        try:
            main()
        except Exception as err:
            print(err)
        time.sleep(1)

Salve o código em um arquivo, digamos, save_hang.py. Execute o script como:

sudo python save_hang.py

Por favor, note que este script é compatível apenas com o Python 3 e requer que você instale o pacote tkinter. você pode instalá-lo como:

sudo apt-get install python3-tk

Espero que isso ajude ...

    

Answer 5

Meu palpite é que você definiu seu vm.swappiness para um valor muito baixo, o que faz com que o kernel mude muito tarde, deixando uma RAM muito baixa para o sistema trabalhar.

Você pode mostrar sua configuração atual de swappiness executando:

sysctl vm.swappiness

Por padrão, isso é definido como 60. O recomenda configurá-lo para 10, mas fique à vontade para configurá-lo para um valor mais alto. Você pode alterá-lo executando:

sudo sysctl vm.swappiness=10

Isso mudará para a sessão atual somente , para torná-la persistente, você precisa adicionar vm.swappiness = 10 ao arquivo /etc/sysctl.conf .

Se o seu disco estiver lento, considere comprar um novo.

    

Answer 6

Estou lutando com esse problema há muito tempo, mas agora parece estar resolvido no meu laptop.

Se nenhuma das outras respostas funcionar para você (tentei a maioria delas), brinque com min_free_kbytes , para ter mais espaço na RAM quando o computador iniciar a troca (antes de atingir esse valor mínimo em sua RAM livre).

Tenho 16 GB de RAM, mas mais cedo do que o esperado, a memória ficou cheia e parou de responder por 10 a 30 minutos, até que algumas coisas sejam trocadas.

Pelo menos para mim, definir o valor min_free_kbytes acima do recomendado faz com que o processo de troca seja consideravelmente mais rápido.

Para 16 GB de RAM, tente isto:

vm.min_free_kbytes=500000

Para definir esse valor, veja outras respostas ou apenas pesquise no Google:)

    

Answer 7

Eu corro um dos meus laptops de um Ubuntu Live card constantemente, com uma pequena partição de armazenamento ext4 e um arquivo de swap no disco rígido. Quando quase toda a RAM é usada e o valor do swappiness é muito baixo (às vezes eu prefiro manter o disco rígido completamente desligado, se possível, porque é barulhento), o desempenho do Linux tende a cair de um penhasco para mim, TTY1 para matar o Firefox leva 15 minutos.

Aumentar /proc/sys/vm/vfs_cache_pressure do padrão de 100 para um valor de 6000 parece ajudar a evitar isso. No entanto, a documentação do kernel adverte contra isso, dizendo

Increasing vfs_cache_pressure significantly beyond 100 may have negative
performance impact. Reclaim code needs to take various locks to find freeable
directory and inode objects. With vfs_cache_pressure=1000, it will look for
ten times more freeable objects than there are.

Eu não tenho certeza dos efeitos colaterais de fazer isso, então eu terei cuidado ao fazer isso.