Neuer Datensatz zeigt tatsächlichen Ressourcenverbrauch im Leerlauf für selbst gehostete Apps

SelfHost Atlas hat einen neuen offenen Datensatz veröffentlicht, der gemessene Ressourcenverbräuche für Hunderte von selbst hostbaren Anwendungen bereitstellt. Die im Oktober 2026 veröffentlichte Sammlung erfasst die tatsächliche Speicher- und Festplattenbelegung im Leerlauf von Software, die auf sauberen, neu installierten Servern gemäß offizieller Dokumentation installiert wurde. Die Daten bieten Entwicklern und Systemadministratoren eine Realitätsprüfung, um ihre Infrastruktur basierend auf beobachtetem Verhalten und nicht nur auf theoretischen Mindestwerten zu dimensionieren.

Was ist passiert?

Der auf GitHub unter einer CC BY 4.0-Lizenz gehostete Datensatz enthält Einträge für 256 Anwendungen. Jeder Eintrag repräsentiert einen verifizierten Installationsdurchlauf, bei dem die vom Projekt veröffentlichten Installationsanweisungen end-to-end auf einer wegwerfbaren Cloud-Virtual-Machine ausgeführt wurden. Der Prozess erfasst, ob die Installation erfolgreich war, welches Betriebssystem verwendet wurde und das Datum der Verifizierung. Entscheidend ist auch die Aufzeichnung des Ressourcenverbrauchs unmittelbar nach dem ersten Start, was eine Baseline für den Verbrauch dieser Anwendungen im Nicht-Belastungszustand liefert.

Die Methodik basiert auf einem strengen Testrahmen, der alle Container, Volumes und Build-Caches zwischen jedem Test bereinigt. Dies stellt sicher, dass die Werte für Festplatte und Speicher ausschließlich der getesteten Anwendung zugeordnet werden können, ohne Kontamination durch vorherige Läufe. Die Messungen umfassen die Summe des von Docker stats gemeldeten Speichers aller laufenden Container dreißig Sekunden nach dem Start sowie den gesamten von Images, Containern und Volumes belegten Festplattenspeicher. Diese Zahlen werden mit Metadaten zur spezifischen Maschinenkonfiguration für den Test kombiniert, wie etwa Instanztyp und OS-Version.

Ein wesentlicher Aspekt dieser Veröffentlichung ist die Unterscheidung zwischen gemessenen Werten und dokumentierten Empfehlungen. Der Datensatz enthält sowohl den beobachteten Idle-RAM als auch den vom Upstream-Projekt oder den SelfHost-Atlas-Herausgebern empfohlenen Mindest-RAM. In vielen Fällen weichen diese Zahlen erheblich voneinander ab. Beispielsweise dokumentieren einige Passwortmanager einen Bedarf von 256 MB RAM, verbrauchen im Leerlauf aber tatsächlich nur 7 MB. Umgekehrt empfehlen Fotomanagement-Tools möglicherweise 2 GB, liegen im Leerlauf aber bei etwa 100 MB. Diese Diskrepanz verdeutlicht die Kluft zwischen konservativen Sicherheitsmargen und tatsächlichen Betriebskosten.

Wichtige Details

• Der Datensatz umfasst 256 Einträge, verfügbar in JSON- und CSV-Formaten, mit einer DOI zur Zitierung.
• Die Messungen erfassen Idle-RAM und Festplattenverbrauch auf einem bereinigten, frischen Server unmittelbar nach der Installation.
• Die Installationsverifizierung bestätigt, dass die offizielle Dokumentation auf bestimmten OS-Versionen funktioniert, und zeichnet Erfolg oder Misserfolg auf.
• Dokumentierter Mindest-RAM wird klar vom gemessenen Idle-RAM getrennt, um Verwechslungen zwischen Empfehlungen und Beobachtungen zu vermeiden.
• CPU-Auslastung, Installationszeit und Wartungsaufwand sind in dieser ersten Version nicht enthalten.
• Die Daten stehen unter der Lizenz CC BY 4.0; bei Nutzung oder Bearbeitung ist eine Namensnennung von SelfHost Atlas erforderlich.

Hintergrund

Bei der Planung der Infrastruktur für selbst gehostete Software verlassen sich Ingenieure oft auf die in der Projektdokumentation aufgeführten minimalen Systemanforderungen. Diese Werte sind typischerweise konservativ gehalten, um sicherzustellen, dass die Software auch auf eingeschränkter Hardware oder bei unerwarteten Lastspitzen läuft. Für kleine Teams oder Einzelpersonen, die mehrere Dienste auf einem einzigen virtuellen privaten Server betreiben, können diese konservativen Schätzungen jedoch zu Überdimensionierung und unnötigen Kosten führen. Das Verständnis des Unterschieds zwischen einer empfohlenen Mindestanforderung und der tatsächlichen Leerlaufnutzung ist entscheidend für eine effiziente Kapazitätsplanung.

