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


75

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


11
Cela doit attirer plus d'attention. Je sais que des bogues sont répertoriés depuis de nombreuses années.
n3rd

1
@ n3rd: C'est le bug .
Dan Dascalescu

@ Krišjānis Nesenbergs: S'il vous plaît, corrigez-moi si je me trompe de copie, le fait de coller un fichier long le fait également bloquer.
Rick2047

Merci d'avoir posé cette question et d'avoir trouvé une solution. S'il vous plaît ajouter une date à la mise à jour, sinon il n'est pas clair ce qui a fonctionné et ce qui n'a pas fonctionné. J'ai le même problème, je vérifie toujours les niveaux de mémoire, et j'ai 16 Go, je prévois d'avoir 32 Go, pour voir si je peux arranger ça de cette façon ...
Beto Aveiga

Réponses:


63

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

1
Bonne trouvaille, essayez de signaler les bugs à ce sujet afin que le problème soit davantage pris en compte et espérons que quelqu'un trouvera une solution pour ne pas charger le film au hasard,
Oxwivi

merci, beaucoup de détails et explique mon problème. Très appréciée!
odedbd

1
eh bien, j'ai presque tout essayé, et seule votre suggestion a amélioré les choses. merci
vitalii

1
Si je suis sans partition de swap, dois-je utiliser une quantité supérieure à 5-6%? Et le réglage vm.swappinessne fera rien dans ce cas, je suppose?
Jarett Millard

1
"[vm.min_free_kbytes] oblige l'ordinateur à essayer de conserver cette quantité de mémoire vive, ce qui limite la capacité de mise en cache des fichiers sur le disque." - désolé de vous déranger, mais cela n'a rien à voir avec ce qui se vm.min_free_kbytespasse. Il agit comme un bloc de pages réservées pour faciliter les __GFP_WAITattributions atomiques (c'est-à-dire remplir ou tuer / non ) en cas de conflit de mémoire système élevé. Il serait peut- être judicieux de le relever ici (car ces blocages sont probablement liés à des conflits de mémoire système), mais ce ne serait certainement pas pour la raison décrite dans cette réponse.
Chris Down

9

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é.


3
Merci beaucoup! Je suis aux prises avec ce virus incroyablement exaspérant depuis près d’un an maintenant, et j’ai tout essayé pour le réparer. Pourquoi Linux a-t-il ce comportement? Il semble qu'il devrait agir comme s'il n'y avait pas d'échange, et simplement invoquer le tueur OOM. Au lieu de cela, il semble prétendre qu'il existe un échange, mais ne parvient pas à échanger des éléments (car il n'y en a pas réellement, car il est mal configuré).
crazy2be

@ crazy2be Ce n'est pas un échec, c'est une réussite sans fin. Même sans échange, Linux peut toujours rechercher des programmes et des fichiers non modifiés en mémoire et les relire à partir du disque.
Martin Thornton le

5

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.


zramest une option viable que si vous ne pouvez pas installer plus de RAM. Si le système est trop lent lors de la permutation sur un disque SSD et sort de la RAM sans permutation, cela zrampeut aider un peu jusqu'à ce que vous essayiez d'en faire un peu plus et que le résultat soit identique à l'absence de RAM, sans permutation.
Mikko Rantalainen

5

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...


2

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.


En réalité, réduire le swapiness a réduit le problème (cela se produisait plus rarement). Je le garde à 5 maintenant. C’était peut-être un autre problème de swapinness, parce qu’à l’âge de 60 ans, j’ai décidé de regarder un film ou d’éditer un gros fichier, un fichier entier de presque un Go a été chargé en mémoire, puis le système a immédiatement échangé des programmes utilisant activement et même l'interface utilisateur elle-même. Le problème, c’est que je pense comprendre la partie permutation; ce que je veux, c’est de tuer les applications utilisateur gloutonnes au lieu de geler la machine lorsque la mémoire vive est insuffisante. (Et de préférence limiter la taille du fichier dans le cache)
Krišjānis Nesenbergs

