Blocage de l'ordinateur sur la quasi-totalité de la RAM, peut-être un problème de cache disque
Le problème que je pense est quelque peu similaire à ce fil .
Peu importe que le swap soit activé ou désactivé, chaque fois que la quantité réelle utilisée RAM commence à être 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 non (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. Mon hypothèse la moins explicite 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 le cache du disque et ensuite après, le système n’est pas en mesure de les décharger assez 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 est vraiment à court de mémoire vive, je préférerais qu'il tue 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 le moniteur RAM sur mon écran à tout moment et lorsque le blocage s’est produit, il restait toujours à environ 30% de liberté (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 à ce moment-là, 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 n'ai rien remarqué de bizarre, mais je ne savais pas quoi regarder, donc voici: https://docs.google.com/document/d/1iQih0Ee2DwsGd3VuQZu0bPbg0JGJSOCRZhu0B05CMYs/edit?hl=fr CPzF7bcC
Pour résoudre ce problème, nous avons constaté que vous deviez définir le paramètre suivant sur 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 RAM et deux cœurs, alors j'ai calculé 6% sur seulement 1 Go et ajouté 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 assez 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 blocage 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 qu’un des cas d’utilisation et n’est pas toujours la meilleure solution, même si certaines personnes tentent 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é 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.
Le 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 affecter les changements, 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 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, je viens de suivre les instructions ici , comme ceci:
Sudo apt-get install zram-config
Ensuite, j'ai pu configurer la taille de l'échange 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.
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 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 RAM usage 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 __== "__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 votre vm.swappiness sur une valeur très faible, ce qui entraîne une permutation trop tardive du noyau, ce qui laisse le système trop bas RAM au 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 Ubunt recommande de le définir sur 10, mais n'hésitez pas à le définir sur une valeur supérieure. 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 ajouter vm.swappiness = 10 au fichier /etc/sysctl.conf.
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), jouez avec min_free_kbytes, pour avoir plus d'espace dans RAM lorsque votre ordinateur commence à permuter (juste avant 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, régler min_free_kbytes au-dessus de ce qui est recommandé rend le processus de swap considérablement plus rapide.
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 :)
Je suis confronté au même problème d’Ubuntu 16.04 à Ubuntu 18.10 Si vous utilisez plusieurs écrans de Firefox après un certain temps, il restera 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 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, car c'est bruyant), les performances de Linux ont tendance à s'effondrer , pour arriver à TTY1 pour tuer Firefox, cela prend 15 minutes.
Augmenter /proc/sys/vm/vfs_cache_pressure de 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 que cela entraîne, alors je ferais attention à le faire.