Selbsthosting bedeutet, dass Sie Software auf Ihrer eigenen Infrastruktur ausführen, anstatt sich auf einen Drittanbieter-SaaS-Anbieter zu verlassen. Dies gibt Nutzern die Kontrolle über ihre Daten und Anpassungsoptionen, verlagert aber die Last der Wartung und Ressourcenverwaltung auf den Nutzer. Tools wie Docker vereinfachen die Bereitstellung, beseitigen aber nicht die Notwendigkeit zu verstehen, wie viel Speicher und Festplatz jeder Container verbraucht. Ohne genaue Daten könnten Administratoren einer App zu viele Ressourcen zuweisen, wodurch andere ausgehungert werden, oder größere Serverinstanzen bezahlen als notwendig.

Warum es wichtig ist

Für Teams, die ihren eigenen Software-Stack verwalten, haben genaue Ressourcendaten direkte Auswirkungen auf Budget und Leistung. Wenn ein Administrator davon ausgeht, dass jede App den dokumentierten Mindest-RAM benötigt, provisioniert er möglicherweise einen Server mit 8 GB Speicher, obwohl 4 GB basierend auf tatsächlichen Leerlaufmessungen ausreichen würden. Diese Überdimensionierung erhöht die monatlichen Cloud-Rechnungen ohne Mehrwert. Umgekehrt ermöglicht die Kenntnis des tatsächlichen Leerlauf-Fußabdrucks eine engere Packung von Diensten auf einem einzelnen Host, was die Auslastung vorhandener Hardware maximiert.

Der Datensatz dient auch als Verifikationsebene für Installationsdokumentationen. In der schnelllebigen Welt des Open Source können Installationsanweisungen schnell veralten. Indem aufgezeichnet wird, welche OS-Versionen die Installationsskripte an bestimmten Daten erfolgreich ausgeführt haben, hilft der Datensatz Nutzern dabei, Kombinationen zu identifizieren, von denen bekannt ist, dass sie funktionieren. Dies reduziert die Zeit, die für die Fehlersuche bei gebrochenen Abhängigkeiten oder inkompatiblen Systembibliotheken während der Ersteinrichtung aufgewendet wird. Es bietet eine Vertrauensbasis dafür, dass die Software wie beschrieben bereitgestellt werden kann.

Darüber hinaus schafft die Transparenz der Methodik Vertrauen. Da die Daten von einem automatisierten Skript auf sauberen Maschinen generiert werden, werden menschliche Verzerrungen oder Optimierungstricks eliminiert, die die Ergebnisse verfälschen könnten. Nutzer können genau sehen, wie die Zahlen abgeleitet wurden, einschließlich der spezifischen Docker-Befehle und Systemzustände. Diese Detailtiefe ermöglicht DevOps-Ingenieuren, die Tests bei Bedarf in ihrer eigenen Umgebung zu replizieren, um sicherzustellen, dass die Daten mit ihren spezifischen Anwendungsfällen und Einschränkungen übereinstimmen.

Was Sie tun können

• Laden Sie die CSV- oder JSON-Dateien aus dem GitHub-Repository herunter, um den Ressourcenverbrauch für Apps zu analysieren, die Sie aktuell betreiben oder bereitstellen möchten.
• Filtern Sie Einträge nach install_verified_date, um sicherzustellen, dass Sie aktuelle Tests betrachten, da ältere Installationen möglicherweise nicht die aktuellen Softwareversionen widerspiegeln.
• Vergleichen Sie documented_min_ram_mb mit measured_ram_mb für Ihre Zielanwendungen, um mögliche Überdimensionierungen in Ihrem aktuellen Setup zu identifizieren.
• Nutzen Sie das Feld install_verified_os, um zu prüfen, ob die Anwendung auf derselben Betriebssystemversion getestet wurde, die Sie in der Produktion verwenden.
• Geben Sie die Daten ordnungsgemäß gemäß den bereitgestellten CC BY 4.0-Richtlinien an, wenn Sie Analysen oder Dashboards auf Basis dieses Datensatzes veröffentlichen.
• Beobachten Sie das Repository auf Updates, da der Datensatz monatlich neu generiert wird, um neue Anwendungen und aktualisierte Messungen aufzunehmen.