Ubuntu Server 24.04 Minimal vs. Standard: Leistungsvergleich im Detail

Ein virtueller privater Server (VPS) hat wenig Arbeitsspeicher, daher installieren Sie Ubuntu Server 24.04 LTS neu und stehen vor der Wahl: die Standardinstallation von Ubuntu Server oder eine minimierte Version. Man könnte annehmen, dass weniger Pakete automatisch schnellere Webanfragen, kürzere Datenbankabfragen und eine höhere CPU-Auslastung bedeuten. Der Unterschied ist jedoch komplexer. Ein kleinerer Satz an Startpaketen kann zwar die Festplattennutzung und Hintergrundprozesse reduzieren, beschleunigt aber nicht automatisch den Prozessor oder das Speichermedium.

Kurz gesagt: Wählen Sie die minimale Installation, wenn Sie einen schlanken Startpunkt wünschen und nur die benötigten Tools hinzufügen möchten. Wählen Sie die Standardinstallation, wenn Sie den umfassenderen Standard-Server-Toolset benötigen. Vergleichen Sie Startzeit, Arbeitsspeicherbedarf, Festplattennutzung und tatsächliche Anwendungsleistung separat, anstatt sie unter dem Begriff „schneller“ zusammenzufassen.

Anmerkung (9. Oktober 2026): Dieser Artikel erläutert eine reproduzierbare Benchmark-Methode und die Ergebnisse, die mit den einzelnen Metriken erzielt werden können. Es werden keine Originalmesswerte von zwei identischen Ubuntu-24.04-Installationen präsentiert. Unbestätigte Angaben zu RAM-Auslastung, Festplattennutzung, Bootzeit oder Durchsatz werden nicht als Testergebnisse dargestellt.

Zwei nebeneinanderliegende Terminalfenster im Ubuntu-Stil mit den Bezeichnungen „Standardinstallation“ und „Minimierte Installation“ zeigen jeweils Befehle zur Überprüfung von Bootzeit, Speicher- und Festplattennutzung ohne Messwertausgabe an.
Standard- und minimierte Serverterminals mit denselben in der Warteschlange befindlichen Diagnosebefehlen: systemd-analyze time, free -h und df -h. Die tatsächlichen Werte müssen von Ihren eigenen, entsprechenden Systemen stammen.

Worin besteht der Unterschied zwischen der Standardversion und der minimierten Version von Ubuntu Server?

Der Subiquity-Installer von Ubuntu Server bietet zwei Installationsquellen: ubuntu-servereine Standardinstallation (die voreingestellte) und ubuntu-server-minimaleine minimierte Installation. Canonical dokumentiert diese Quellkennungen und empfiehlt, casper/install-sources.yamldie gewählte ISO-Datei zu überprüfen, da sich die Installer-Kennungen ändern können. Siehe die Canonical-Dokumentation zur automatischen Subiquity-Installationsquelle .

Beide Systeme basieren auf Ubuntu Server 24.04 LTS und verwenden keine unterschiedlich optimierten CPU-Architekturen oder separate Linux-Distributionen. Der Hauptunterschied liegt in der bei der Installation mitgelieferten Software. Welche Pakete genau enthalten sind, hängt von der Revision des Installationsmediums, optionalen Einstellungen, Updates, Treibern und den anschließend installierten Anwendungen ab. Gehen Sie nicht davon aus, dass eine für einen bestimmten Image-Build veröffentlichte Liste unverändert für alle 24.04-Punktversionen gilt.

Die Option „Minimierter Server“ ist nicht mit minimalen Ubuntu-Cloud-Images (einer separaten Image-Familie) oder der Minimalinstallation von Ubuntu Desktop zu verwechseln. Die Versionshinweise zu Ubuntu 24.04 LTS beschreiben eine deutliche Reduzierung der Paketanzahl und der Downloadgröße minimaler Cloud- Images im Vergleich zu früheren Versionen. Die veröffentlichten Beispiele für Cloud-Images stellen keinen kontrollierten Vergleich zwischen Standard- und minimierten Live-Server-ISOs dar, und ihre Werte sollten nicht als solche verwendet werden.

Welche Leistungskennzahlen sind relevant?

