Blocage de l'ordinateur sur la quasi-totalité de la RAM, peut-être un problème de cache disque

Je pense que le problème est un peu similaire à ce fil.

Peu importe que le swap soit activé ou désactivé, chaque fois que la quantité réelle de RAM utilisée commence à devenir proche du maximum et qu'il ne reste presque plus d'espace pour le cache disque, le système ne répond plus du tout.

Le disque tourne spinnigieusement, et parfois après de longues attentes, 10 à 30 minutes, il se dégèle, et parfois pas (ou je manque de patience). Parfois, si j'agis rapidement, je parviens à ouvrir lentement la console et à tuer certaines applications de restauration dynamique, comme le navigateur, et le système se débloque presque instantanément.

En raison de ce problème, je ne vois presque jamais rien dans le swap. Seulement, il y a parfois quelques Mo ici, et peu après, ce problème apparaît. Ma conjecture, moins éduquée, serait que le cache disque soit trop gourmand ou que la gestion de la mémoire soit trop indulgente. Ainsi, lorsque la mémoire est nécessaire, elle n'est pas libérée assez rapidement et affame le système.

Le problème peut être résolu très rapidement si vous travaillez avec des fichiers lagrge (500 Mo +) chargés dans la mémoire cache du disque et ensuite après, le système n’est pas en mesure de les décharger suffisamment rapidement.

Toute aide ou idée sera grandement appréciée.

Pour le moment, je dois vivre dans une peur constante. Lorsque je fais quelque chose, un ordinateur peut tout simplement geler et je dois généralement le redémarrer. S'il manque vraiment de mémoire vive, je préférerais qu'il ne tue que certaines applications de l'espace utilisateur, comme broser ( de préférence si je pouvais en quelque sorte marquer lequel tuer en premier)

Bien que le mystère soit, pourquoi l’échange ne me sauve-t-il pas dans cette situation.

MISE À JOUR: Il ne s'est pas arrêté pendant un certain temps, mais maintenant, j'ai eu plusieurs événements à nouveau. Je garde maintenant mon moniteur de RAM sur mon écran à tout moment et quand le blocage s'est produit, il restait toujours ~ 30% libre (probablement utilisé par le cache disque). Symptômes supplémentaires: si au moment où je regarde une vidéo (lecteur VLC), le son s’arrête en premier, puis l’image s’arrête après quelques secondes. Bien que le son se soit arrêté, j'ai toujours un certain contrôle sur PC, mais lorsque l'image s'arrête, je ne peux même plus déplacer la souris. Je l'ai donc redémarrée après quelques temps d'attente. Au fait, cela ne s'est pas produit lorsque j'ai commencé à regarder la vidéo, mais quelque temps après (20 min) et que je ne faisais pas activement autre chose à l'époque, même si navigateur et oowrite étaient toujours ouverts sur le deuxième écran. Fondamentalement, quelque chose décide d’arriver à un moment donné et bloque le système.

Comme demandé dans les commentaires, j'ai lancé dmesg juste après le blocage. Je ne ai pas remarqué quelque chose de bizarre, mais ne savais pas pour ce qu'il faut, si elle est ici: https://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGjSOCRZhu0B05CMYs/edit?hl=en_US&authkey=CPzF7bcC

Pour résoudre ce problème, nous avons constaté que vous deviez définir le paramètre suivant à environ 5% à 6% de votre RAM physique totale, divisé 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, je calcule alors 6% sur seulement 1 Go et ajoute un petit extra pour plus de sécurité.

Cela 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 = échange le plus souvent possible, 0 = échange uniquement en cas de nécessité totale)

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 le problème avec bonté (vu qu'il n'y a plus de gel comme avant).

Après avoir testé pendant une journée - les blocages 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 n'ai pas à redémarrer l'ordinateur toutes les quelques heures.

La leçon à tirer est la suivante: 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.confcomme ceci:

vm.swappiness=5
vm.min_free_kbytes=65536

Cela m'est arrivé dans 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/fstabpour remplacer la valeur UUID du swap incorrect par celle signalée par blkid.

Un simple redémarrage pour affecter les changements, et le tour est joué.

Je sais que cette question est ancienne, mais j'avais 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 encore planté parfois.

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

sudo apt-get install zram-config

Ensuite, j'ai pu configurer la taille de l'échange zram en modifiant la /etc/init/zram-config.confligne 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 bélier que j'ai. Depuis, je n'ai plus eu de blocage ou de non-réponse du système.

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 processus, jusqu'à ce que la consommation de mémoire 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 informera é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

Veuillez noter 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 t'aides...

Mon hypothèse est que vous avez défini vm.swappinessune 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, il est défini sur 60. Le wiki d'Ubuntu vous recommande de le définir sur 10, mais n'hésitez pas à le définir sur une valeur plus élevée. Vous pouvez le changer en lançant:

sudo sysctl vm.swappiness=10

Cela ne le changera que pour la session en cours . Pour le rendre persistant, vous devez l’ajouter vm.swappiness = 10au /etc/sysctl.conffichier.

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

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 fonctionne pour vous (j'ai essayé la plupart d'entre elles), jouez avec min_free_kbytes , pour avoir plus d'espace dans la RAM lorsque votre ordinateur commence à permuter (juste avant d'atteindre cette valeur minimale sur 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 min_free_kbytes au-dessus de ce qui est recommandé 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, voir d'autres réponses, ou simplement google it :)

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 passage /proc/sys/vm/vfs_cache_pressurede la valeur par défaut de 100 à une valeur de 6000 semble aider à empêcher 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 cela, alors je ferais attention à le faire.