Donc si tu as un processus qui utilise tout ton CPU en permanence aucun mécanisme n'existe pour le tuer.
Quand on a que ce problème-là, on ne perd pas la main.
Quand on n’arrive plus à reprendre la main sur le système, c’est parce qu’il swappe à mort. J’ai parfois le même cas que lejocelyn sur une bécane qui n’a que 4 Go.
Il fut pourtant un temps où ça ne faisait pas ça. Je me demande si c’est Linux qui gère moins bien le coup, ou les conditions qui se sont dégradées : un seul processus, celui du navigateur (quel qu’il soit ; j’ai essayé avec plusieurs, quand certaines pages pourries font exploser leur consommation de ressources, j’en arrive toujours à la même situation), qui bouffe plus que la mémoire physique à lui tout seul, alors qu’à l’époque, c’était seulement l’ensemble des processus qui dépassait.
J’ai essayé plus ou moins de swap, sans réussir à éviter complètement la situation (mieux vaut quand même qu’il n’y en ait pas trop, mais si on veut pouvoir mettre le système en hibernation, il en faut malheureusement au moins autant que de mémoire physique).
Même sans swap du tout, comme le fait remarquer Chris Down au point 6 dans le lien posté plus haut par kna, le manque de buffer fait écrouler les performances en écriture de fichiers et la situation est similaire. Tout au plus le manque de mémoire déclenche-t-il l’OOM killer plus tôt.
J’ai bien trouvé une solution pour éviter cette situation : lancer le navigateur avec ulimit -v une taille plus petite que la mémoire physique (genre ulimit -v 3000000 firefox &), mais ça se traduit, au moins pour Firefox, par un plantage très sale quand il n’a plus de mémoire. Pas idéal si l’on est en train de faire quelque chose d’important avec (et comme il y a de plus en plus de choses qu’on fait sur le web)...
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mémoire ?
Posté par Arthur Accroc . En réponse à la dépêche Sortie du noyau Linux 5.0. Évalué à 8.
Quand on a que ce problème-là, on ne perd pas la main.
Quand on n’arrive plus à reprendre la main sur le système, c’est parce qu’il swappe à mort. J’ai parfois le même cas que lejocelyn sur une bécane qui n’a que 4 Go.
Il fut pourtant un temps où ça ne faisait pas ça. Je me demande si c’est Linux qui gère moins bien le coup, ou les conditions qui se sont dégradées : un seul processus, celui du navigateur (quel qu’il soit ; j’ai essayé avec plusieurs, quand certaines pages pourries font exploser leur consommation de ressources, j’en arrive toujours à la même situation), qui bouffe plus que la mémoire physique à lui tout seul, alors qu’à l’époque, c’était seulement l’ensemble des processus qui dépassait.
J’ai essayé plus ou moins de swap, sans réussir à éviter complètement la situation (mieux vaut quand même qu’il n’y en ait pas trop, mais si on veut pouvoir mettre le système en hibernation, il en faut malheureusement au moins autant que de mémoire physique).
Même sans swap du tout, comme le fait remarquer Chris Down au point 6 dans le lien posté plus haut par kna, le manque de buffer fait écrouler les performances en écriture de fichiers et la situation est similaire. Tout au plus le manque de mémoire déclenche-t-il l’OOM killer plus tôt.
J’ai bien trouvé une solution pour éviter cette situation : lancer le navigateur avec
ulimit -vune taille plus petite que la mémoire physique (genreulimit -v 3000000 firefox &), mais ça se traduit, au moins pour Firefox, par un plantage très sale quand il n’a plus de mémoire. Pas idéal si l’on est en train de faire quelque chose d’important avec (et comme il y a de plus en plus de choses qu’on fait sur le web)...« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone