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 -h ou busybox free -m ne 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, free rapporte 3.5Gio utilisés pour 183 lignes dans ps -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 -A montre 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 freem . En réponse à la dépêche Mesurer la consommation d'énergie des projets informatique, depuis les serveurs, avec scaphandre. É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.