Système suspendu lorsqu'il manque de mémoire

34

J'ai un eeePC 900a: il a un disque flash de 8 Go et seulement 1 Go de RAM. La distribution Linux installée est ArchLinux.

Lorsque le système est à court de mémoire , il devient extrêmement insensible: il faut plusieurs secondes / minutes pour faire des choses comme le passage à TTY1 ou même de déplacer le pointeur de la souris. Parfois, on a l'impression que le système se fige: il y a trois ans, je le laissais faire et rien n'a changé jusqu'à présent.

Je préférerais éviter de créer une partition / un fichier d'échange sur cet eeePC car le disque est déjà aussi petit et que de nombreuses écritures sur l'espace d'échange réduiraient considérablement la durée de vie de la carte Flash. De plus, je pense qu'un fichier / une partition d'échange ne ferait que déplacer le problème, au lieu de le résoudre définitivement.

Le noyau n'est-il pas censé tuer des applications aléatoires lorsqu'il manque de mémoire? Pourquoi cela échoue-t-il (ou prend-il des siècles)?

Il ya quelques mois / années, j’ai déjà essayé d’approfondir cette question, mais je n’ai rien trouvé qui puisse réellement fonctionner ...

linux memory freeze

— peoro
source

1

Quel DE / WM utilisez-vous dans votre configuration, quels services / daemons utilisez-vous? L'utilisation d'un environnement de bureau complet et la navigation avec Chromium ou Firefox, par exemple, consomment votre RAM pour un brunch. 1 Go de RAM devrait suffire à faire fonctionner Arch Linux lui-même, mais ce qui compte vraiment, c'est ce que vous y mettez.

1

J'utilise LXDE. Le chrome est le programme qui utilise généralement la majeure partie de la RAM. En tout cas ce n'est pas le but. Ce n'est pas moi qui dois me soucier de la quantité de mémoire utilisée par mon système, c'est mon système qui ne devrait pas mourir à cause de cela. Si mon système manque de mémoire, il est libre de tuer toutes les applications de son choix, je veux juste que cela ne se fige pas !

— peoro

6

Je veux dire, je pense sérieusement à l' exécution d' un script comme celui - ci (en pseudocode): while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. Cela réglerait définitivement mon problème. Mais attendez, le noyau n’est-il pas supposé le faire (et de manière bien meilleure que mon script)? Pourquoi ne fait-il pas son travail?

— peoro

2

@Marcin, cela ne ferait que déplacer le problème, ne le résoudra pas. Même si j'avais 4 Go de mémoire (grâce à un échange), mon système pourrait manquer de mémoire (donc en attente). Ce que je veux éviter, c'est que mon système se bloque lorsqu'il manque de RAM. Si mon noyau venait à tuer subitement le chrome dès que ma RAM est terminée, je serais heureux même avec le 1 Go que j'ai maintenant.

— peoro

4

@Lee Le "sysrq magique" est un combo clé qui va directement au noyau. Cela fonctionnera souvent même si le clavier et la souris ne répondent pas. Voir en.wikipedia.org/wiki/Magic_SysRq_key

— Raman

14

Il est possible d’appeler directement OOM-killer (à court de mémoire) en utilisant une combinaison de touches:

SysRq-F

La touche SysRq est généralement combinée à la touche PrtSc sur les claviers.

OOM-Killer tue certains processus (-es) et le système redevient réactif.

Thx Raman pour des conseils sur cette fonctionnalité dans les commentaires ci-dessus.

PS: Cela m'a beaucoup aidé. Je suis d’accord avec l’opinion que c’est le conseil le plus utile concernant ce problème s’il est causé par Chrome ou par un logiciel gourmand en mémoire. Mais vous devez garder à l’esprit que le tueur OOM peut tuer un processus très important, utilisez-le avec précaution.

— Arkemlar
source

2

J'ai la clé PrtScn|SysRq. Mais presser SysRq - Fne donne qu'une capture d'écran

— Lee

2

Puisque vous avez essentiellement pris mon commentaire ci-dessus et en avez fait une réponse, une petite attribution aurait été bien. Je t'ai quand même voté. :-)

— Raman

3

@Lee Vous devez l'activer. Certaines distributions ne disposent pas de sysrq magique activé par défaut. Cela devrait aider: google.ca/search?q=sysrq+enable

— Raman

2

@Raman Je parie que 99% des personnes interrogées trouvent que cela ne peut pas "l'activer" par défaut car leur ordinateur est déjà gelé ... Pourquoi n'est-il pas activé par défaut?

— themihai

3

@themihai parce que beaucoup de gens le considèrent comme un risque pour la sécurité - cela vous donne un accès direct au noyau via un accès physique à un périphérique d'entrée, quel que soit l'état de l'application, par exemple les écrans de verrouillage, etc.