MetrikWas minimiert werden könnte, könnte sich ändernWas die Zahl tatsächlich aussagt
Anzahl der installierten PaketeIn der Regel weniger Pakete, bevor Ihre Arbeitslast hinzugefügt wird.Wartungsaufwand, nicht Verarbeitungsgeschwindigkeit
Verwendeter SpeicherplatzPotenziell weniger Platzbedarf durch das BasissystemVerfügbare Kapazität; nicht Festplatten-IOPS oder Latenz
Verfügbarer ArbeitsspeicherMöglicher Vorteil, wenn weniger Hintergrunddienste aktiv sindSpielraum für den Anwendungs- und Dateisystemcache
Start- und BetriebsbereitschaftszeitKönnte sich verbessern, wenn weniger Start-up-Jobs auf dem kritischen Pfad liegenWie schnell ein Server nach einem Neustart wieder einsatzbereit ist
CPU-BenchmarkEs gibt keine intrinsische Leistungssteigerung durch das Entfernen nicht verwandter Pakete.Hauptsächlich CPU-, Kernel-, Scheduler-, Energiezustands- und Benchmark-Bedingungen
Speicher-E/A-BenchmarkKeine garantierte Verbesserung auf demselben Gerät und DateisystemArbeitslastspezifische Bandbreite, IOPS und Latenz
AnwendungsantwortzeitAbhängig von aktiven Prozessen, verfügbarem Speicher und KonfigurationWas ist für reale Nutzer unter vergleichbarer Last wichtig?

Das erwartete Verhalten ist kein messbares Ergebnis. Eine minimierte Maschine verbraucht möglicherweise unmittelbar nach der Installation weniger Ressourcen. Sobald jedoch auf beiden Maschinen dieselbe Datenbank, Container-Laufzeitumgebung, derselbe Überwachungsagent und derselbe Webserver laufen, kann sich der beobachtete Unterschied verringern, verschwinden oder sogar umkehren. Die einzig verlässliche Schlussfolgerung ergibt sich aus der Messung der Zielauslastung.

Beginnen Sie mit einem fairen Testaufbau, nicht mit einer Stoppuhr.

Erstellen Sie zwei temporäre virtuelle Maschinen mit derselben Ubuntu Server 24.04 LTS ISO-Revision: eine Standard- und eine minimierte Version. Weisen Sie ihnen identische vCPU-Anzahl, RAM, virtuelle Festplatten, Dateisysteme, Boot-Modus, Hypervisor-Einstellungen, Netzwerkverbindungen und Speicherklassen zu. Verwenden Sie für physische Maschinen äquivalente Hardware und testen Sie unter vergleichbaren thermischen und Stromversorgungsbedingungen. Vermeiden Sie den Produktivbetrieb der Maschinen.

Installieren Sie auf beiden Systemen dieselben Sicherheitsupdates und starten Sie sie neu. Notieren Sie cat /etc/os-releasesich uname -rdie lscpuVersionsnummer des Installationsabbilds und das Testdatum. Ubuntu Server 24.04 verwendet normalerweise den allgemein verfügbaren Kernel-Track, kann aber optional auch Hardware-Enablement-Kernel (HWE) nutzen. Unterschiedliche Kernel-Tracks würden einen Vergleich anhand des Installationstyps verfälschen. Die Ubuntu-Kernel-Dokumentation zu GA- und HWE-Kerneln erläutert diesen Unterschied.

Sammeln Sie zwei Messreihen:

  1. Referenzzustand bei Neuinstallation: Unmittelbar nach identischen Aktualisierungen, vor der Installation einer Arbeitslast. Dadurch werden die praktischen Unterschiede in den Installationsvorgaben isoliert.
  2. Produktionsähnliche Ausgangslage: Nach der Installation derselben Anwendungspakete, der Aktivierung derselben Dienste und der Anwendung identischer Konfigurationen. Dies zeigt, ob der anfängliche Unterschied im Ressourcenbedarf noch relevant ist.

