Blocage de l'ordinateur sur de la mémoire RAM presque complète, peut-être un problème de cache disque

Pour résoudre ce problème, j'ai constaté que vous deviez définir le paramètre suivant à environ 5% à 6% de votre RAM physique totale, divisée par le nombre de cœurs de l'ordinateur:

sysctl -w vm.min_free_kbytes=65536

N'oubliez pas qu'il s'agit d'un paramètre par cœur. Par conséquent, si j'ai 2 Go de RAM et deux cœurs, alors j'ai calculé 6% sur seulement 1 Go et ajouté un petit extra juste pour être sûr.

Ceci oblige l’ordinateur à essayer de garder cette quantité de RAM libre, ce qui limite la possibilité de mettre en cache les fichiers du disque. Bien sûr, il essaie toujours de les mettre en cache et de les échanger immédiatement. Vous devriez donc probablement aussi limiter votre échange:

sysctl -w vm.swappiness=5

(100 = échangez le plus souvent possible, 0 = échange uniquement si vous en avez besoin)

Le résultat est que Linux ne décide plus de manière aléatoire de charger un fichier de film entier d’environ 1 Go en RAM tout en le regardant, ce qui tue la machine.

Maintenant, il y a suffisamment d'espace réservé pour éviter la famine de mémoire, ce qui posait un problème (puisqu'il n'y avait plus de blocage, comme avant).

Après avoir testé pendant une journée, les verrouillages ont disparu, il y a parfois des ralentissements mineurs, car les objets sont mis en cache plus souvent, mais je peux vivre avec cela si je ne dois pas redémarrer l'ordinateur toutes les quelques heures.

La leçon à retenir est que la gestion de la mémoire par défaut n’est que l’un des cas d’utilisation et n’est pas toujours la meilleure solution, même si certaines personnes essaient de suggérer le contraire. Le divertissement domestique Ubuntu doit être configuré différemment du serveur.

Vous voudrez probablement rendre ces paramètres permanents en les ajoutant à votre /etc/sysctl.conf comme ceci:

vm.swappiness=5
vm.min_free_kbytes=65536

Cela m'est arrivé lors d'une nouvelle installation d'Ubuntu 14.04.

Dans mon cas, cela n’a rien à voir avec les problèmes de système mentionnés.

Au lieu de cela, le problème était que l'UUID de la partition de swap était différent lors de l'installation par rapport à après l'installation. Ainsi, mon échange n'a jamais été activé et ma machine se verrouillerait après quelques heures d'utilisation.

La solution consistait à vérifier l'UUID actuel de la partition de swap avec

sudo blkid

puis sudo nano /etc/fstab pour remplacer la valeur UUID du swap incorrect par celle indiquée par blkid.

Un simple redémarrage pour modifier les modifications et le tour est joué.

Je sais que cette question est ancienne, mais j’ai eu ce problème dans Ubuntu (Chrubuntu) 14.04 sur un Chromebook Acer C720. J'ai essayé la solution de Krišjānis Nesenberg, et cela a fonctionné quelque peu, mais il est parfois tombé en panne.

J'ai finalement trouvé une solution qui fonctionnait en installant zram au lieu d'utiliser un échange physique sur le SSD. Pour l'installer, je viens de suivre les instructions ici , comme ceci :

sudo apt-get install zram-config

Ensuite, j'ai pu configurer la taille du swap zram en modifiant /etc/init/zram-config.conf à la ligne 21.

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

J'ai remplacé le 2 par un 1 afin de donner à la taille du zram la même taille que la quantité de RAM dont je dispose. Depuis, je n'ai plus eu de blocage ou de non-réponse du système.

Je suppose que vous avez défini votre valeur de vm.swappiness sur une valeur très faible, ce qui entraîne une permutation trop tardive du noyau, ce qui laisse une mémoire RAM trop faible pour le système.

Vous pouvez afficher votre paramètre swappiness actuel en exécutant:

sysctl vm.swappiness