— Raman

12

L'état naturel des choses est que les données de l'application sont dans la RAM et les fichiers sur le disque.
En termes de performances, l’état idéal des choses est que les données fréquemment utilisées se trouvent dans la RAM et que les données inutiles pour le moment se trouvent sur le disque.
Sur un système normal, le noyau fait deux choses pour tenter d'atteindre cet idéal:

Les données d'application qui n'ont pas été utilisées pendant un certain temps peuvent être déplacées sur le disque: il s'agit d'un échange.
Les données des fichiers récemment utilisés sont conservées dans la RAM: il s'agit du cache de disque (pour les données lues à partir du disque) et des tampons de disque (pour les données sur le point d'être écrites sur le disque).

Sur un système typique, une partie importante de la RAM est consacrée au cache et aux mémoires tampons (50% est un chiffre typique). La RAM étant une ressource finie, il peut être nécessaire de déplacer certaines données d'application pour les échanger (l'échange n'est nécessaire que s'il existe un meilleur moyen d'utiliser la RAM).

Sur un système sans échange, il arrive un moment où les données de l'application utilisent presque toute la RAM, il ne reste donc presque plus de place pour le cache. Ensuite, le système est susceptible d'être lent. Le noyau ne commencera pas à tuer les applications tant qu'il ne le sera pas. Tant que les applications ne remplissent que 99% de la mémoire disponible, le système continue à fonctionner, mais très lentement, car les données des fichiers doivent être chargées et rechargées à partir du disque en permanence. Avec les mêmes applications en cours d'exécution, le système serait plus rapide avec le swap à ce stade.

Pour plus d'informations sur cette question, voir cette discussion de Lkml et cet article de blog .

Je ne connais pas de moyen direct pour dire au noyau de réserver une quantité minimale de RAM pour le cache de disque. Vous pouvez configurer une petite partie de votre RAM en tant qu'espace de permutation , peut-être même compressé . Il existe des rapports de réussite sur ce front , bien que je ne fasse aucune garantie dans votre cas particulier.

— Gilles, arrête de faire le mal
source

1

Merci pour l'explication et les liens, ils ont permis de dissiper certains doutes sur l'échange. Après la réponse de @Marcin à ma question, j’ai mis en place 256 Mo d’échange virtuel compressé (compcache) dans ma mémoire vive. Cela ne répond toutefois pas complètement à ma question: je comprends que mon système sera lent lorsque toute la mémoire RAM n’est utilisée que par l’application et que rien n’est mis en cache; Je ne comprends toujours pas pourquoi ce système s'interrompt quelques minutes / heures (peut-être pour toujours?) Alors que je n'ai plus de RAM. Je pense que mon noyau ne fait pas son travail pour tuer les applications lorsqu'il manque de mémoire, si 3 heures ne suffisent pas pour passer à TTY1.

— peoro

J'ai désactivé ma mémoire physique avec 32 Go de mémoire désactivée et lorsqu'un logiciel nuisible s'emballe (bonjour ld, déchet), il reste suspendu pendant presque une minute, me réveillant juste assez pour me permettre de déplacer la souris incroyablement lente pendant une seconde. ou deux toutes les plusieurs secondes. La gestion des MOO par Linux est une merde complète Si j'ai de la chance, le tueur OOM tue le bon processus sans vider complètement l'environnement de bureau. Et je suis un grand fan de Linux. C'est bien pire avec la pagination activée. La pagination Linux est une blague.

— Doug65536

6

Ce bogue est connu depuis 2007 - voir Gel du système pour une utilisation intensive de la mémoire .

Dans cette situation, Windows affiche une boîte de dialogue demandant à l'utilisateur de fermer une ou plusieurs applications.

— Dan Dascalescu
source

2

Semble être "non assigné" dans Ubuntu. Peut-être que le DE devrait avertir l'utilisateur ou même geler l'application gourmande en mémoire?

— nkkollaw

1

@ nbrogi - tout sauf le gel silencieux. Mais bonne chance pour convaincre les développeurs Ubuntu de le faire.

— Dan Dascalescu

6

Récemment, j'ai trouvé une solution à mon problème.

Le tueur de MOO Linux n'étant pas en mesure de faire son travail correctement, j'ai commencé à utiliser un tueur de MOO en espace utilisateur: earlyoom . C'est écrit en C, assez configurable et ça marche comme un charme pour moi.

J'ai aussi entendu parler de certaines alternatives, comme celle de Facebook, OOMD , développée pour fonctionner sur leurs serveurs, mais je n'ai pas essayé celui-ci.

— peoro
source