Discussion :

[destroyedlolo]

Mouai, j'ai des machines avec seulement 512 Mo qui fonctionnent très bien avec LXDE et sans bouffer de la swap (évidement, il ne faut pas vouloir ouvrir 15 000 pages dans firefox).
Je suis meme décendu a 128 Mo mais uniquement pour du web en remplacant FF par Midori avec toutes les limitations que ca implique.
Le tout sous Gentoo.

Pour testé, je suis meme descendu a 64 Mo avec l'excellent TinyCoreLinux et leur site annonce même pouvoir décendre a 16 Mo

Par contre, le problème de swap est bien réel et pas uniquement limité aux desktop : certaines compilation en C++ ont des besoins vraiment gargantuesque en mémoire.
Pour le desktop, la solution serait d'interdire a certains process cruciaux d'etre swapper pour garantir des temps de réponses immédiats ...

[Neckara]

Dans ce cas, tu paramètres le fichier /etc/security/limits.conf pour fixer les limites que tu souhaites par utilisateur ou groupe.

Je n'ai aucune idée de la quantité de mémoire à allouer à chaque utilisateur/groupe (il y en a 44 et 74 sur ma machine). Ce que je souhaite, c'est qu'en toutes circonstances qu'il me reste assez de ram pour utiliser un terminal et killer le processus fautif. D'autant plus que cela reviendrait soit à réserver une "partie" de ma ram à chaque utilisateur/groupe, or il vaut mieux "partager" la ram : un processus pouvant avoir besoin de plus de ram à un moment donné et inversement.


Pour les groupes, en effet la limite semble s'appliquer aussi aux groupes secondaires. En revanche, cela signifie d'assigner à chaque utilisateur un groupe qu'on aura créé pour l'occasion. Le problème étant alors de tenir ce groupe à jour en cas de création de nouveaux utilisateurs (qui peuvent se faire e.g. à l'installation/mise à jour d'un paquet).

Je pense que c'est la même problématique avec cgroup. D'ailleurs dans le cas d'un groupe d'utilisateur, lequel serait le plus adapté ? cgroup ou ulimit ?



Un autre problème, est le compte root qui va aussi potentiellement lancer des process qui consomment de la ram et qui sont inutiles à l'ouverture d'un terminal avec ctrl+Alt+F1.

Franchement, plus j'y pense, moins le problème semble simple si on veut le résoudre proprement. ulimit/cgroup, si bien configuré pourra réduire le risque de manière significative, mais n'offrira aucune garantie qu'en toutes circonstances il y aura suffisamment de ram pour un terminal. Peut-être est-il possible de faire l'inverse ? Plutôt que de limiter la consommation de ram des autres utilisateurs/groupes, réserver explicitement une partie de la ram pour l'utilisateur/processus qui permettra de lancer un terminal pour tuer d'autres processus ?

[chrtophe]

Peut-être est-il possible de faire l'inverse ? Plutôt que de limiter la consommation de ram des autres utilisateurs/groupes, réserver explicitement une partie de la ram pour l'utilisateur/processus qui permettra de lancer un terminal pour tuer d'autres processus ?

C'est le cas pour l'espace disque, 5% est réservé à root. Pour la RAM, il n'y a pas de RAM réservé à root, du moins à ma connaissance. Par contre, il y a un watchdog qui kille des process en cas de manque de mémoire :
https://www.kernel.org/doc/gorman/ht...rstand016.html

Mais le process killé est choisi par l'algorithme.

[Steinvikel]

Mais le process killé est choisi par l'algorithme.

Dommage que l'on ne puisse pas établir de liste noire des process "connu" à kill de préférence avant les autres... à l'image des listes blanche /noire des site web à filtrer.

[Neckara]

Par contre, il y a un watchdog qui kille des process en cas de manque de mémoire :
https://www.kernel.org/doc/gorman/ht...rstand016.html

N'est-ce pas OOM_killer dont SofEvans parlait ?

[chrtophe]

oui c'est ça. Ca fait partie du noyau.

[AndMax]

Je suis toujours assez loin de saturer la mémoire sur ma machine (8Go). Ma femme par contre (sur son portable qui a également 8Go de RAM) a réussi à atteindre plusieurs fois le point où la souris ne bouge plus. Maintenant elle connaît le truc: ouvrir un terminal Ctrl+Alt+F1 et tuer Firefox avec top. Pourtant comme elle, j'ai aussi tendance à ouvrir beaucoup d'onglets. La principale différence, c'est que j'utilise NoScript, elle non. Vous n'imaginez pas à quel point les sites web sont devenus gourmands en RAM (et parfois en CPU) si vous laissez tourner tous les scripts qui sont proposés sur les pages. Bref uBlock Origin n'est pas suffisant pour éliminer toutes les nuisances. Par contre, NoScript n'est pas vraiment adapté pour les non-geeks. Paramétrer au cas par cas les sites qui ont droit à exécuter des choses est perçu comme quelque chose de chiant pour la majorité des gens, surtout sur des sites qui ont besoin d'exécuter des scripts sur 10 noms de domaines différents pour pouvoir commencer à fonctionner.

Pour en revenir au sujet: je suis d'accord avec les gens qui pensent qu'il devrait être plus facile de tuer le processus qui a tout saturé. Ctrl+Alt+F1 marche très bien, et pour moi perso ça va très bien, mais ce n'est pas intuitif, pas très user friendly. En attendant, je vais peut-être lui proposer d'afficher un petit graphique avec la RAM disponible dans sa barre des tâches.

[Neckara]

Ctrl+Alt+F1 marche très bien, et pour moi perso ça va très bien, mais ce n'est pas intuitif, pas très user friendly.

Tu en as de la chance, moi ça bloque tellement que je ne peux même pas m'authentifier .

[rockinpenguin]

Ca fait déjà longtemps en effet que ce monsieur tient un billet de blog qu'il met régulièrement à jour : https://itvision.altervista.org/why....p.current.html
J'ai toujours été très en accord avec ce qu'il pointe : l'autocritique, la remise en question est indispensable pour qui veut s'améliorer.
Toujours rejeter la faute (sur la concurrence, sur l'utilisateur...) permet peut être de se donner une bonne conscience, ou encore d'éviter de heurter sa propre fierté, mais ce n'est pas ça qui permet d'avancer.

[chrtophe]

Dans le lien fourni ci-dessus, il y a quand-même des affirmations fausses et d'autres à vérifier.