Memória cheia, principalmente tomada por “shared”, GUI sem resposta

Question

Existem zilhões de perguntas como essa, mas nenhuma tem uma resposta que funcione para mim. Talvez meu sistema esteja apenas mal configurado.

Meu problema é que depois de algum tempo de atividade (alguns dias), a RAM na minha máquina de desktop (Ubuntu 16.04 LTS) é completamente preenchida e a GUI começa a ficar atrasada e fica sem resposta / inutilizável.

Saída de free :

              total        used        free      shared  buff/cache   available
Mem:       16326212     5633804      395072    10026328    10297336      184458
Swap:             0           0           0

O que não ajuda é isso:

sync; sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches'

= > praticamente nenhuma mudança nos números acima

swapoff -a

= > nenhuma mudança (a troca está desabilitada de qualquer maneira)

Uma diferença marcante para todas as saídas de free postadas em questões relacionadas é que a maior parte da minha memória é ocupada por shared .

No entanto, ipcs -m | awk '{sum+=$5} END{print sum}' produz um número apenas em torno de 213 MB.

Possivelmente relacionado: Eu tenho vários caminhos mapeados para um disco RAM (de /etc/fstab ):

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0 
tmpfs /var/log/apt tmpfs defaults,noatime 0 0

mas parece não haver nenhum problema:

Filesystem           Size  Used Avail Use% Mounted on
tmpfs                1.6G   22M  1.6G   2% /run
tmpfs                1.6G  132K  1.6G   1% /run/user/1000
tmpfs                5.0M  4.0K  5.0M   1% /run/lock
tmpfs                7.8G     0  7.8G   0% /sys/fs/cgroup
tmpfs                7.8G   12M  7.8G   1% /var/tmp
tmpfs                7.8G  1.7M  7.8G   1% /var/log
tmpfs                7.8G  143M  7.7G   2% /dev/shm
tmpfs                7.8G  8.0K  7.8G   1% /var/log/apt
tmpfs                7.8G  878M  7.0G  12% /tmp
...

exceto talvez

udev                 7.8G  7.8G     0 100% /dev

Alguma outra ideia?

    

Answer 1

Esta linha

udev                 7.8G  7.8G     0 100% /dev

era de fato uma característica do problema. Esta montagem provavelmente nunca deve ser 100% preenchida. Depois de ler uso de memória High SHMem! eu achei que bootchart tinha preenchido isso completamente. Depois de desinstalar bootchart e excluir /dev/.bootchart , tudo estará de volta ao normal, incluindo o uso da memória shared :

              total        used        free      shared  buff/cache   available
Mem:       16326212     3258332     7929904     1177272     5137976    10981178
Swap:             0           0           0

    

Answer 2

Você precisa descobrir o que enche a memória do seu computador. A primeira coisa que me vem à mente é o navegador. Os navegadores modernos usam quantidades insanas de memória.

Você pode descobrir o que usa a quantidade de memória com smem . Há smem empacotado para o Ubuntu 17.x aqui: link . Depende apenas de python e python-matplotlib , que estão disponíveis no Ubuntu 16.x. Então você deve ser capaz de baixar o pacote smem e instalá-lo com dpkg -i smem_1.4-2_all.deb .

Após instalá-lo, você pode simplesmente executar smem e verá qual processo está usando a quantidade de memória.

Depois de descobrir o que enche a memória, você pode simplesmente interromper esse processo. F.ex. fechando abas no navegador ajuda. Além disso, parar e iniciar o navegador pode ajudar a liberar memória.

Mais uma coisa - você deve ativar a troca. A troca irá estender sua memória disponível.

Uma outra coisa - já que - aparentemente - você não está usando swap, então "a GUI começa atrasada e não responde / não é utilizável" provavelmente não é causada pela memória sendo preenchida, mas por algum processo acessando o disco também muito (um backup em execução, reconstruindo o banco de dados mlocate veio à minha mente) ou usando muito o CPU. Você deve ser capaz de diagnosticar "uso excessivo de CPU" com top e muito uso de I / O com iotop ( apt-get install iotop ).