Führen Sie pro Test mindestens mehrere Durchläufe durch, idealerweise fünf oder mehr nach einer Aufwärmphase, und vergleichen Sie sowohl die Medianwerte als auch die Streuung. Starten Sie das System neu und messen Sie die Startzeit über mehrere Starts hinweg. Vergleichen Sie niemals ein Kaltstartergebnis eines Systems mit einem Ergebnis eines bereits warmen Systems auf einem anderen.

Messen Sie zuerst die einfachen Unterschiede.

1. Zählen Sie die installierten Pakete und prüfen Sie den Speicherplatz.

Paketanzahl und Speichernutzung sind in der Regel die am einfachsten zu überprüfenden Merkmale. Führen Sie auf jeder VM folgenden Befehl aus:

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

Erfassen Sie die Anzahl der Partitionen, den belegten Speicherplatz im Root-Dateisystem und dessen Layout. Stellen Sie sicher, dass die Root-Partitionen vergleichbare Größen aufweisen; andernfalls kann ein scheinbarer Unterschied durch die Partitionierung entstehen. Die Festplattennutzung umfasst auch Protokolle, Paketcaches und Dateisystem-Metadaten, daher sind identische Installationszeiten und vergleichbare Aktualisierungsverläufe wichtig.

2. Vergleichen Sie den verfügbaren Arbeitsspeicher, nicht nur den „freien“ Arbeitsspeicher.

Nachdem beide Systeme eine angemessene Zeit im Leerlauf waren, um sich zu stabilisieren, führen Sie Folgendes aus:

free -h
systemctl --type=service --state=running --no-pager

Beachten Sie die availableSpalte „Speicherverbrauch“ freesowie useddie Spalte „Speicherverbrauch“. Linux nutzt ansonsten ungenutzten Speicher für den Cache, der bei Bedarf von Anwendungen freigegeben werden kann. Ein niedrigerer Wert in der freeSpalte „Speicherverbrauch“ deutet nicht automatisch auf ein Problem hin. Prüfen Sie, ob der zusätzliche Speicherverbrauch auf Dienste zurückzuführen ist, die Sie tatsächlich weiterverwenden möchten.

3. Vergleichen Sie die Startzeiten und finden Sie langsame Dienste.

Verwenden Sie bei jedem Systemstart die mit der Distribution mitgelieferten systemd-Tools:

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

systemd-analyze timeDie angezeigten Startzeiten bedeuten nicht zwangsläufig, dass die Anwendung bereit ist, Anfragen entgegenzunehmen. Die blameListe kann zudem irreführend sein, da Einheiten parallel initialisiert werden können und manche Diensttypen nicht auf dieselbe Weise gemessen werden. Untersuchen Sie die kritische Kette und prüfen Sie anschließend separat den relevanten Dienstendpunkt. Diese Einschränkungen sind im Handbuch zu systemd-analyze unter Ubuntu 24.04 dokumentiert .

Wenn beispielsweise ein Server eine HTTP-API ausführt, messen Sie die Zeit vom Neustart bis zum erfolgreichen Erreichen des API-Integritätsendpunkts. Wenn ein Host eine Datenbank betreibt, prüfen Sie, ob eine Abfrage erfolgreich ist. Diese Bereitschaftsmessung ist aussagekräftiger als die Überprüfung, ob das Betriebssystem ein Startziel erreicht.

Anschließend werden CPU und Speicher unter kontrollierter Last getestet.

4. Führen Sie auf beiden Maschinen die gleiche CPU-Auslastung aus.

Für einen einfachen CPU-Vergleich installieren Sie auf jeder temporären VM eine identische Version von sysbench, nachdem Sie den Speicherbedarf der Neuinstallation erfasst haben. Führen Sie anschließend denselben Befehl aus:

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

Vergleichen Sie Ereignisse pro Sekunde und Latenz bei wiederholten Durchläufen. Die Dokumentation des Sysbench-Projekts enthält die Befehlssyntax und einen integrierten CPU-Test. Führen Sie einen zweiten Durchlauf mit derselben höheren Thread-Anzahl nur dann durch, wenn diese der zugewiesenen CPU-Anzahl entspricht. Ein reduzierter Paketsatz allein rechtfertigt keine Behauptung einer CPU-Beschleunigung; unerwartete Unterschiede sollten Anlass geben, die CPU-Auslastung des Hosts, das Taktverhalten, die Kernel-Version und Hintergrundprozesse zu überprüfen.

