100 votes

L'ordinateur se bloque lorsque la RAM est presque pleine, peut-être un problème de cache sur le disque.

Le problème, je pense, est un peu similaire à ce fil.

Peu importe que le swap soit activé ou désactivé, lorsque la quantité de RAM réellement utilisée commence à être proche du maximum et qu'il n'y a presque plus d'espace pour le cache du disque, le système ne répond plus du tout.

Le disque tourne sauvagement, et parfois après de longues attentes de 10 à 30 minutes, il se débloque, et parfois non (ou je perds patience). Parfois, si j'agis rapidement, j'arrive à ouvrir lentement la console et à tuer certaines des applications qui consomment de la mémoire vive, comme le navigateur, et le système se débloque presque instantanément.

A cause de ce problème, je ne vois presque jamais rien dans le swap, seulement parfois il y a quelques MB là, et puis peu après ce problème apparaît. Je pense que ce problème est lié à un cache disque trop gourmand ou à une gestion de la mémoire trop indulgente, de sorte que 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 atteint très rapidement si l'on travaille avec de gros fichiers (500MB+) qui sont chargés dans le cache du disque et apparemment après le système est incapable de les décharger assez rapidement.

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

Pour l'instant, je dois vivre dans une peur constante, lorsque je fais quelque chose, l'ordinateur peut se figer et je dois généralement le redémarrer, s'il est vraiment à court de ram, j'aimerais beaucoup plus qu'il tue certaines applications de l'espace utilisateur, comme le navigateur (de préférence si je pouvais marquer lesquelles tuer en premier).

Mais le mystère est de savoir pourquoi le swap ne me sauve pas dans cette situation.

MISE À JOUR : Il ne s'est pas bloqué pendant un certain temps, mais maintenant j'ai à nouveau plusieurs occurrences. Je garde maintenant le moniteur de ram sur mon écran à tout moment et quand le blocage s'est produit, il montrait encore ~30% de libre (utilisé par le cache disque probablement). Symptômes supplémentaires : Si au moment où je regarde une vidéo (VLC player) le son s'arrête en premier, après quelques secondes l'image s'arrête. Pendant que le son s'arrête, j'ai encore un certain contrôle sur le PC, mais lorsque l'image s'arrête, je ne peux même plus bouger la souris, alors je l'ai redémarré après quelques minutes d'attente. En fait, cela ne s'est pas produit lorsque j'ai commencé à regarder la vidéo, mais après un certain temps (20 minutes) et je n'ai rien fait d'autre à ce moment-là, même si le navigateur et oowrite étaient ouverts sur le deuxième écran pendant tout ce temps. En gros, quelque chose décide de se produire à un moment donné et bloque le système.

Comme demandé dans les commentaires, j'ai exécuté dmesg juste après l'accrochage. Je n'ai rien remarqué de bizarre, mais je ne savais pas quoi chercher, alors voilà : https://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGjSOCRZhu0B05CMYs/edit?hl=en_US&authkey=CPzF7bcC

82voto

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

sysctl -w vm.min_free_kbytes=65536

Gardez à l'esprit qu'il s'agit d'un paramètre par cœur, donc si j'ai 2 Go de RAM et deux cœurs, j'ai calculé 6 % de seulement 1 Go et j'ai ajouté un peu plus par sécurité.

Cela oblige l'ordinateur à essayer de garder cette quantité de RAM libre et, ce faisant, 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, donc vous devriez probablement limiter votre échange également :

sysctl -w vm.swappiness=5

(100 = échanger aussi souvent que possible, 0= échanger uniquement en cas de nécessité absolue)

Le résultat est que linux ne décide plus aléatoirement de charger un fichier vidéo entier d'environ 1 Go dans la mémoire vive pendant qu'il le regarde, et de tuer la machine en le faisant.

Maintenant, il y a assez d'espace réservé pour éviter la faim de mémoire, qui était apparemment le problème (vu qu'il n'y a plus de freezes comme avant).

Après avoir testé pendant une journée, les blocages ont disparu. Il y a parfois des ralentissements mineurs, parce que les données sont mises en cache plus souvent, mais je peux vivre avec ça si je ne dois 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 qu'un des cas d'utilisation et n'est pas toujours la meilleure, même si certaines personnes essaient de suggérer le contraire.


Vous voudrez probablement rendre ces paramètres permanents en les ajoutant à votre liste d'utilisateurs. /etc/sysctl.conf comme ça :

vm.swappiness=5
vm.min_free_kbytes=65536

11voto

Dale Anderson Points 375

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

Dans mon cas, cela n'avait rien à voir avec les problèmes de sysctl mentionnés.

Le problème était plutôt que l'UUID de la partition swap était différent pendant l'installation et après. Ainsi, mon swap n'a jamais été activé, et ma machine se bloquait après quelques heures d'utilisation.

El solution était de vérifier l'UUID actuel de la partition swap avec

sudo blkid

et ensuite sudo nano /etc/fstab pour remplacer la valeur UUID du swap incorrect par celle rapportée par blkid.

Un simple redémarrage pour appliquer les changements, et voilà.

9voto

Saim Raza Points 191

Rien n'a marché pour moi !

J'ai donc écrit un script pour surveiller l'utilisation de la mémoire. Il essaiera d'abord de vider le cache de la RAM si la consommation de mémoire augmente un seuil. Vous pouvez configurer ce seuil sur le script. Si la consommation de mémoire ne descend pas sous le seuil même alors, il commencera à tuer les processus un par un dans l'ordre décroissant de la consommation de mémoire jusqu'à ce que la consommation de mémoire soit inférieure au seuil. Je l'ai fixé à 96% par défaut. Vous pouvez le configurer en modifiant la valeur de la variable RAM_USAGE_THRESHOLD dans le script.

Je suis d'accord que tuer les processus qui consomment beaucoup de mémoire n'est pas la solution parfaite, mais il vaut mieux tuer UNE application plutôt que de perdre TOUT le travail ! !! le script vous enverra une notification de bureau si l'utilisation de la RAM augmente le seuil. Il vous notifiera également s'il tue un 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 appelé save_hang.py. Exécutez le script comme :

sudo python save_hang.py

Veuillez noter que ce script est compatible pour Python 3 uniquement et nécessite l'installation du paquet tkinter. vous pouvez l'installer comme :

sudo apt-get install python3-tk

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

5voto

brismuth Points 151

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šjanis Nesenbergs, et cela a fonctionné quelque peu, mais il y a toujours des plantages parfois.

J'ai finalement trouvé une solution qui a fonctionné en installant zram au lieu d'utiliser le swap physique sur le SSD. Pour l'installer, j'ai simplement suivi les instructions aquí comme ceci :

sudo apt-get install zram-config

Ensuite, j'ai pu configurer la taille du zram swap 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 que la taille du zram soit la même que la quantité de ram dont je dispose. Depuis que j'ai fait cela, je n'ai plus eu de freezes ou de non-réponse du système.

3voto

Lekensteyn Points 162346

Je pense que vous avez réglé votre vm.swappiness à une valeur très basse, ce qui amène le noyau à échanger trop tard, laissant trop peu de RAM pour que le système puisse travailler.

Vous pouvez montrer votre réglage actuel d'échange en exécutant :

sysctl vm.swappiness

Par défaut, cette valeur est fixée à 60. Le site Wiki Ubuntu recommande de le fixer à 10, mais n'hésitez pas à le fixer à une valeur plus élevée. Vous pouvez le modifier en exécutant :

sudo sysctl vm.swappiness=10

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

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

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X