Oui, c'est une vaste question, mais je dirais que c'est une question tout à fait valable. Parfois, les programmes et les scripts prennent trop de temps ou utilisent trop de mémoire et commencent vraiment à ralentir mon système. Bien. Parfois, le système ralentit tellement que je peux à peine glisser ma souris vers le terminal et le spam. Ctrl + C . Cela me laisse perplexe sur la raison pour laquelle un système d'exploitation ne donne pas la priorité de planification pour permettre à l'utilisateur d'utiliser la souris, le clavier et de tuer des objets. Jamais vu ça?
> ./program
^C^C^C^C^C^C^C^C^C^C^C^Z^Z^Z^C^C^C^C^C^Clsdhafjkasdf
À présent, Ctrl + C n'est pas aussi sévère que d'autres (cela peut être géré par l'application et même ignoré, mais ce n'est pas le cas ici). Ctrl + Z ferait le travail très bien aussi que je serais en mesure de kill -9 %1 juste après mais ça ne marche pas non plus.
Une autre méthode peut être de passer à une console virtuelle Ctrl + Alt + F2 , connectez-vous et supprimez l’application incriminée, mais comme le système est occupé, cela ne fonctionne pas et j’obtiens un écran noir. De même, je ne peux pas ouvrir de nouveaux terminaux (la fenêtre s’ouvre mais ne parvient pas à me déposer dans un shell). Les autres terminaux ouverts peuvent ne pas répondre ou exécuter des commandes.
Je soupçonne une des raisons pour lesquelles le système est si inutilisable, c'est que le programme en cause utilise la permutation et repousse les applications les plus essentielles de la mémoire principale. Même la commande la plus simple pour me donner une invite bash ou exécuter kill ne peut obtenir un cycle dans les bords. Je n'ai aucune preuve de cela parce que je ne peux pas courir top quand ça arrive. Y at-il des options pour améliorer les chances de l'original Ctrl + C travail? . Peut-être que quelque chose dans le sens d'une augmentation de la priorité de X et du terminal ou de la suppression automatique des programmes qui utilisent une grande partie de la mémoire ou qui commencent à trop permuter?
Existe-t-il un autre linux-fu que je pourrais utiliser pour reprendre le contrôle lorsque cela se produit (par exemple, SysRq commandes)?
Mettre à jour: Après quelques tests supplémentaires, je suis presque certain que ce sont les applications qui utilisent trop de mémoire et qui échangent. Même après avoir tué l'application en question, les autres mettent très longtemps à réagir, comme s'ils avaient été chassés de la mémoire principale. Je voudrais vraiment un moyen de limiter automatiquement les programmes d'utilisation de mémoire haute à la mémoire principale . Si cela se produit, il sera de toute façon trop lent, alors pourquoi le laisser continuer?
REMARQUE: je ne suis pas à la recherche d'une solution pour une application spécifique et je ne sais pas à l'avance quand une opération va détruire la mémoire. Je veux résoudre ce genre de ralentissement à l’échelle du système. C'est à dire. beaucoup de programmes causent ceci. Autant que je sache, la configuration du système ne me concerne pas et il s’agit d’une installation plutôt standard de Fedora. Je ne suis pas surpris par ces ralentissements, mais je veux plus de contrôle.
Je voudrais laisser mon gestionnaire de fenêtres en cours d'exécution et ce sont mes dernières stations que j'espère éviter. Je n'ai généralement besoin de ceux-ci que si mon GPU est bloqué dans une boucle et bloque X. Si activé , Ctrl + Alt + retour arrière est un raccourci pratique pour tuer X et toutes vos applications, vous ramenant à la connexion. Une commande encore plus puissante si activé , est Alt + SysRq + K . Si cela ne fonctionne pas, maintenez l'heure du bouton d'alimentation.
Alt + SysRq + F (merci, @Hastur), qui tue les processus mémorisants en mémoire est assez destructif mais peut aider en dernier recours.
Mise à jour: Pas tout à fait sûr de toutes les conséquences ici, mais suggestion de @ Xen2050 de ulimit semble résoudre beaucoup de problèmes ...
TOTAL_PHYSICAL_MEMORY=$(grep MemTotal /proc/meminfo | awk '{print $2}')
ulimit -Sv $(( $TOTAL_PHYSICAL_MEMORY * 4 / 8))
Je vais laisser ça dans mon dossier et voir comment les choses se passent.
Mise à jour: les choses semblent généralement bonnes, sauf que je suppose que certaines applications partagent de grandes bibliothèques et mappent des fichiers volumineux. Même s'ils ne consomment quasiment pas de mémoire et qu'il est peu probable qu'ils soient fréquemment échangés. Il ne semble pas y avoir un nombre assez bas pour tuer des applications mortelles frappant le swap, mais laisser des applications régulières (comme 4.6gb VIRT amarok ) fonctionnement.
En relation: https://unix.stackexchange.com/questions/134414/how-to-limit-the-total-resources-memory-of-a-process-and-its-children/174894 , mais toujours le problème de la limitation des applications qui commencent à frapper beaucoup swap.
C'est exactement la bonne solution, il s'avère que je suis après: Est-il possible de faire intervenir le tueur OOM plus tôt?
kde2d dans R ce qui s’avère être très lent avec de grands ensembles de données (je n’en avais aucune idée mais je peux certainement dire que je le fais maintenant). Ce problème d'ordre général, récurrent, ne concerne pas une tâche ou une application spécifique. J'ai eu des problèmes similaires avec les filtres dans Gimp, les grosses simulations de corps rigides dans Blender, les applications CUDA, l'ouverture accidentelle de fichiers binaires dans les éditeurs de texte, etc.
nice -n 19avant? Bien sûr, si vous avez besoin de plus de priorité, vous pouvez essayer par exemple. avec -n 15 ... BTW je savaisALT+SysRq+ une des lettres suivantes: +Rprendre le contrôle de X, +Spour synchroniser, +Eterminer tout gracieusement , +Ituer brusquement, +Uremonter en lecture seule les systèmes de fichiers et +Rredémarrer. + k je ne savais pas ...