Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
Il y a pas plus ou moins décorrélation entre le code propre et lisible et l’optimisation de l’utilisation des ressources de la machine ? A moins d’avoir des compilos super forts (ce qui est de plus en plus le cas) optimiser le code nécessite souvent de le complexifier ou d’utiliser des algos plus malins mais pas forcément plus lisibles ou compréhensibles pour autant.
A moins d'avoir des développeurs super forts (ou d'aimer les régressions), optimiser le code nécessite de le comprendre et de pouvoir faire des changements profonds sans avoir peur de tout casser.
Ce n'est pas parce qu'un algorithme est complexe que le code doit être illisible. Il doit être possible d'écrire les choses de façon modulaire et réutilisable, ce qui permet en plus d'appliquer le même algorithme (ou quelques morceaux) pour optimiser d'autres choses.
C'est très pénible (mais pas impossible) à faire en C, et plus confortable en C++ (pas de commentaire sur les autres langages que je ne connaît pas assez bien pour en juger).
Si ton code est un tas de spaghetti, tu ne peux pas le modifier facilement pour le rendre plus efficace. S'il est propre et bien architecturé, tu peux remplacer une structure de données ou un algorithme sans devoir tout remettre en question.
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
Oui et non.
Ça arrive quand ton OS ne peut plus gérer le bloat que tu fais tourner, il n'y a juste pas assez de ressources.
Alors oui, bien sûr, choisir quel processus tuer, et définir des priorités, c'est mieux.
Mais ce qui est vraiment bien c'est aussi de mieux gérer ton serveur et de ne pas surplomber sa RAM ET son SWAP.
Si t'en arrives là sur un serveur que tu gères, tu t'es peut-être trompé de métier, ou alors tu fais une erreur de jeunesse, tu t'excuses auprès des utilisateurs, boss, collègues, etc., et tu promets de ne plus jamais recommencer…
Si t'en arrives là sur ta machine perso, tu as dû te rendre compte depuis un bon moment déjà que ton SWAP est ultra-sollicité et que ta machine se traîne à mort, et tu devrais savoir quel programme est en train de partir en vrille, donc tu devrais pouvoir choisir toi-même quel programme fermer avant le OOM-killer.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
Mais sous Linux aussi malloc renvoie NULL quand il ne peut pas allouer la mémoire.
Et je suppose que la plupart des logiciels écrit à peu près correctement savent gérer la situation.
Donc l'OOM-killer il sert uniquement dans les autres cas.
Lesquels ? Sais pas vraiment, mais si je n'ai pas rencontré l'OOM-killer depuis plus de 15 ans, il doit bien y avoir une raison, genre c'est le dernier des derniers recours quand tout le reste à foiré.
Et franchement, si ton système en est là, flinguer au hasard est une technique qui en vaut bien une autre. L'alternative étant probablement un crash du kernel et donc un massacre de tous les processus.
Et après, il faudrait vraiment m'expliquer pourquoi ça vaudrait vraiment le coup de se fouler plus que ça pour ce cas tellement extrême que de toute façon le système est inutilisable depuis un moment ?
C'est pas l'OS le problème quand on en arrive là…
Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?
flinguer au hasard est une technique qui en vaut bien une autre
Euh, c'est pas vraiment au hasard, hein ?
Il flingue le process qui a le score le plus haut, score calculé en fonction de :
* la mémoire qu'il consomme, évidemment
* l'importance du process (s'il est lancé par root, le score diminue), pour éviter de tuer un processus critique
* le tuning éventuellement fait par l'adminsys
C'est du FUD.
Dommage, le fond de l'article soulève de vrais problèmes, mais ce genre d'attaques infondées, et de phrases à l'emporte-pièce, gâchent le propos.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Ça c'est parce que vous avez pas d'applications.
Désolé, hein, j'aime bien haiku, mais l'OS doit se débrouiller pour vivre avec des appli qui ne sont pas sympa. On ne serait pas passé à un modèle préemptif sinon.
Il faut comprendre que faire un truc bien et maintenir cette qualité au passage à l'échelle ça n'a presque rien avoir. Faire des dizaines de fois moins de choses qu'un autre et bien le faire, j'ai plus envi de dire que c'est bien heureux. Faire des choses en petits commité et bien les faire c'est aussi assez logique.
Qu'il soit possible de faire mieux, j'ai pas de doute, mais pas forcément bien mieux et pas sans de gros changements dans les organisations. Mais je me trompe peut être.
Si vous avez des solutions tout le monde sera heureux de les entendre. Il y a des gens qui paient des conf pour justement avoir ce genre d'info, il y a même des formations qui sont données (et bien chère). Sincèrement ceux qui ont des idées, n'hésitez pas à vous lancer vous gagnerez de l'argent et ferrez avancer vos idées (c'est une manière bien plus efficace de contribuer au monde au quel vous semblez aspirer) que de développer un truc dans son coin.
Personnellement je ne trouve pas ça "strictement" sans intérêt. Je trouve le passage ou il compare la taille d'un binaire à son utilité fallacieux.
Mais y a deux trois truc vrai. Le fait qu'on construit sur de l'existant un peu trop souvent sans penser dette technique. Qu'il y a des effets de mode/cycle: le cas YAML vs XML est un exemple très parlant. On aurait aussi pu citer protobuf vs ASN1, la "révolution agile, le TDD" dont les principes existaient déjà dans les années etc…
Je pense qu'il manque à pas mal d'ingénieur/informaticiens un bagage en histoire de l'informatique.
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 19 septembre 2018 à 09:16.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
[^] # Re: TL ; DR
Posté par matteli . Évalué à 10.
Et donc, quelle est la bonne pratique utilisée sur Haiku quand la ram et le swap sont pleins ?
[^] # Re: TL ; DR
Posté par Thomas Douillard . Évalué à 3.
Il y a pas plus ou moins décorrélation entre le code propre et lisible et l’optimisation de l’utilisation des ressources de la machine ? A moins d’avoir des compilos super forts (ce qui est de plus en plus le cas) optimiser le code nécessite souvent de le complexifier ou d’utiliser des algos plus malins mais pas forcément plus lisibles ou compréhensibles pour autant.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
A moins d'avoir des développeurs super forts (ou d'aimer les régressions), optimiser le code nécessite de le comprendre et de pouvoir faire des changements profonds sans avoir peur de tout casser.
Ce n'est pas parce qu'un algorithme est complexe que le code doit être illisible. Il doit être possible d'écrire les choses de façon modulaire et réutilisable, ce qui permet en plus d'appliquer le même algorithme (ou quelques morceaux) pour optimiser d'autres choses.
C'est très pénible (mais pas impossible) à faire en C, et plus confortable en C++ (pas de commentaire sur les autres langages que je ne connaît pas assez bien pour en juger).
Si ton code est un tas de spaghetti, tu ne peux pas le modifier facilement pour le rendre plus efficace. S'il est propre et bien architecturé, tu peux remplacer une structure de données ou un algorithme sans devoir tout remettre en question.
[^] # Re: TL ; DR
Posté par Yth (Mastodon) . Évalué à 9.
Oui et non.
Ça arrive quand ton OS ne peut plus gérer le bloat que tu fais tourner, il n'y a juste pas assez de ressources.
Alors oui, bien sûr, choisir quel processus tuer, et définir des priorités, c'est mieux.
Mais ce qui est vraiment bien c'est aussi de mieux gérer ton serveur et de ne pas surplomber sa RAM ET son SWAP.
Si t'en arrives là sur un serveur que tu gères, tu t'es peut-être trompé de métier, ou alors tu fais une erreur de jeunesse, tu t'excuses auprès des utilisateurs, boss, collègues, etc., et tu promets de ne plus jamais recommencer…
Si t'en arrives là sur ta machine perso, tu as dû te rendre compte depuis un bon moment déjà que ton SWAP est ultra-sollicité et que ta machine se traîne à mort, et tu devrais savoir quel programme est en train de partir en vrille, donc tu devrais pouvoir choisir toi-même quel programme fermer avant le OOM-killer.
Yth.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
[^] # Re: TL ; DR
Posté par Yth (Mastodon) . Évalué à 7.
Mais sous Linux aussi malloc renvoie NULL quand il ne peut pas allouer la mémoire.
Et je suppose que la plupart des logiciels écrit à peu près correctement savent gérer la situation.
Donc l'OOM-killer il sert uniquement dans les autres cas.
Lesquels ? Sais pas vraiment, mais si je n'ai pas rencontré l'OOM-killer depuis plus de 15 ans, il doit bien y avoir une raison, genre c'est le dernier des derniers recours quand tout le reste à foiré.
Et franchement, si ton système en est là, flinguer au hasard est une technique qui en vaut bien une autre. L'alternative étant probablement un crash du kernel et donc un massacre de tous les processus.
Et après, il faudrait vraiment m'expliquer pourquoi ça vaudrait vraiment le coup de se fouler plus que ça pour ce cas tellement extrême que de toute façon le système est inutilisable depuis un moment ?
C'est pas l'OS le problème quand on en arrive là…
Yth.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?
[^] # Re: TL ; DR
Posté par kna . Évalué à 10.
Euh, c'est pas vraiment au hasard, hein ?
Il flingue le process qui a le score le plus haut, score calculé en fonction de :
* la mémoire qu'il consomme, évidemment
* l'importance du process (s'il est lancé par root, le score diminue), pour éviter de tuer un processus critique
* le tuning éventuellement fait par l'adminsys
https://unix.stackexchange.com/questions/153585/how-does-the-oom-killer-decide-which-process-to-kill-first
[^] # Re: TL ; DR
Posté par Yth (Mastodon) . Évalué à 3.
Et donc :
C'est du FUD.
Dommage, le fond de l'article soulève de vrais problèmes, mais ce genre d'attaques infondées, et de phrases à l'emporte-pièce, gâchent le propos.
Yth.
[^] # Re: TL ; DR
Posté par gnumdk (site web personnel) . Évalué à 2.
Je me disais bien aussi. J'ai déjà eu des applis de merde (ou un script bash mal branlé) qui m'ont lancé OOM killer et ça a tuer le process de merde.
[^] # Re: TL ; DR
Posté par barmic . Évalué à 4.
Ça c'est parce que vous avez pas d'applications.
Désolé, hein, j'aime bien haiku, mais l'OS doit se débrouiller pour vivre avec des appli qui ne sont pas sympa. On ne serait pas passé à un modèle préemptif sinon.
Il faut comprendre que faire un truc bien et maintenir cette qualité au passage à l'échelle ça n'a presque rien avoir. Faire des dizaines de fois moins de choses qu'un autre et bien le faire, j'ai plus envi de dire que c'est bien heureux. Faire des choses en petits commité et bien les faire c'est aussi assez logique.
Qu'il soit possible de faire mieux, j'ai pas de doute, mais pas forcément bien mieux et pas sans de gros changements dans les organisations. Mais je me trompe peut être.
Si vous avez des solutions tout le monde sera heureux de les entendre. Il y a des gens qui paient des conf pour justement avoir ce genre d'info, il y a même des formations qui sont données (et bien chère). Sincèrement ceux qui ont des idées, n'hésitez pas à vous lancer vous gagnerez de l'argent et ferrez avancer vos idées (c'est une manière bien plus efficace de contribuer au monde au quel vous semblez aspirer) que de développer un truc dans son coin.
[^] # Re: TL ; DR
Posté par Tangi Colin . Évalué à 3.
Personnellement je ne trouve pas ça "strictement" sans intérêt. Je trouve le passage ou il compare la taille d'un binaire à son utilité fallacieux.
Mais y a deux trois truc vrai. Le fait qu'on construit sur de l'existant un peu trop souvent sans penser dette technique. Qu'il y a des effets de mode/cycle: le cas YAML vs XML est un exemple très parlant. On aurait aussi pu citer protobuf vs ASN1, la "révolution agile, le TDD" dont les principes existaient déjà dans les années etc…
Je pense qu'il manque à pas mal d'ingénieur/informaticiens un bagage en histoire de l'informatique.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.