5. Testen der Festplatten-E/A ohne Benchmarking einer Produktionsfestplatte

Für ein optionales Speicherexperiment installieren Sie fio auf beiden Testrechnern und erstellen identische Testdateien auf einem temporären Dateisystem mit ausreichend freiem Speicherplatz. Die folgenden Befehle erstellen eine 256 MiB große Datei im Home-Verzeichnis des aktuellen Benutzers und führen anschließend eine begrenzte, zufällige Leselast auf diese Datei aus:

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

Führen Sie beide Maschinen mit identischen Festplatten und E/A-Parametern aus. Eine 256-MiB-Datei ist möglicherweise zu klein, um Ihre Datenbank oder Ihr Speichermedium präzise zu modellieren. Vergrößern Sie die Datei und variieren Sie die Arbeitslast nur, wenn ausreichend Speicherplatz und eine sichere Testumgebung vorhanden sind. Erfassen Sie die IOPS-, Bandbreiten- und Latenzverteilung, nicht nur den höchsten Bandbreitenwert. Die Arbeitslastparameter werden im Ubuntu 24.04 fio-Handbuch erläutert. Führen Sie Schreibtests niemals direkt auf einem Blockgerät durch, das Nutzdaten enthält.

6. Testen Sie zuletzt die eigentliche Anwendung.

Installieren Sie auf beiden Maschinen exakt denselben Anwendungsstack, einschließlich Web- und Datenbankversionen, Verbindungslimits, Protokollierung, TLS, Caching und Monitoring. Senden Sie von einem separaten Lastgenerator eine identische Anfragemenge mit derselben Parallelität und Testdauer. Messen Sie Durchsatz, mittlere und 95. Perzentil-Antwortlatenz, Fehlerrate, CPU-Auslastung, Speicherauslastung und Swapping. Verwenden Sie denselben Datensatz und stellen Sie sicher, dass keine der Maschinen ein ressourcenintensives Speichersystem nutzt, ohne mögliche Konflikte zu berücksichtigen.

Bei einem kleinen API-Server kann ein Unterschied im verfügbaren Arbeitsspeicher relevant sein, wenn eine Konfiguration unter Last mit dem Auslagern beginnt. Bei einem rechenintensiven Prozess mit ausreichend freiem Arbeitsspeicher kann dieselbe Anwendungsdatei hingegen einen nahezu identischen Durchsatz erzielen. Beide Ergebnisse lassen sich erst nach Tests mit Sicherheit sagen.

Wie man widersprüchliche Benchmark-Ergebnisse interpretiert

  • Weniger Softwarepakete, aber gleiche CPU-Leistung: Das ist völlig konsistent. Weniger installierte Tools müssen die Rechenleistung nicht beeinträchtigen.
  • Geringere Festplattenauslastung bei gleicher IOPS-Zahl: Freier Speicherplatz und Gerätegeschwindigkeit sind unterschiedliche Eigenschaften. Beachten Sie die Speicherhardware, das E/A-Muster, das Dateisystem und den Caching-Prozess.
  • Schnellerer Systemstart, aber ebenso langsame Anwendungsbereitschaft: Der Flaschenhals könnte der Anwendungsstart, Netzwerkabhängigkeiten oder die Datenbankwiederherstellung sein.
  • Weniger ungenutzter RAM bei gleicher Anfragelatenz: Minimiert bietet möglicherweise nützlichen Kapazitätsspielraum, die aktuelle Arbeitslast ist jedoch nicht speicherbeschränkt.
  • Stark schwankende Ergebnisse zwischen den Durchläufen: Untersuchen Sie Störfaktoren wie benachbarte Prozessoren, Skalierung der CPU-Frequenz, Aktualisierungen, geplante Aufgaben, thermische Drosselung und Cache-Erwärmung, bevor Sie einen Gewinner küren.

