J'ai du mal comprendre alors, mais le ton me semblait plutôt négatif à l'encontre des DCs lors de la lecture.
Et ça me rassure que tu sois plus ou moins d'accord, tout en disant plus ou moins que tu ne l'es pas :)
Honnêtement, un informaticien de bureau d'étude (dev, admin...) qui ne vois pas le problème devrais vraiment retourner au lycée, pour prendre des cours de philosophie et de français, les deux matières qui à mon époque essayaient de développer le sens critique des élèves (qui n'en avaient souvent pas grand chose à faire, certes).
Un exemple "très récent" du problème du je-m-en-foutisme pour moi est quand je me suis aperçu qu'une installation minimale de Debian via l'installateur ne peux pas démarrer si la VM ne dispose pas d'au moins 250 Megs de RAM. Une fois bien démarrée, la machine n'en consommait même pas 60... la raison?
L'initrd ne rentre pas. Pourtant à l'install j'ai bien sélectionné l'option pour n'avoir que les pilotes nécessaires...
Avant ça, il me fallait moins de 150 megs, il me semble. D'ailleurs, si quelqu'un à des pointeurs qui expliquent comment en pratique il serait possible de faire un initrd minimal, pour un système "moderne" (debian stable, c'est pas non plus si moderne que ça je suppose) ça m'intéresse.
De la même manière, j'ai remarqué pendant un temps qu'utiliser de l'édition de liens dynamique avec glibc6 ajoute "magiquement" 750Kio de ressources dédiées à une application, qui autrement n'en consommerait potentiellement que 4Kio, ce qui peut être vérifié en utilisant un liage statique ou, tout bêtement, muslc (dynamique ou pas, ça ne change rien de ce côté avec cette lib).
Je vois avec plaisir que ça à changé, ps -orss,vsz,comm --sort=rss indique mes processus les plus légers à 60Kio, c'est nettement mieux (il y a un ordre de grandeur d'écart quand même, ça m'intrigue ça, ils ont corrigé un bug sévère chez gcc ou quoi?).
Si je prend juste les 22 processus que sont runit, runsvdir, runsv et svlogd, avant ça aurait donné environ 140Mio de conso "gratuite". Si je regarde la totalité de la ram actuellement utilisée sur ma machine, c'est à dire 291Mio, et que je regarde ce que ça donnerai hypothétiquement, ça ferait grosso merdo 30% ("( 291 + 140 ) / 291"). C'était beaucoup.
Maintenant, ça ne fait plus "que" 3%. Ca reste non négligeable pour des processus qui ne font virtuellement que dalle (j'avais regardé la ram que bouffe systemd aussi: il dépassait le mega de RSS si je me souviens bien, mais son avantage est que son poids n'est que très peu impacté par le nombre de daemons, contrairement à mon archi basée sur runit qui y est plus sensible, mais j'avais caculé qu'il me faudrait une 30aine de démons gérés par runsv+glibc en dynamique pour que ça soit rentable, si ma mémoire est bonne: ça date, donc c'est pas sûr).
Du coup, ce qui est agaçant, c'est que même pas ça ne concerne que le développement applicatif (qui a l'excuse de devoir modifier ses interfaces en permanence je suppose), le gâchis de ressources: même le développement système qui devrais justement se faire le plus léger possible, par exemple pour stocker plus de VMs par machine physique, gâche des quantités de ressources importantes (une fois mis à l'échelle en multipliant les instances, ce qui est, je crois, la méthode moderne?).
Alors évidemment il ne faut pas non plus sur-optimiser, et ces quelques kilo par processus semblent négligeables comparé aux ressources disponibles sur des machines modernes... mais je crois que c'est la mauvaise façon de voir si un système est performant.
Pour moi, ce qu'il faut regarder ce n'est pas la ressource disponible, mais bien les ressources utilisées par le processus et, si possible, les bibliothèques qu'il charge: ça permets de se donner idée du bloat. Dans le cas de glibc6, selon ce que je vois, la, sur mon portable (avec lequel je n'écrit pas ce message) c'est que des processus qui ne devraient consommer qu'une seule page (4Kio) de ram, en consomment 15 fois plus. La conclusion évidente est que glibc, même si ça c'est méchamment amélioré (vraiment une super surprise ça) reste bien bloatée.
J'imagine qu'il faut aussi voir l'évolution de la conso en ressources d'un logiciel lors de son cycle de vie.
Evidemment, tout ça, ça prend du temps, et le client s'en fout "un peu"... si ce n'est pas le client qui s'en fout, alors ça sera le commercial ou le patron. Ou le développeur (parce que bon, c'est facile de rejeter la faute sur les autres échelons, mais ce n'est pas toujours taper sur les bons).
[^] # Re: mouai
Posté par freem . En réponse au lien La chasse au gaspillage dans le cloud et les data centers. Évalué à 3.
J'ai du mal comprendre alors, mais le ton me semblait plutôt négatif à l'encontre des DCs lors de la lecture.
Honnêtement, un informaticien de bureau d'étude (dev, admin...) qui ne vois pas le problème devrais vraiment retourner au lycée, pour prendre des cours de philosophie et de français, les deux matières qui à mon époque essayaient de développer le sens critique des élèves (qui n'en avaient souvent pas grand chose à faire, certes).
Un exemple "très récent" du problème du je-m-en-foutisme pour moi est quand je me suis aperçu qu'une installation minimale de Debian via l'installateur ne peux pas démarrer si la VM ne dispose pas d'au moins 250 Megs de RAM. Une fois bien démarrée, la machine n'en consommait même pas 60... la raison?
L'initrd ne rentre pas. Pourtant à l'install j'ai bien sélectionné l'option pour n'avoir que les pilotes nécessaires...
Avant ça, il me fallait moins de 150 megs, il me semble. D'ailleurs, si quelqu'un à des pointeurs qui expliquent comment en pratique il serait possible de faire un initrd minimal, pour un système "moderne" (debian stable, c'est pas non plus si moderne que ça je suppose) ça m'intéresse.
De la même manière, j'ai remarqué pendant un temps qu'utiliser de l'édition de liens dynamique avec glibc6 ajoute "magiquement" 750Kio de ressources dédiées à une application, qui autrement n'en consommerait potentiellement que 4Kio, ce qui peut être vérifié en utilisant un liage statique ou, tout bêtement, muslc (dynamique ou pas, ça ne change rien de ce côté avec cette lib).
Je vois avec plaisir que ça à changé,
ps -orss,vsz,comm --sort=rssindique mes processus les plus légers à 60Kio, c'est nettement mieux (il y a un ordre de grandeur d'écart quand même, ça m'intrigue ça, ils ont corrigé un bug sévère chez gcc ou quoi?).Si je prend juste les 22 processus que sont runit, runsvdir, runsv et svlogd, avant ça aurait donné environ 140Mio de conso "gratuite". Si je regarde la totalité de la ram actuellement utilisée sur ma machine, c'est à dire 291Mio, et que je regarde ce que ça donnerai hypothétiquement, ça ferait grosso merdo 30% ("( 291 + 140 ) / 291"). C'était beaucoup.
Maintenant, ça ne fait plus "que" 3%. Ca reste non négligeable pour des processus qui ne font virtuellement que dalle (j'avais regardé la ram que bouffe systemd aussi: il dépassait le mega de RSS si je me souviens bien, mais son avantage est que son poids n'est que très peu impacté par le nombre de daemons, contrairement à mon archi basée sur runit qui y est plus sensible, mais j'avais caculé qu'il me faudrait une 30aine de démons gérés par runsv+glibc en dynamique pour que ça soit rentable, si ma mémoire est bonne: ça date, donc c'est pas sûr).
Du coup, ce qui est agaçant, c'est que même pas ça ne concerne que le développement applicatif (qui a l'excuse de devoir modifier ses interfaces en permanence je suppose), le gâchis de ressources: même le développement système qui devrais justement se faire le plus léger possible, par exemple pour stocker plus de VMs par machine physique, gâche des quantités de ressources importantes (une fois mis à l'échelle en multipliant les instances, ce qui est, je crois, la méthode moderne?).
Alors évidemment il ne faut pas non plus sur-optimiser, et ces quelques kilo par processus semblent négligeables comparé aux ressources disponibles sur des machines modernes... mais je crois que c'est la mauvaise façon de voir si un système est performant.
Pour moi, ce qu'il faut regarder ce n'est pas la ressource disponible, mais bien les ressources utilisées par le processus et, si possible, les bibliothèques qu'il charge: ça permets de se donner idée du bloat. Dans le cas de glibc6, selon ce que je vois, la, sur mon portable (avec lequel je n'écrit pas ce message) c'est que des processus qui ne devraient consommer qu'une seule page (4Kio) de ram, en consomment 15 fois plus. La conclusion évidente est que glibc, même si ça c'est méchamment amélioré (vraiment une super surprise ça) reste bien bloatée.
J'imagine qu'il faut aussi voir l'évolution de la conso en ressources d'un logiciel lors de son cycle de vie.
Evidemment, tout ça, ça prend du temps, et le client s'en fout "un peu"... si ce n'est pas le client qui s'en fout, alors ça sera le commercial ou le patron. Ou le développeur (parce que bon, c'est facile de rejeter la faute sur les autres échelons, mais ce n'est pas toujours taper sur les bons).