Un nouveau jeu de données révèle l'utilisation réelle des ressources au repos pour les applications auto-hébergées

SelfHost Atlas a publié un nouveau jeu de données ouvert qui fournit des mesures de consommation de ressources pour des centaines d'applications auto-hébergeables. Publié en octobre 2026, ce recueil consigne l'empreinte mémoire et disque réelle au repos des logiciels installés sur des serveurs propres et neufs, en suivant la documentation officielle. Ces données offrent une vérification concrète aux développeurs et administrateurs système qui doivent dimensionner leur infrastructure en se basant sur le comportement observé plutôt que sur des minimums théoriques.

Ce qui s'est passé

Le jeu de données, hébergé sur GitHub sous licence CC BY 4.0, contient des enregistrements pour 256 applications. Chaque entrée représente une installation vérifiée où les instructions d'installation publiées par le projet ont été exécutées de bout en bout sur une machine virtuelle cloud jetable. Le processus capture si l'installation a réussi, quel système d'exploitation a été utilisé, et la date de la vérification. Crucialement, il consigne également l'utilisation des ressources immédiatement après le premier démarrage, fournissant une référence pour ce que ces applications consomment lorsqu'elles ne sont pas sous charge.

La méthodologie repose sur un harnais strict qui purge tous les conteneurs, volumes et caches de build entre chaque test. Cela garantit que les chiffres de disque et de mémoire appartiennent exclusivement à l'application testée, sans contamination par les exécutions précédentes. Les mesures incluent la somme de la mémoire rapportée par Docker stats pour tous les conteneurs actifs trente secondes après le démarrage, ainsi que l'espace disque total utilisé par les images, conteneurs et volumes. Ces chiffres sont associés à des métadonnées sur la configuration spécifique de la machine utilisée pour le test, comme le type d'instance et la version de l'OS.

Un aspect significatif de cette publication est la distinction entre les valeurs mesurées et les recommandations documentées. Le jeu de données inclut à la fois la RAM au repos observée et la RAM minimale suggérée par le projet amont ou les éditeurs de l'atlas. Dans de nombreux cas, ces chiffres diffèrent substantiellement. Par exemple, certains gestionnaires de mots de passe documentent un besoin de 256 Mo de RAM mais idlent réellement à seulement 7 Mo. Inversement, des outils de gestion de photos peuvent recommander 2 Go mais idler autour de 100 Mo. Cette divergence met en évidence l'écart entre les marges de sécurité conservatrices et les coûts opérationnels réels.

Détails clés

• Le jeu de données comprend 256 enregistrements, disponibles aux formats JSON et CSV, avec un DOI pour la citation.
• Les mesures capturent l'utilisation de la RAM et du disque au repos sur un serveur propre et fraîchement purgé, immédiatement après l'installation.
• La vérification de l'installation confirme que la documentation officielle fonctionne sur des versions spécifiques de l'OS, enregistrant le succès ou l'échec.
• La RAM minimale documentée est clairement séparée de la RAM au repos mesurée pour éviter toute confusion entre recommandations et observations.
• L'utilisation du CPU, le temps d'installation et l'effort de maintenance ne sont pas inclus dans cette première version.
• Les données sont sous licence CC BY 4.0, nécessitant une attribution à SelfHost Atlas si elles sont utilisées ou adaptées.

Contexte

Lors de la planification de l'infrastructure pour des logiciels auto-hébergés, les ingénieurs comptent souvent sur les exigences système minimales listées dans la documentation du projet. Ces chiffres sont généralement conservateurs, conçus pour garantir que le logiciel fonctionne même sur du matériel contraint ou lors de pics de charge inattendus. Cependant, pour les petites équipes ou les individus exécutant plusieurs services sur un seul serveur privé virtuel, ces estimations conservatrices peuvent mener à un surdimensionnement et à des coûts inutiles. Comprendre la différence entre un minimum recommandé et l'utilisation réelle au repos est crucial pour une planification efficace de la capacité.

L'auto-hébergement consiste à exécuter des logiciels sur votre propre infrastructure plutôt que de dépendre d'un fournisseur SaaS tiers. Cela donne aux utilisateurs le contrôle sur leurs données et les options de personnalisation, mais transfère la charge de la maintenance et de la gestion des ressources à l'utilisateur. Des outils comme Docker simplifient le déploiement, mais n'éliminent pas le besoin de comprendre combien de mémoire et de stockage chaque conteneur consomme. Sans données précises, les administrateurs peuvent allouer trop de ressources à une application, affamant les autres, ou payer pour des instances de serveur plus grandes que nécessaire.

Pourquoi c'est important

Pour les équipes gérant leur propre pile logicielle, des données de ressources précises impactent directement le budget et la performance. Si un administrateur suppose que chaque application a besoin de la RAM minimale documentée, il pourrait provisionner un serveur avec 8 Go de mémoire alors que 4 Go suffiraient selon les mesures réelles au repos. Ce surdimensionnement augmente les factures cloud mensuelles sans ajouter de valeur. Inversement, connaître l'empreinte réelle au repos permet un regroupement plus serré des services sur un seul hôte, maximisant l'utilité du matériel existant.

Le jeu de données sert également de couche de vérification pour la documentation d'installation. Dans le monde rapide de l'open source, les instructions d'installation peuvent devenir obsolètes rapidement. En enregistrant quelles versions de l'OS ont exécuté avec succès les scripts d'installation à des dates spécifiques, le jeu de données aide les utilisateurs à identifier quelles combinaisons sont connues pour fonctionner. Cela réduit le temps passé à diagnostiquer des dépendances cassées ou des bibliothèques système incompatibles lors de la configuration initiale. Il fournit une base de confiance que le logiciel peut être déployé comme décrit.

De plus, la transparence de la méthodologie renforce la confiance. Parce que les données sont générées par un script automatisé sur des machines propres, cela élimine les biais humains ou les astuces d'optimisation qui pourraient fausser les résultats. Les utilisateurs peuvent voir exactement comment les chiffres ont été dérivés, y compris les commandes Docker spécifiques et les états système. Ce niveau de détail permet aux ingénieurs DevOps de reproduire les tests dans leurs propres environnements si nécessaire, garantissant que les données correspondent à leurs cas d'utilisation et contraintes spécifiques.

Ce que vous pouvez faire

• Téléchargez les fichiers CSV ou JSON depuis le dépôt GitHub pour analyser l'utilisation des ressources des applications que vous exécutez actuellement ou prévoyez de déployer.
• Filtrez les enregistrements par install_verified_date pour vous assurer que vous consultez des tests récents, car les installations plus anciennes peuvent ne pas refléter les versions actuelles des logiciels.
• Comparez documented_min_ram_mb avec measured_ram_mb pour vos applications cibles afin d'identifier un potentiel surdimensionnement dans votre configuration actuelle.
• Utilisez le champ install_verified_os pour vérifier si l'application a été testée sur la même version du système d'exploitation que celle que vous utilisez en production.
• Attribuez correctement les données en utilisant les directives CC BY 4.0 fournies si vous publiez des analyses ou des tableaux de bord basés sur ce jeu de données.
• Surveillez le dépôt pour les mises à jour, car le jeu de données est régénéré mensuellement pour inclure de nouvelles applications et des mesures actualisées.