Pourquoi un système peut-il ne plus répondre?

Je viens d'exécuter dot(un programme pour dessiner des graphiques dirigés) avec un fichier d'entrée qui était si gros qu'il ne pouvait pas être rendu dans un délai raisonnable.

Tout mon système s'est figé. Je pouvais à peine atteindre une console texte avec Ctrl+ Alt+ F1pour tuer dot, mais cela a pris plusieurs minutes.

Pourquoi le système permet-il quelque chose comme ça? Pourquoi donne-t-il un programme non critique tel que dot99% du système et utilise-t-il les 1% restants pour rester réactif?

scheduling

— Christoph Wurm
source

Copie possible d'E / S disque lourd unix.stackexchange.com/questions/5565/… et unix.stackexchange.com/questions/11/…

— George M

C'est ainsi que GNU / Linux et d'autres systèmes multitâches fonctionnent, ils partagent le processeur entre les processus en cours d'exécution, dotn'auront pas 99%, mais 100% pendant 99% du temps. Chaque processus domine le processeur pendant une certaine période de temps.

Ceci est géré par les planificateurs (Linux a plusieurs planificateurs, certains utilisent simplement la stratégie habituelle, certains essaient de donner plus de temps aux interfaces utilisateur, etc.).

Maintenant, dans votre cas, le problème était - probablement - qui dotne prenait pas beaucoup de temps processeur, mais beaucoup de mémoire. Et quand un programme utilise trop de mémoire, il y a thrashing , qui est exactement un processus qui fait figer le système, non pas parce qu'il en dotfait beaucoup, mais parce que le noyau doit déplacer les pages mémoire entre le disque (partition de swap) et la mémoire système.

Même si cela dotne prenait que 99% du temps CPU, il est probable que le passage à un terminal texte soit presque immédiat, ce qui se passe est que le noyau doit déplacer des dotéléments hors de la mémoire afin qu'il puisse les remettre Xen mémoire afin de Xpouvoir voir les clés vous venez de frapper et de vous déplacer vers le terminal texte, puis le noyau doit Xsortir de la mémoire pour dotlaquelle il est toujours en cours d'exécution, puis dotsortir pour déplacer les processus du terminal texte (peut-être juste login?) en mémoire. (Si ce semble désordonnée, ce n'est pas seulement parce que l'exemple est en désordre - la réalité est ce . Désordre)

Un exemple est que si vous vous connectez au terminal texte, vous pourrez peut-être simplement appuyer sur des touches, appuyer sur la touche de retour arrière, et cela se fera avec plaisir en temps réel, mais si vous faites quelque chose d'aussi simple que d'exécuter un petit outil comme ps, il "gèlera" "pendant un certain temps car il doit libérer de la mémoire pour se charger ps(et il doit également attendre dans la file d'attente d'E / S disque, qui est largement utilisée pour déplacer des données vers et depuis la mémoire, jusqu'à ce qu'il soit en mesure de demander psau système de fichiers) .

— njsg
source

Hm, donc le moyen d'une meilleure expérience utilisateur serait de spécifier certains programmes comme " collants " et donc d'empêcher leur permutation.

— Christoph Wurm

L'adhérence n'a pas fonctionné comme ça depuis les années 70 et la sémantique originale du bit «collant». Vous pouvez cependant verrouiller (des parties de) des programmes en mémoire afin qu'ils ne puissent pas être échangés. La mémoire principale est un luxe cher, donc cela ne peut pas être fait pour tout.

— Alexios

@njsg, merci pour la bonne explication. Une question de suivi: n'y a-t-il aucun moyen d'empêcher la raclée? Je comprends que l'échange permette de rendre l'utilisation de la mémoire plus efficace dans l'ensemble, mais il devrait y avoir des limites. À mon humble avis, un processus aussi essentiel que X ne doit jamais être retiré de la mémoire. Existe-t-il un moyen de configurer un système de type Unix de telle sorte que les processus essentiels soient protégés contre la sortie? Sur un serveur, c'est quelque chose de différent, mais sur un ordinateur de bureau, je préfère avoir un processus gourmand en mémoire pour planter plutôt que de laisser mon ordinateur de bureau me parler.

— A. Donda