Artem S. Tashkinov est connu sur la toile pour ses publications pour certaines très controversées. Par exemple, la question de savoir pourquoi Linux ne connaît pas de succès sur le desktop comme Windows continue de faire couler beaucoup d’encre. Il y a deux ans, il s’est exprimé sur celle-ci et a dressé SA liste de raisons pour lesquelles ça ne le fait pas pour Linux dans cette filière. L’une des pistes qu’il arrive que des tiers explore est qu’il en est ainsi parce que Microsoft tient d’une façon ou d’une autre les fabricants de matériel. Artem S. Tashkinov s’était inscrit en faux et avait plutôt souligné que c’est la communauté elle-même qui plombe le succès de l’OS sur le desktop.
Dans une publication parue il y a peu sur la liste de diffusion de mail du noyau Linux, il indique que l’OS est mauvais au jeu de la gestion de faibles quantités de mémoire vive. « Lorsqu’une tâche requiert plus de mémoire vive que disponible, le système se bloque au point où il devient impossible de déplacer le pointeur de la souris. La DEL du disque dur se met à clignoter de façon incessante. De plus, il devient impossible de lancer de nouvelles applications ou d’arrêter celles en cours de fonctionnement. Je pense que ce n’est pas de cette façon que le système doit se comporter dans de telles situations », indique-t-il avant d’ajouter que « c’est un bogue qui affecte de nombreux utilisateurs du système d’exploitation depuis plusieurs années et qui est reproductible en moins de quelques minutes sur la dernière version du noyau. »
Artem propose à ceux désireux de faire le même constat que lui de passer par trois étapes : limiter à l’aide d’une commande la quantité de mémoire vive disponible sur le système à 4 Go, désactiver l’espace d’échange (swap) pour accélérer le processus, lancer un navigateur et ouvrir autant de pages que possible. Plus que tout dans ce développement, c’est même la nécessité de la mise sur pied d’un espace d’échange qui est à questionner. En effet, la nécessité de simuler un supplément de mémoire vive sur disque laisse filtrer que c’est l’approche Linux pour anticiper sur les cas où la ressource mémoire vive peut être insuffisante. C’est une solution, mais le développement d’Artem suggère qu’il faut améliorer le kernel de sorte qu’il ne soit même pas nécessaire de faire usage d’espace d’échange. En tout cas, même avec l’espace d’échange actif, il arrive de constater sous certaines distributions que le système plante au point où il devient impossible de déplacer la souris, de lancer de nouvelles applications ou d’arrêter celles en cours de fonctionnement.
En sus, il y a que l’usage de l’espace d’échange présente moins d’intérêt dans certains cas de figure. En effet, il ne faut pas perdre de vue que la multiplication des accès à cet espace peuvent raccourcir la durée de vie du support de stockage de masse. Ainsi, dans des situations où l’on décide de ne pas en faire usage, il faut que le système puisse tenir la route.
Il y a quelques années, un internaute qui répond au pseudonyme Hackerman1 a gratifié Microsoft d’une grosse publicité en publiant une capture d’écran de l’installation de la RC1 de Windows 7 sur un PC doté d'un Pentium II à 266 MHz et de seulement 96 Mo de mémoire vive.
Ce qu’il faut dire c’est que de tels « exploits » ne sont possibles que parce que l’approche swap n’est pas exclusive à Linux. Oui, les systèmes d’exploitation de Microsoft s’appuient eux aussi sur un espace d’échange.
Ce n'est pas spécifique à Linux. C'est spécifique à ce qu'on fait. Maintenant tout le monde code des nouvelles applications en electron qui nécessitent une quantité astronomique de RAM. Moi j'arrive à faire tourner mon système sous 3Go de ram sans aucun problème. Il suffit de choisir les bons outils.
Je dois avouer que cela m'arrive un peu trop fréquemment, même avec 8Go ou 16Go de ram, je suis passé à 32Go pour être tranquille.
Le problème est que certaines applications peuvent avoir des fuites de mémoires, ou être très consommatrices si on lance plusieurs instances.
Sauf que lorsque cela m'arrive, je ne peux pas tout simplement tuer le processus responsable et je suis obligé de redémarrer le système.
Une solution serait de réserver une petite quantité de RAM au système (e.g. 40Mo - je donne un chiffre au hasard), pour au moins avoir un terminale disponible (e.g. via Crtl+Alt+F1). Une autre plus intéressante serait de refuser l'allocation aux applications non-prioritaires si cette allocation fait que la quantité de ram restante se retrouve en deçà d'un certain seuil. À l'application ensuite de se démerder (e.g. afficher une erreur).
Possesseur d'un asus x205ta (2gb de ram, processeur intel patate, Xubuntu 18.04), j'arrive à faire tourner en simultané IntelliJ IDEA, Tomcat, Chrome avec 5-6 onglets et un terminal.
Alors oui c'est pas le truc le plus rapide du monde et parfois il ralenti bien mais au moins il crash pas et revient à la normal après un petit temps, ce qui je trouve est plutôt un bon comportement.
Faut que le monsieur revoit l'usage de son ordinateur..
Pour le coup c'est vraiment n'importe quoi. Par ex,des Raspberry Pi tournent de manière très fluide avec 512 ou 1GO de RAM je n'ai jamais eu de problème.
Après c'est évident que si tu as 2GO de RAM et que tu veux faire tourner des applications a 4GO de RAM tu vas avoir des problèmes, mais bon... Clairement, il existe des alternatives légères à quasiment toutes les applications sous Linux donc tu peux t'en sortir même avec une petite quantité de RAM.
Ce développeur râle mais ne propose rien de concret pour limiter ce problème... Donc son témoignage n'a pas spécialement de valeur... Pour moi, c'est encore un random qui veut lancer un débat de comptoir pour faire parler de lui.
D'ailleurs, Windows n'est pas spécialement meilleur en terme de gestion de mémoire...
Je fais tourner des VM Linux avec 512 Mo de RAM. Elles répondent très bien.
Et Ulimit par exemple c'est pour les chiens ? Après si on travaille avec une interface graphique en root, ce qui est déconseillé.
Je ne connais pas l'auteur, il est dit qu'il est familier des publications controversées mais pas si il a des compétences ou si c'est un développeur de noyau.
ulimit n'est pas fait pour limiter les capacités d'un process en particulier mais d'un utilisateur/une session. Par contre ça doit être faisable avec les cgroups.
Sous Windos, tant que le ctrl-alt-suppr fonctionne, tu peux arriver à t'en sortir, sinon c'est mort. Sous Linux, tu dois pouvoir ouvrir une autre console en root pour killer le process incriminé, résultat non garanti si ta GUI tourne en root, mais KDE et Gnome ne te le permettent pas par défaut.
Windows founi une fonction dans son API : SetProcessWorkingSetSize, encore faut il que les applis l'utilisent. Sous windows Server, il y avait Windows System Resource Manager mais qui est maintenant déprécié.
Dans les deux cas (Windows et Linux), tu peux récupérer la main mais pas tout le temps.
La moitié des reponses ci-dessus disent que Linux tourne bien sur de petites configs. Je ne pense pas que ce soit le sujet du bug.
Le sujet du bug, c'est lorsque la mémoire vive est saturé: le système devient incontrolable, là où il devrait au pire tuer des applications.
D'ailleurs, dans le message original LKML, Artem désactive la zone swap et se demande du pourquoi de l'affolement de son disque dur (et il a raison: sans swap, pourquoi le disque se mets a tourner lorsque le système est OOM?)
il y a les cgroup sous linux pour limiter cpu, ram ... par processus...
Sauf qu'on aimerait bien que ce soit fait de base plutôt que d'avoir à s'enquiquiner avec.
D'autant plus que ce n'est pas la première chose à laquelle on pense quand on installe un système, i.e. il faut déjà que cela nous arrive 3-4 fois pour qu'on commence à penser à utiliser les cgroup. Sachant que cela demande de passer du temps à se pencher sur la question, surtout quand on n'est pas familier avec les cgroup.
L'os qui se fige quand trop de ram a été consommé ça me les brise. (...) sur Windows cela ne se comporte pas de cette façon : ca fige, ca te rend la main, tu tues le processus en question et/ou tu kill les applis qui consomment trop. Sur Linux même ma souris ne bouge plus dans ce cas : redémarrage forcé obligé.
Nous semblons ne pas avoir été confrontés aux mêmes problèmes sur Windows... un écran bleu, un écran de bureau (avec ou sans fenêtre) figé sans la main sur la souris ni les raccourcis clavier (dont ctrl-alt-suppr)... Les dépassement de RAM (et de swap dynamique) ça a été mon dada sur Windows il fut un temps (j'ai pu vérifier que cela n'avait strictement pas changé d'un Yotta sur Windows 10 --> déversement swap en boucle : accès disque à 100% (principalement en lecture) + forte charge du CPU directement corrélé à l'utilisation disque. attendre 10min ou 24h n'y change rien (ça lui laisse juste plus de chance de planter).
Moi, ce qui me les brises, c'est que tu as beau avoir 1Go ou 128 Go de RAM physique, Windows va toujours utiliser une partie de la swap en "prévoyance", quand bien même je n'utilise que 50% actuellement... et ce comportement n'est pas paramétrable via un seuil dans les réglages sytèmes via GUI.
Envoyé par chrtophe
Sous Windows, tant que le ctrl-alt-suppr fonctionne, tu peux arriver à t'en sortir, sinon c'est mort.
Sous Linux, tu dois pouvoir ouvrir une autre console en root pour killer le process incriminé, résultat non garanti si ta GUI tourne en root, mais KDE et Gnome ne te le permettent pas par défaut.
(...) Dans les deux cas (Windows et Linux), tu peux récupérer la main mais pas tout le temps.
Si c'est uniquement pour débugger la machine, je t'invite à oublier ctrl-alt-suppr et d'utiliser plutôt ctrl-shift-esc qui à l'avantage de ne pas s'appuyer sur la souris pour arriver au gestionnaire de tâches.
Ensuite, il me semble que sur Windows comme sur Linux il y a des Magic key (ex: Magic SysRq key), qui sont des interruptions hardwares pour prendre la main sur l'OS. Les ports PS/2 présentent l'avantage sur l'USB de présenter une priorité d'interruption plus élevé. Amis gamers et dépanneurs... ; )
--> on peut interrompre le processus de boot du BIOS en appuyant sur 'Pause', et le relancer en appuyant à nouveau.
J'ai trouvé une petite vidéo qui semble plutôt bien rentrer dans le sujet (je l'ai visionné en diagonale)
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 ...
Artem S. Tashkinov est connu sur la toile pour ses publications pour certaines très controversées. Par exemple, la question de savoir pourquoi Linux ne connaît pas de succès sur le desktop comme Windows continue de faire couler beaucoup d’encre. Il y a deux ans, il s’est exprimé sur celle-ci et a dressé SA liste de raisons pour lesquelles ça ne le fait pas pour Linux dans cette filière. L’une des pistes qu’il arrive que des tiers explore est qu’il en est ainsi parce que Microsoft tient d’une façon ou d’une autre les fabricants de matériel. Artem S. Tashkinov s’était inscrit en faux et avait plutôt souligné que c’est la communauté elle-même qui plombe le succès de l’OS sur le desktop. 
Qu’en pensez-vous ? 
Envoyé par marc.collin