Par défaut, la valeur est 60. Wiki Ubuntu recommande de le définir sur 10, mais n'hésitez pas à le définir à une valeur plus élevée. Vous pouvez le changer en exécutant:

sudo sysctl vm.swappiness=10

Cela le modifiera pour la session en cours uniquement . Pour le rendre persistant, vous devez ajouter vm.swappiness = 10 au fichier /etc/sysctl.conf .

Si votre disque est lent, envisagez d’en acheter un nouveau.

Rien n'a fonctionné pour moi !!

J'ai donc écrit un script pour surveiller l'utilisation de la mémoire. Il essaiera d’abord d’effacer le cache de la RAM si la consommation de mémoire augmente d’un seuil. Vous pouvez configurer ce seuil sur le script. Si, même dans ce cas, la consommation de mémoire ne dépasse pas le seuil, la suppression des processus est annulée par ordre décroissant de consommation de mémoire jusqu'à ce que celle-ci soit inférieure au seuil. Je l'ai réglé à 96% par défaut. Vous pouvez le configurer en modifiant la valeur de la variable RAM_USAGE_THRESHOLD dans le script.

Je conviens que tuer des processus qui consomment beaucoup de mémoire n’est pas la solution parfaite, mais il vaut mieux tuer UNE application au lieu de perdre TOUT le travail! le script vous enverra une notification sur le bureau si l'utilisation de la RAM augmente le seuil. Il vous avertira également si cela tue tout processus.

#!/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)

Enregistrez le code dans un fichier, par exemple, save_hang.py. Exécutez le script en tant que:

sudo python save_hang.py

Notez que ce script est compatible avec Python 3 uniquement et vous oblige à installer le paquet tkinter. vous pouvez l'installer en tant que:

sudo apt-get install python3-tk

J'espère que cela vous aidera ...

Je suis aux prises avec ce problème depuis longtemps, mais maintenant, il semble être résolu sur mon ordinateur portable.

Si aucune des autres réponses ne vous convient (j'ai essayé la plupart d'entre elles), jouez avec min_free_kbytes , pour disposer de plus d'espace disque dans la RAM lorsque votre ordinateur commence à permuter (juste avant de passer à cette valeur minimale). votre RAM libre).

J'ai 16 Go de RAM, mais plus tôt que tard, la mémoire est devenue pleine, puis a cessé de répondre pendant 10 à 30 minutes, jusqu'à ce que certaines choses soient échangées.

Au moins pour moi, définir la valeur min_free_kbytes au-dessus de la valeur recommandée accélère considérablement le processus de permutation.

Pour 16 Go de RAM, essayez ceci:

vm.min_free_kbytes=500000

Pour définir cette valeur, consultez les autres réponses ou recherchez-le simplement dans Google:)

Je suis confronté au même problème depuis Ubuntu 16.04 à Ubuntu 18.10 Si vous utilisez firefox plusieurs onglets après un certain temps, il sera bloqué et ne pourra plus rien faire par la suite. Ensuite, je veux appuyer sur le bouton d'alimentation pour continuer à nouveau. Je crains que mon système ne soit endommagé!

J'utilise constamment l'un de mes ordinateurs portables depuis une carte SD live Ubuntu, avec une petite partition de stockage ext4 et un fichier d'échange sur le disque dur. Lorsque la quasi-totalité de la mémoire RAM est utilisée et que la valeur de swappiness est trop faible (parfois, je préfère garder le disque dur complètement hors tension si possible, parce que c'est bruyant), les performances de Linux ont tendance à tomber d'une falaise pour moi. TTY1 pour tuer Firefox prend 15 minutes.

Le fait de relever /proc/sys/vm/vfs_cache_pressure de la valeur par défaut de 100 à une valeur de 6000 semble aider à éviter cela. Cependant, la documentation du noyau vous avertit de ne pas le faire, en disant

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.

Je ne suis pas tout à fait sûr des effets secondaires de cette opération, alors je ferais attention de le faire.