Wenn der gemessene Vorteil nur in einer geringen Menge ungenutzten Speicherplatzes besteht, Ihr Betriebsablauf aber wiederholt fehlende Verwaltungsprogramme benötigt, kann die Standardinstallation die produktivere Wahl sein. Werden Ihre Server automatisch bereitgestellt und führen sie einen klar definierten Dienst aus, erleichtert eine minimierte Basis oft die Überprüfung der Paketauswahl.

Sollte ein bestehender Server in den minimierten Modus versetzt werden?

In der Regel geht es nicht nur darum, Benchmark-Werte zu erreichen. Bei einer funktionierenden Standardinstallation sollten Sie zunächst die tatsächlich aktiven Dienste überprüfen und die Anwendung messen. Das Entfernen nicht benötigter Pakete verbessert eine bereits stabile Arbeitslast möglicherweise nicht, und das unbedachte Entfernen von Paketen kann Netzwerkfunktionen, Wiederherstellung, Protokollierung oder Fernverwaltung beeinträchtigen. Die Sicherheitsrichtlinien von Canonical für Ubuntu empfehlen, anstelle des wahllosen Entfernens von Standardpaketen eine möglichst minimale Startinstallation zu wählen.

Wenn eine Neuinstallation sinnvoll ist, sichern Sie Daten und Konfiguration, überprüfen Sie die Wiederherstellung, installieren Sie die minimierte Option auf einer neuen Instanz und stellen Sie die benötigten Pakete explizit bereit. Überprüfen Sie SSH-Zugriff, Updates, Zeitsynchronisierung, Backups, Überwachung, Firewall-Richtlinien und den Zustand der Anwendungen, bevor Sie den Datenverkehr verschieben. Wenn ein Administrator regelmäßig auf die mitgelieferten Diagnosetools oder verschiedene Rollen angewiesen ist, kann die Standardinstallation vorzuziehen sein, auch wenn sie bei einer Neuinstallation mehr Speicherplatz benötigt.

Sicherheit ist zwar verwandt, aber dennoch ein separates Thema: Weniger Pakete können den Wartungsaufwand verringern, beweisen aber nicht die Reduzierung bestimmter Sicherheitslücken (CVEs). Beide Installationsarten erfordern weiterhin Sicherheitsupdates und die Härtung der Dienste.

Checkliste zur abschließenden Überprüfung

  • Bitte vergewissern Sie sich, dass es sich bei beiden Maschinen um Ubuntu Server 24.04 LTS mit gleicher Architektur, gleichem Patch-Level, gleichem Kernel-Track und gleicher Installer-Generation handelt.
  • Dokumentieren Sie die Auswahl der Standard- oder Minimalversion, die optionalen Installationsoptionen und die nachträglich hinzugefügten Dienstleistungen.
  • Vergleichen Sie die Anzahl der Pakete, die Nutzung des Root-Dateisystems und den verfügbaren Speicher nach identischen Aktualisierungen und einer Eingewöhnungsphase im Leerlauf.
  • Wiederholte Messungen der Start- und Anwendungsbereitschaft über mehrere Neustarts hinweg, wobei Medianwerte anstelle eines einzelnen besten Durchlaufs ausgegeben werden.
  • Verwenden Sie passende Parameter für CPU-, Speicher- und Anwendungsworkloads und protokollieren Sie Fehler- und Latenzverteilungen.
  • Führen Sie die Anwendung mit identischen Abhängigkeiten, Konfigurationen und Daten aus und entscheiden Sie dann, ob sich etwaige Unterschiede auf Kapazität, Zuverlässigkeit oder Bereitstellungszeit auswirken.

Praktisches Fazit: Die minimierte Konfiguration bietet in der Regel den besseren Startwert für Server mit begrenztem Aufgabenbereich und Automatisierung; die Standardkonfiguration bietet einen umfassenderen Standard-Toolset. Keine der beiden Optionen ist generell schneller. Unter Ubuntu Server 24.04 LTS ist der aussagekräftigste Benchmark derjenige, der Ihren Dienst unter der tatsächlichen Arbeitslast misst.

Einen Kommentar hinterlassen

Ubuntu Server 24.04 Minimal vs. Standard: Leistungsvergleich im Detail

Ubuntu Server 24.04 Minimal vs. Standard: Leistungsvergleich im Detail

