Il est compliqué de mesurer l’impact de l’informatique sur le climat. Si bien que les études qui alimentent les débats sur ce sujet se basent sur des estimations à grande échelle et sont parfois contradictoires. On entend, par exemple, parler des émissions de gaz à effets de serre liées à l’envoi d’un courriel, mais comment être sûr de pouvoir s’appuyer sur ces données ?
Scaphandre devrait pouvoir (enfin) nous donner des réponses crédibles.
En clair comment obtenir des métriques fiables et vérifiables ? En particulier, comment savoir si une action ou une décision prise pour plus de sobriété a l’effet escompté ? Lorsque l’on souhaite s’attaquer à la problématique, notamment sur les systèmes de son entreprise, comment savoir par quel bout s’y prendre ?
Scaphandre est un agent de mesure de la consommation d’énergie d’un serveur et des services qui tournent dessus. Il peut également être utilisé pour mesurer la consommation d’un logiciel ou d’une application, d’une version à une autre.
Le projet, sous licence Apache-2.0, est tout jeune et accueille de nouveaux contributeurs chaque jour. Voici un article qui résume ce qu’il permet de faire aujourd’hui, ce qu’il permettra de faire demain et pourquoi il a été lancé.
Bonne lecture et au plaisir d’en discuter.
# Super
Posté par gasche . Évalué à 10. Dernière modification le 16 janvier 2021 à 16:23.
Merci, c'est un projet intéressant et je trouve ton billet de présentation remarquable.
Je vais essayer de faire joujou avec.
Quelques retours immédiats:
Vers la fin du billet il y a un lien "c'est ici" qui pointe vers les "issues" du projet, je m'attendrais plutôt à un lien vers la page d'accueil du dépôt source (pour voir le README, etc.).
La première question que je me pose, "mais comment est mesurée la consommation ? est-ce que je peux faire confiance à la mesure". Il y a une réponse dans la documentation, on aimerait que le README y fasse directement référence.
Sur l'exemple de visualisation, le graphique en haut à gauche ("Host's power consumption") indique trois quantités avec les unités entre parenthèses "(from microwatts)", "(from microjoules)". Je ne comprends pas le "from" ici, pour moi ça n'est pas correct grammaticalement, je dirais juse "(microwatts)", "(microjoules)". Tant qu'on y est, je dirais juste "Host power consumption".
Toujours sur cet exemple de visualisation, pas mal de graphes sont des sommes de diracs (presque 0 la plupart du temps, sauf des pics très hauts et très fins), sans doute quand un processus ponctuel et court se lance. Je n'arrive pas à estimer la consommation ces services visuellement (il faudrait estimer l'aire sous la courbe et c'est trop difficile). Ça serait utile de mettre une deuxième courbe moyennée sur une fenêtre de temps plus longue (relativement à la fenêtre de temps affichée), qui permettrait de faire cette estimation visuellement.
[^] # Re: Super
Posté par nulse . Évalué à 3.
Bonjour,
Merci pour ces retours !
Le lien vers la page d'acceuil du projet est plus haut dans l'article, mais je note car c'est vrai qu'arriver directement sur les issues peut être déroutant :)
Effectivement ajouter un lien vers cette section dans le readme peut être un plus. La documentation est en mouvement et les sections vont sûrement être remodelées dans les jours à venir. On essaye de clarifier les choses au maximum, j'espère que ce sera plus clair bientôt.
En fait, c'est la même métrique (la consommation du CPU de l'hôte) calculée de 3 manières différentes (une fois en faisant le cumul de conso des process, puisen collectant directement la métrique globale depuis RAPL, en récupérant directement la métrique et en faisant la conversion vers des microwatts avec promQL d'un côté et en s'appuyant sur la conversion proposée par scaphandre de l'autre). Le dashboard est un WIP et n'est pas très clair pour le moment. Ca devrait s'améliorer bientôt.
Tu veux dire pour lire la consommation d'un process lancé par un service comme AWX par exemple ?
# Energie grise
Posté par Pol' uX (site web personnel) . Évalué à 7.
Sans vouloir dénigrer l'intérêt du projet (qui a l'air très intéressant au demeurant), la question de l'impact sur le climat risque de ne pas être solutionnée par la mesure coté serveur car :
Adhérer à l'April, ça vous tente ?
[^] # Re: Energie grise
Posté par gasche . Évalué à 8.
Si on voulait comprendre les proportions dont il est question ("essentiellement pas", "très lourd", ça veut dire quoi concrètement ?), ou pour avoir plus de détails, on irait consulter quelle référence qui explique ça ?
[^] # Re: Energie grise
Posté par Pol' uX (site web personnel) . Évalué à 6. Dernière modification le 18 janvier 2021 à 12:40.
Pour les PC le chiffre qu'on voit souvent c'est que l'énergie de fabrication est estimée peser 3 à 5 fois l'énergie d'utilisation. Pour les mobiles c'est plus.
Et si on regarde le CO2 c'est encore plus accentué car en général l'énergie mobilisée par la fabrication est plus sale que l'énergie mobilisée à l'utilisation.
Quelques références en vrac :
Et la réponse précise à ta question :
Et il y a plus de terminaux vendus que de serveurs. Exemples de chiffres de vente glanés en 3 minutes :
0 003 500 000 serveurs https://www.lemagit.fr/actualites/252459978/Les-ventes-de-serveurs-progressent-de-85-surtout-grace-a-la-Chine
0 261 000 000 de PC : https://www.zdnet.fr/actualites/chiffres-cles-le-marche-des-pc-39380521.htm
1 370 000 000 ordiphones : https://www.zdnet.fr/actualites/chiffres-cles-les-ventes-de-mobiles-et-de-smartphones-39789928.htm
Notons que ça ne trahit pas l'intuition : dans le monde du web, si vous avez plus de serveurs que de clients, c'est que vous êtes alternatifs. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Energie grise
Posté par Renault (site web personnel) . Évalué à 10.
Il y a par exemple l'ADEME qui a compilé quelques chiffres détaillés avec les cycles de vie complet : https://www.bilans-ges.ademe.fr/documentation/UPLOAD_DOC_FR/index.htm?ordinateurs_et_equuipements_pe.htm
Cela donne un ordre de grandeur.
Après cela a aussi un sens logique. De nos jour un ordinateur ou un téléphone cela ne consomme pas beaucoup d'énergie à l'usage. Il y a eu un gros travail dessus. Mais on a toujours besoin de grandes quantités de métaux et de transports pour les produire et les amener chez le client. Et la plupart de ces composants étant produits en Chine, le transport et l'électricité des usines sont très carbonés. Il faut donc beaucoup de temps pour que l'usage rattrape la fabrication.
Après, n'oublions pas que ce principe (et ces chiffres) valent pour la France qui a l'électricité parmi les moins impactantes pour le climat au monde. Ce principe est beaucoup moins vrai pour un allemand, un polonais ou un chinois par exemple.
[^] # Re: Energie grise
Posté par Benjamin (site web personnel) . Évalué à 1.
On peux trouver un début de réponse sur une version beta de Nuts une plate forme regroupant ces informations : http://nuts.be-ma.fr
[^] # Re: Energie grise
Posté par Benjamin (site web personnel) . Évalué à 0.
On peux trouver un début de réponse sur une version beta de Nuts une plate forme regroupant ces informations : http://nuts.be-ma.fr
[^] # Re: Energie grise
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
Source ? C'est justement un des gros problème des discussions « informatique et climat ». On a peu de données fiables sur lesquelles s'appuyer. (Au moins pour les ordiphones, je pense que leur consommation est pas mal optimisée car la durée de fonctionnement entre deux recharges est un critère important.)
[^] # Re: Energie grise
Posté par Thomas Douillard . Évalué à 3.
C’est pas tant la consommation qui est couteuse, mais bien souvent la fabrication. Cf. par exemple https://ecoinfo.cnrs.fr/2010/10/20/le-silicium-les-impacts-environnementaux-lies-a-la-production/
[^] # Re: Energie grise
Posté par Pol' uX (site web personnel) . Évalué à 5.
Oui ce n'est pas facile de disposer de données. Elle ne sont pas facile à constituer . Beaucoup sont donc des modélisations, et il y a toujours matière à ergoter. Et moi même je ne suis pas du tout un expert du sujet.
Mais, dans les chiffres relevés plus haut à la va-vite :
- une source parle de 3.5 millions de serveurs vendus à l'année (mea culpa : j'avais pris un mauvais chiffre dans le propos plus haut ; si un modo peut éditer pour remplacer 0 000 270 000 par 0 003 500 000 c'est bienvenu).
- une source parle de 261 millions de PC vendus dans le même laps de temps (75 fois plus).
- une source parle de 1 370 millions de smartphone vendus dans le même laps de temps (400 fois plus).
Question : est-ce que d'après votre bon sens, en moyenne, la partie high tech d'un serveur pèse plus lourd que celle réunie de 400 smartphone + 75 PC ? Perso je pense que non.
L'Ademe recommande, concernant les serveurs, d'affecter les valeurs d'émission au prorata du prix de vente, comparé au prix d'une unité centrale (modélisation grossière, là encore ; mais pas dénuée de sens).
Le prix moyen du serveur déductible des chiffres de lemagit est ~6200€. J'ignore le prix moyen de 75 UC mais on doit être proche de 75*800 = 60000€. Soit des émissions modélisables à hauteur de 10x celle du serveur moyen.
Le smartphone quant à lui pollue ~7x moins que le PC selon le même tableau Ademe, donc 400 smartphones pollueraient de l'ordre de 57x celle du PC moyen, soit près de 6x celle du serveur moyen.
Au final, et avec toutes les précautions qu'on peut prendre du fait de manipuler des chiffres à l'emporte pièce, on tombe grosso merdo sur un impact 16x plus lourd coté terminal que coté serveur.
Dans les liens donnés plus haut, il y a peut être des études plus sérieuses basées sur des chiffres mieux établis.
Adhérer à l'April, ça vous tente ?
[^] # Re: Energie grise
Posté par Arkem . Évalué à 1.
Fait ;-)
[^] # Re: Energie grise
Posté par freem . Évalué à 5. Dernière modification le 17 janvier 2021 à 20:06.
Même si les terminaux et la fabrication du serveurs coûtent, ce dont je ne doute pas, les optimisations (parce qu'au final, pour réduire la facture, faut optimiser ou virer des fonctionnalités lourdes, j'imagine) qui permettent de consommer moins (de RAM, de CPU, d'espace disque) ne peuvent-elles pas du même coup rendre le soft utilisable, justement, sur du plus vieux matériel?
Quand je vois que par exemple sur mes systèmes (Debian 10, fonctionnant sur runit) les processus qui gèrent les daemons (runsv pour la gestion d'un daemon, svlogd pour gérer ses logs) ont un coût de RSS (mémoire résidente) de 740Kio en moyenne, pour un coût total de ~1.5Mio par daemon, je me pose des questions. Ces outils ne faisant quasi rien…
Une rapide comparaison très biaisée indique, pour
int main() { for( ;; ); }:Le VSZ, on s'en fout un peu (c'est la mémoire utilisée, mais pas réservée. Si je dis pas de conneries, lancer 2 processus images du même programme auront notamment les sections .text communes, les lib partagées également, etc, sans compter la mémoire réservée mais pas utilisée (overcommit) et ce genre de joyeusetés).
La taille de binaire est surtout pertinente du fait que, ben, ça prend de la bande passante quand il faut installer, l'espace disque est aussi un argument, mais il me semble moins pertinent. N'empêche que ça reste un argument (la bande passante, ça fait chauffer pleins de machines).
Par contre, le RSS, ça me semble pertinent: c'est une pas si mauvaise approximation de l'impact sur la RAM (pas exacte, cependant, par exemple GNU
free -houbusybox free -mne me donnent pas du tout les mêmes valeurs, GNU free étant inférieur à la somme des RSS de tous les processus, la ou busybox trouve justement cette valeur).Bon, évidemment, le programme ici ne fait tellement rien (d'autre que monter un coeur à 100%) que ces résultats ne peuvent pas servir de manière brute.
Sur de gros programmes, le coût est probablement négligeable: par exemple, sur ma machine,
freerapporte 3.5Gio utilisés pour 183 lignes dansps -A.Un calcul rapide (et surtout bien pourri) permettrait de dire "(744 - 4 )*183 => ~132Mio soit ~3.7% économisés".
C'est évidemment faux, ne serait-ce que parce que
ps -Amontre aussi des éléments du noyau je crois (rcu_sched, migration/3, etc) ce qui implique que le résultat est trop élevé par rapport à la réalité.N'empêche que si on prend un système moins puissant que mon PC de bureau, et plus vieux, par exemple une beaglebone black (512Mio de RAM).
Le surcoût de pas loin de 1.5Mio gâchés par daemon (on pourrait même dire de 2.1Mio pour la plupart des daemon, puisqu'eux aussi souffrent de ce problème), multiplié par le nombre de daemons d'un système (cron, getty, client dhcpd, cups, mpd, caches dns parfois, proxy ldap (nslcd), etc) peut vite représenter une valeur non négligeable.
Disons 10 daemons. 15Mio. 512Mio de RAM dispo. Presque 3%. Si on compte le daemon lui même, on monte donc à 21Mio, soit plus de 4%.
Bref.
En réduisant ces coûts, je pense qu'il est probable que l'on puisse aussi utiliser plus longtemps les vieux systèmes, et donc baisser l'impact énergétique de l'informatique puisque l'on diminuerais le nombre de machines jetées à la benne en plus de diminuer légèrement la consommation fonctionnelle.
[^] # Re: Energie grise
Posté par nulse . Évalué à 4.
Bonjour,
Merci pour ce retour. Il est tout à fait vrai que les terminaux sont une part importante du problème. Si l'on parle de consommation d'énergie, pour garder la même métrique, c'est 60% de la conso globale si l'on prend en compte la production.
La question ici me semble être celle de l'impact que l'on a, d'un côté en tant que particulier, consommateur et citoyen. De l'autre, il y a l'impact que l'on a en tant qu'informaticien et potentiellement employé dans une entreprise qui créé des services numériques. C'est plutôt de ce côté que scaphandre tente d'apporter des bouts de réponse.
Le mix énergétique de production d'électricité en france étant plutôt décarbonné par rapport à ses voisins, on a tendance à sous-estimer le problème. Dans les exemples de service que j'évoque dans l'article, les machines tournaient en dehors de france et aux US, pour des questions business et d'accès aux dernière fonctionnalités du provider. Mauvaise pioche donc, mais ce cas est courant (également) chez les boites françaises que l'on associe aux entreprises "du numérique".
Il faut aussi s'intéresser aux perspectives sur ce sujet. L'augmentation en cours et à venir de la consommation d'énergie de cette "partie du numérique" me laisse penser qu'il est important de rendre visibles les choses pour tendre vers plus de sobriété.
Ce projet ne remplace en rien les efforts à faire concernant les terminaux, que ce soit en terme de longévité/réparation ou de conception des services sollicités, pour freiner l'obsolescence. C'est seulement un élément de réponse sur un sous ensemble des problèmes à traiter. Il faut bien commencer quelquepart :)
(Encore merci pour ce message, ça me fait penser qu'un rappel des ordres de grandeur dans une partie de la documentation du projet pourrait être utile.)
# L'autre face de la mesure de la consommation énergétique
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Attacking CPUs with power side channels (conférence au rC3 évoquée dans ce journal)
# climat / planète /
Posté par Psychofox (Mastodon) . Évalué à 5.
Je pense que c'est une erreur de présenter ce projet sous l'angle de l'écologie. Il y a clairement un conflit d'intérêt entre l'envie somme toute égoiste de vouloir baisser sa conso et la facture d'électricité avec le fait de produire plus de biens.
On a parlé plus haut de l'impact co2 de la production de nouveaux appareils, que l'on peut vaguement mesurer même si cette info n'est pas mentionnée au consommateur, mais il y a aussi des impacts non mesurables comme la pollution des sols et eaux usées par les usines et mines servant à l'extraction des matières premières, l'impact sur la santé des travailleurs, le traitement des appareils retiré d'activité (le recyclage est à l'heure actuelle une vaste blague).
[^] # Re: climat / planète /
Posté par nulse . Évalué à 4.
Bonjour,
Je présente ce projet sous l'angle de l'écologie, car c'est la motivation qui m'a mené à commencer ce projet. Il s'adresse en priorité aux entreprises qui souhaitent entamer un changement de fond, mais si d'autres, moins bien intentionnées, réduisent leur impact pour d'autre raisons, ce sera toujours ça de pris.
Comme évoqué plus haut, les terminaux et leur production, sont effectivement un problème majeur, qui doit être ciblé en parallèle des travaux possibles côté serveurs/services. Ce projet ne remet en rien ce fait en cause.
L'impact global du numérique est une question très large, qui ne peut être addressée que d'une seule manière. Un effort commun, sur les deux aspects (il y en a en fait bien plus), est nécessaire.
# Dubitatif
Posté par zerodeux (site web personnel) . Évalué à 10.
Il y a pas mal de facteurs qui font qu'estimer la consommation de "son" projet est particulièrement casse-gueule. Je clarifie tout de suite : je n'ai aucun problème avec l'idée, mais il faudrait être honnête en précisant qu'il ne s'agit que d'une tentative d'évaluation, et par exemple être prudent en donnant des chiffres en "pseudo-watts", et bien rappeler le périmètre de ce qui est mesurée qui est très restreint.
1/ RAPL ne mesure qu'une toute petite partie de la conso d'un serveur, lui échappe les circuits d'alimentation (efficients à 90% max), toutes les IOs, la RAM, la ventilation, etc. Si tu as accès à un serveur avec un BMC récent, tente de comparer les mesures RAPL avec ce que le BMC mesure directement depuis des capteurs sur la ou les alims du serveur. Perso j'utilise les BMCs pour partir de la conso réelle (que je peux aussi rapprocher à leur somme et ce que je peux lire sur les onduleurs), mais je me suis pas encore aventuré à distribuer ça "soft" par "soft" (prochaine étape : la VM).
2/ Sur un serveur pour maximiser les performances il y a très peu de mécanismes de consommation d'énergie variable en jeu (comme dans les laptops), de ce fait un serveur qui ne fait rien consomme pas mal, et cette conso n'appartient à personne (je relève régulièrement 100 à 150W sur un serveur qui "dort")
3/ Il faut aussi rajouter la conso des équipements réseaux impliqués, c'est certes souvent un ou deux ordres de grandeur inférieur aux serveurs car on peut mutualiser et être très efficient sur la partie switch et routage, mais toute de même … En tout cas je n'irai pas jusqu'à décompter la partie FAI et le terminal, c'est intéressant mais c'est un autre sujet (certes connexe).
4/ Toutes ces données varient énormément d'un DC à l'autre, et la plupart des clouds sont complètement opaques à ce sujet. Au mieux on a le PUE, souvent vers 1,1 ces jours-ci donc penser à s'imputer +10% mini. Vous n'aurez pas le tonnage de batteries au plomb et le tonnage de fuel pour les alternateurs de secours, les pertes en ligne dans le DC, etc. Ni la nature de l'énergie électrique, qui change quand même pas mal la donne si on en fait un projet d'étude écologique. Ce serait facile de dire qu'on n'en paie pas sa part.
5/ La durée de vie des équipements a un gros impact, je mettrais donc un gros malus aux gros cloud qui courrent toujours après le derniers CPU/GPU les plus voraces et donc décomissionnent des anciens équipements parfaitement fonctionnels (donc tous ?). Il semble difficile de trouver du CPU de plus de 5 ans sur le marché, pourtant je peux témoigner qu'un serveur de bonne facture choyé dans l'environnement d'un DC peut tourner 10ans sans soucis, et convient à des foules d'applications qui n'en ressentent aucun grief.
Enfin et c'est ce qui me chiffonne le plus, cette approche part du concept qu'on ne consomme que ce que le programme utilise. C'est à peu près vrai pour du "batch", mais pour faire tourner de l'interactif ça me semble très incorrect, on réserve de la capacité et ce n'est pas gratuit : d'une part parce que des serveurs qui tournent à vide ça consomme (cf. plus haut) et d'autre part parce que ça pousse la demande du cloud vers le haut - et in fine le problème principal aujourd'hui c'est la croissance folle du nombre et de la conso des DCs.
Je pourrais ajouter qu'aujourd'hui une app est rarement isolée à une VM mais va consommer foules de services (storage S3, logs, métriques, etc.) et tout ceci compte; j'ai vu pas mal de 'stacks' où clairement la quantité de logiciels et de ressources consommées n'étaient pas dans l'app, mais ailleurs (CI/CD, régie pub, monitoring, indexation déportée, etc). On pourra facilement publier des chiffres de conso totalement tartuffiens sur la page de son app en oubliant 90% de son écosystème. Perso en amont je forcerai un projet à lister ces ressources et à s'imposer un malus (coef multiplicateur ?) pour chaque ressource supplémentaire. Si ça peut faire réfléchir ceux qui déploient 99 micro-services sur 42 VM autoscalées avec invocation de la moitié des services AWS pour un pauvre blog, ça serait toujours ça de pris.
Bref tout ça pour dire : attention à ne pas confondre la mesure du détail avec la mesure du problème global.
[^] # Re: Dubitatif
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
La mesure précise est compliqué mais souvent ce que tu veux mesuré c'est un delta, tu veux mesuré une baisse de 10%. Que tu es oublié le PUE ou le rendement de l'alim, tu as toujours 10% de baisse.
J'ai lu une étude d'un japonais qui donnait 1 pour 1 entre la production de CO2 lors de fabrication d'un ordinateur et la production au cours de sa vie lié à l'électricité. Avec notre énergie décarboné, en France le rapport serait plutôt de 1 à 4. Ce qui va dans ton sens de ne pas changer trop souvent de machine. D'un autre coté depuis 10 ans, même si la puissance de calcul (flops) n'a pas trop bougé par cpu, l'efficacité énergétique (flops/W) a été multiplié par 20. On pourrait aussi parler des alims qui avaient souvent 50% de rendement contre les alims actuelles à 80%.
"La première sécurité est la liberté"
[^] # Re: Dubitatif
Posté par zerodeux (site web personnel) . Évalué à 8.
Oui mais ce qu'on fait tourner sur ces mêmes CPUs plus efficients est vastement moins efficient. Je n'ai pas de chiffre et sources précises, mais depuis 20 ans que je vois passer des blogs et CMS PHP (que j'héberge), je ne les vois que systématiquement ralentir (mesure du TTBF avec l'app neuve sans plugins) et réclamer de plus en plus de CPUs et de RAM dans leur pré-requis. Commentaire certes trollesque, mais c'est mon observation constante et répétée sur de très longues années.
Autre grand sujet occulté : il faudrait comparer les dépenses énergétiques à fonctions comparables. Par ex. quelle est l'évolution du bilan énergétique du transport de la voix en passant du POTS à la VoIP ? Quelle évolution de la conso en passant de la télé+vidéoclub à Youtube+Netflix par heure regardée ? Comme ces critères n'ont jamais été pris en compte, je m'attend à ce qu'on constate globalement qu'on est de plus en plus inefficients à fonction constante (et SUPER inefficients vu que le matériel a lui-même eu une croissance d'efficience impressionnnante).
[^] # Re: Dubitatif
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
PHP lui-même va plus vite et les applications sont plus grosses, et surtout il y aussi de plus en plus de couche réseau entre le serveur et le client.
Vu l'usage de tonne de plastique pour les VHS, netflix est largement gagnant. Et je ne parle pas de simplement faire 1km en voiture si tu dois aller au vidéo au club pour ça, tu as >1000h de vidéo netflix avant de produire plus de CO2.
"La première sécurité est la liberté"
[^] # Re: Dubitatif
Posté par orsayman . Évalué à 0.
Remarque intéressante. Est-ce que tu as des chiffres qui étayent tes dires ?
[^] # Re: Dubitatif
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
100g de plastique.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.