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.
# Dubitatif
Posté par zerodeux (site web personnel) . En réponse à la dépêche Mesurer la consommation d'énergie des projets informatique, depuis les serveurs, avec scaphandre. É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.