Vergleichen Sie die minimierte und die Standardinstallation von Ubuntu Server 24.04 hinsichtlich RAM, Festplattenspeicher, Bootzeit, CPU und realer Arbeitslasten – ohne irreführende Benchmark-Aussagen.

Tech-Enabled Senior Care in 2026: What AI and Smart Homes Can—and Can’t—Do for Aging in Place

Tech-Enabled Senior Care in 2026: What AI and Smart Homes Can—and Can’t—Do for Aging in Place

A practical 2026 guide to AI, smart-home sensors, remote monitoring, fall safety, privacy, and how technology can support aging in place without replacing care.

Datengestützte Stadtplanung: Nachhaltige und fußgängerfreundliche Smart Cities aufbauen

Datengestützte Stadtplanung: Nachhaltige und fußgängerfreundliche Smart Cities aufbauen

Erfahren Sie, wie Städte Mobilitäts-, Landnutzungs-, Klima- und Gemeindedaten in sicherere, grünere und fußgängerfreundlichere Viertel umwandeln können, ohne dabei die Technologie über die Menschen zu stellen.

Wo man 2026 UAV-Ingenieurwesen studieren kann: Die besten Luft- und Raumfahrtprogramme nach Karriereziel

Wo man 2026 UAV-Ingenieurwesen studieren kann: Die besten Luft- und Raumfahrtprogramme nach Karriereziel

Vergleichen Sie führende UAV- und Luft- und Raumfahrttechnikprogramme für Drohnen, Autonomie, Steuerung, UAS-Betrieb und Graduiertenforschung mit verifizierten Aktualisierungen von 2026.

KI-gestützte chirurgische Robotik: Ein praktischer Leitfaden zu Präzision, Autonomie und dem, was tatsächlich im OP passiert.

KI-gestützte chirurgische Robotik: Ein praktischer Leitfaden zu Präzision, Autonomie und dem, was tatsächlich im OP passiert.

Ein praktischer Leitfaden zur KI-gestützten chirurgischen Robotik: aktuelle Fähigkeiten, Autonomiegrade, Vorteile der Präzision, Grenzen, Regulierung und Bewertungskriterien.

CCUS im großen Stil: Kann die Kohlenstoffabscheidung die globalen Emissionen wirklich umkehren?

CCUS im großen Stil: Kann die Kohlenstoffabscheidung die globalen Emissionen wirklich umkehren?

Die Investitionen in CCUS steigen, aber kann die CO₂-Abscheidung die globalen Emissionen tatsächlich umkehren? Erfahren Sie, wo es funktioniert, welche Grenzen die Skalierung setzt und welche Beweise relevant sind.

Where to Study Cross-Border Digital Supply Chain Management: 7 Programs to Compare

Where to Study Cross-Border Digital Supply Chain Management: 7 Programs to Compare

Compare seven global programs for digital supply chains, logistics, analytics, global trade, and operations, with practical guidance on choosing the right fit.

Von der Science-Fiction zur Realität: Wie die BCI-Technologie Mobilität und Sprache wiederherstellt

Von der Science-Fiction zur Realität: Wie die BCI-Technologie Mobilität und Sprache wiederherstellt

Erfahren Sie, wie Gehirn-Computer-Schnittstellen neuronale Signale entschlüsseln, um Kommunikation und Bewegung wiederherzustellen, was aktuelle Studien erreicht haben und was den Einsatz von BCI noch einschränkt.

Die Anatomie kommerzieller Drohnen: Hardware-Durchbrüche und autonomer Flug

Die Anatomie kommerzieller Drohnen: Hardware-Durchbrüche und autonomer Flug

Erfahren Sie, wie kommerzielle Drohnen Sensoren, Edge-KI, Batterien, Kommunikationssysteme und Flugsteuerungssoftware kombinieren – und wo die Autonomie noch immer von der Mission und den Vorschriften abhängt.

Where Should You Study Energy Storage Engineering? 7 Battery Tech Programs Compared

Where Should You Study Energy Storage Engineering? 7 Battery Tech Programs Compared

Compare seven strong battery and energy storage master's options by materials, systems, research, industry exposure, flexibility, language, and cost trade-offs.