@Krisa: lorsque le système manque de mémoire (RAM et swap), le noyau appelle oom_kill qui tue les processus pour économiser de la mémoire. Malheureusement, vous ne pouvez pas contrôler les processus cibles. Pour le déclencher manuellement, appuyez sur les touches Alt + SysRq + F. Lors de l'exécution de la dmesgcommande, vous devriez voir des informations (et le nom du processus + id) du processus. Je pense que vous feriez mieux d'acheter un nouveau disque plus rapide. Ou mettez à niveau votre RAM.
Lekensteyn

3
Le problème est que oom_kill n'est pas appelé avant que l'ordinateur ne soit verrouillé pendant environ 30 minutes. En outre, existe-t-il au moins un moyen de savoir quel processus sera tué en premier?
Krišjānis Nesenbergs

2
J'ai 2 Go de RAM et le disque dur est 5400rpm. Je ne pense vraiment pas que ce soit un système aussi ancien qui justifie le blocage d’une demi-heure tout en regardant des vidéos sur un moniteur et en parcourant 20 à 30 onglets dans l’autre. En fait, je serais très heureux si je pouvais toujours accéder à la console et tuer certains processus. Existe-t-il un moyen de donner une très haute priorité à la saisie utilisateur et au terminal afin que cela fonctionne lorsque le système se bloque?
Krišjānis Nesenbergs

1
Quoi qu'il en soit - swapping et la quantité de RAM est un peu offtopic. Le problème est que ce système ne répond plus pendant longtemps, même si le swap est désactivé, et après cela, il continue parfois d'exécuter le programme (pour qu'il trouve la mémoire quelque part) et d'autres fois, il exécute oom_killer. Le système devrait pouvoir dire qu'il est à court de mémoire vive et ne pas me laisser courir plus de choses. Alors, y a-t-il un moyen d'arrêter ces blocages ou de définir la priorité d'entrée d'utilisateur si haut que je peux passer à la console quand ils se produisent et tuer certains processus moi-même?
Krišjānis Nesenbergs

2

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 :)


0

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.


Vous obtiendrez probablement de meilleurs résultats avec des vfs_cache_pressurevaleurs proches de 10 (beaucoup moins de 100) et un réglage min_free_kbytesplus élevé. Soyez averti que si vous définissez une valeur min_free_kbytestrop élevée, le destructeur de MOO au noyau tuera tout le monde!
Mikko Rantalainen

@MikkoRantalainen J'ai déjà relevé min_free_kbytesà 262144 et j'ai constaté que baisser vfs_cache_pressureavait l'effet inverse: le réduire à moins de 100 rendait le système inactif plus rapidement. Je ne sais pas pourquoi exactement.
Hitechcomputergeek

En général, augmenter vfs_cache_pressureentraînera la projection des répertoires avant le contenu du fichier mis en cache et, par conséquent, les performances globales vont en souffrir avec des valeurs supérieures à 100. Si vous parvenez à comprendre les étapes à suivre pour reproduire afin de bloquer / bloquer le système, par exemple avec Ubuntu Live CD alors les développeurs du noyau peuvent trouver la cause. Pour moi, le blocage se produit sans aucun avertissement. Ma meilleure hypothèse est que le noyau se bloque avant que MOO Killer n'ait libéré suffisamment de RAM. J'exécute maintenant min_free_kbytes = 100000, admin_reserve_kbytes = 250000 et user_reserve_kbytes = 500000.
Mikko Rantalainen

(suite) Je n'ai pas encore écrasé avec la configuration ci-dessus même si j'ai swappiness = 5 et vfs_cache_pressure = 20. Le système dispose de 16 Go de RAM et de 8 Go d’échange sur SSD. Un autre système a 32 Go de RAM et zéro swap et semble aléatoirement souffrir du même problème - appuyer sur Alt + SysRq + f après que le système se soit ralenti semble aider, donc je suppose que si OOM Killer agissait assez vite, le système ne se bloquerait pas.
Mikko Rantalainen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.