Ubuntu Server 24.04 Minimal versus Standard: Prestatiebenchmarks uitgelegd

Een virtuele privéserver heeft vaak weinig geheugen, dus installeer je Ubuntu Server 24.04 LTS opnieuw en sta je al snel voor een keuze: de standaard Ubuntu Server-installatie of Ubuntu Server (geminimaliseerd). Het is verleidelijk om aan te nemen dat minder pakketten automatisch snellere webverzoeken, kortere databasequery's en een hogere CPU-doorvoer betekenen. Het verschil is echter subtieler. Een kleinere set startpakketten kan het schijfgebruik en de achtergrondactiviteit verminderen, maar maakt de processor of het opslagapparaat op zich niet sneller.

Kortom: kies voor de minimale installatie als u een uitgeklede basis wilt en alleen de benodigde tools wilt toevoegen. Kies voor de standaardinstallatie als u de uitgebreidere standaardset servertools wilt. Vergelijk de opstarttijd, het geheugenverbruik in ruststand, de schijfruimte en de daadwerkelijke applicatieprestaties afzonderlijk, in plaats van ze samen te voegen tot één label 'sneller'.

Toelichting (9 oktober 2026): Dit artikel beschrijft een reproduceerbare benchmarkmethode en de resultaten die elke meetwaarde kan opleveren. Het presenteert geen originele meetwaarden van twee identieke Ubuntu 24.04-installaties. Er worden geen niet-geverifieerde cijfers over RAM, schijfgebruik, opstarttijd of doorvoersnelheid als testresultaten weergegeven.

Wat is het verschil tussen de standaard en de geminimaliseerde versie van Ubuntu Server?

De Subiquity-installer van Ubuntu Server biedt twee installatiebronnen: ubuntu-servereen standaardinstallatie (de standaardinstelling) en ubuntu-server-minimaleen geminimaliseerde installatie. Canonical documenteert deze bron-ID's en adviseert om casper/install-sources.yamlde gekozen ISO te controleren, omdat de installatie-ID's kunnen veranderen. Zie de Canonical Subiquity autoinstall source-documentatie .

Beide versies draaien om Ubuntu Server 24.04 LTS, niet om twee verschillend geoptimaliseerde CPU-architecturen of aparte Linux-distributies. Wat vooral verschilt, is de software die tijdens de installatie wordt meegeleverd. Welke pakketten precies worden meegeleverd, hangt af van de revisie van het installatiemedium, optionele keuzes, updates, stuurprogramma's en later geïnstalleerde applicaties. Ga er niet vanuit dat een lijst die voor één image-build is gepubliceerd, ongewijzigd van toepassing is op elke point-release-installer van 24.04.

De optie voor een geminimaliseerde server moet niet worden verward met minimale Ubuntu-cloudimages , een aparte imagefamilie, of met de minimale installatieoptie voor Ubuntu Desktop. In de release-opmerkingen van Ubuntu 24.04 LTS wordt een aanzienlijke vermindering van het aantal pakketten en de downloadgrootte van minimale cloudimages besproken ten opzichte van eerdere releases. De gepubliceerde voorbeelden van cloudimages zijn geen gecontroleerde benchmark voor standaard versus geminimaliseerde live-server ISO's, en hun cijfers mogen niet als zodanig worden hergebruikt.

Welke prestatiebenchmarks zijn belangrijk?

Verwacht gedrag is geen meetbaar resultaat. Een geminimaliseerde machine verbruikt mogelijk direct na installatie minder resources. Maar zodra beide machines dezelfde database, container runtime, monitoring agent en webserver draaien, kan het waargenomen verschil kleiner worden, verdwijnen of van richting veranderen. De enige verdedigbare conclusie kan worden getrokken door de beoogde workload te meten.

Begin met een eerlijke testopstelling, niet met een stopwatch.

Maak twee virtuele machines voor eenmalig gebruik aan met dezelfde Ubuntu Server 24.04 LTS ISO-revisie, één standaard en één geminimaliseerde versie. Wijs identieke aantallen vCPU's, RAM, virtuele schijven, bestandssystemen, opstartmodus, hypervisorinstellingen, netwerkverbinding en opslagklasse toe. Gebruik voor de fysieke machines equivalente hardware en test onder vergelijkbare thermische en stroomomstandigheden. Houd de machines buiten het productieverkeer.

Voer op beide systemen dezelfde beveiligingsupdates uit en herstart de systemen. Noteer cat /etc/os-release, uname -r, en lscpu, plus de versie van de installatie-image en de testdatum. Ubuntu Server 24.04 gebruikt normaal gesproken de algemeen beschikbare kernelversie, maar kan optioneel Hardware Enablement-kernels gebruiken; verschillende kernelversies zouden een vergelijking op basis van alleen het installatietype bemoeilijken. De Ubuntu-kerneldocumentatie over GA- en HWE-kernels legt dit onderscheid uit.

Verzamel twee sets metingen:

1. Basislijn na een schone installatie: Direct na identieke updates, vóór het installeren van een workload. Dit isoleert de praktische verschillen in de standaardinstallatie-instellingen.
2. Productie-achtige basislijn: Na het installeren van dezelfde applicatiepakketten, het inschakelen van dezelfde services en het toepassen van identieke configuraties. Dit laat zien of het aanvankelijke verschil in footprint nog steeds van belang is.

Gebruik minstens meerdere runs per test, bij voorkeur vijf of meer na een opwarmperiode, en vergelijk zowel de medianen als de variabiliteit. Herstart de computer en meet de opstarttijd bij meerdere opstartpogingen. Vergelijk nooit een resultaat van een koude opstart op het ene systeem met een resultaat van een reeds opgewarmd systeem op het andere.

Meet eerst de gemakkelijk te herkennen verschillen.

1. Tel het aantal geïnstalleerde pakketten en controleer de schijfruimte.

Het aantal pakketten en het opslaggebruik zijn doorgaans de meest eenvoudige kenmerken om te controleren. Voer op elke VM het volgende commando uit:

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

Noteer het aantal partities, de gebruikte ruimte op het rootbestandssysteem en de indeling van het bestandssysteem. Zorg ervoor dat de rootpartities vergelijkbare groottes hebben; anders kan een ogenschijnlijk verschil ontstaan ​​door de partitionering. Schijfgebruik omvat ook logbestanden, pakketcaches en metadata van het bestandssysteem, dus identieke installatietijden en vergelijkbare updategeschiedenissen zijn van belang.

2. Vergelijk het beschikbare RAM-geheugen, niet alleen het "vrije" RAM-geheugen.

Nadat beide systemen gedurende een consistente periode inactief zijn geweest, voert u het volgende commando uit:

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

Kijk ook naar de availablekolom in en . Linux gebruikt anders ongebruikt geheugen voor de cache, dat kan worden vrijgemaakt wanneer applicaties het nodig hebben. Een kleinere waarde in de kolom duidt niet automatisch op een probleem. Controleer of het extra geheugengebruik toebehoort aan services die u daadwerkelijk wilt blijven gebruiken.freeusedfree

3. Vergelijk de opstarttijd en spoor trage services op.

Gebruik bij elke opstart de systemd-tools die bij de distributie worden geleverd:

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

systemd-analyze timeHet rapport geeft de timing van de opstartfase weer, maar dat betekent niet noodzakelijkerwijs dat de applicatie klaar is om verzoeken te accepteren. De blamelijst kan ook misleidend zijn, omdat eenheden parallel kunnen initialiseren en sommige servicetypen niet op dezelfde manier worden gemeten. Onderzoek de kritieke keten en controleer vervolgens afzonderlijk het specifieke service-eindpunt dat voor u relevant is. Deze beperkingen worden beschreven in de handleiding van Ubuntu 24.04 systemd-analyze .

Als een server bijvoorbeeld een HTTP API uitvoert, meet dan de tijd vanaf het moment van herstart tot het moment dat het API-status-eindpunt succesvol is. Als een host een database draait, controleer dan of een query succesvol is. Deze gereedheidsmeting is bruikbaarder dan het moment waarop het besturingssysteem een ​​opstartdoel bereikt.

Test vervolgens de CPU en het geheugen onder gecontroleerde belasting.

4. Voer dezelfde CPU-belasting uit op beide machines.

Voor een eenvoudige CPU-vergelijking installeert u een identieke versie van sysbench op elke tijdelijke VM nadat u de footprint van de schone installatie hebt vastgelegd. Voer vervolgens hetzelfde commando uit:

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

Vergelijk het aantal gebeurtenissen per seconde en de latentie bij herhaalde uitvoeringen. De documentatie van het sysbench-project bevat de commandosyntaxis en de ingebouwde CPU-test. Voer een tweede test met hetzelfde hogere aantal threads alleen uit als dit binnen het toegewezen aantal CPU's past. Een gereduceerde pakketset alleen rechtvaardigt niet de bewering van een snellere CPU-belasting; onverwachte verschillen moeten aanleiding geven tot een controle van de CPU-belasting van de host, het klokgedrag, de kernelversie en achtergrondprocessen.

5. Test de schijf-I/O zonder een productieschijf te benchmarken.

Voor een optioneel opslagexperiment installeert u fio op beide testmachines en maakt u identieke testbestanden aan op een tijdelijk bestandssysteem met voldoende vrije ruimte. De volgende commando's maken een bestand van 256 MiB aan in de thuismap van de huidige gebruiker en voeren vervolgens een workload met beperkte willekeurige leesbewerkingen uit op dat bestand:

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

Gebruik op beide machines identieke schijven en I/O-parameters. Een bestand van 256 MiB is mogelijk te klein om uw database of opslagapparaat nauwkeurig te modelleren; vergroot het bestand en varieer de werkbelasting alleen wanneer er voldoende tijdelijke opslagruimte en een veilige testomgeving beschikbaar zijn. Registreer de IOPS, bandbreedte en latentieverdeling, niet alleen de hoogste bandbreedtewaarde. De Ubuntu 24.04 fio-handleiding legt de werkbelastingparameters uit. Voer nooit schrijftests uit op een onbewerkt blokapparaat dat nuttige gegevens bevat.

6. Test de daadwerkelijke applicatie als laatste.

Installeer exact dezelfde applicatiestack op beide machines, inclusief web- of databaseversies, verbindingslimieten, logging, TLS, caching en monitoring. Verstuur een equivalente mix van verzoeken vanuit een aparte loadgenerator, met dezelfde gelijktijdigheid en testduur. Meet de doorvoer, de mediane en 95e percentiel responslatentie, het foutenpercentage, het CPU-gebruik, de geheugendruk en het swapping-gebruik. Gebruik dezelfde dataset en zorg ervoor dat geen van beide machines een luidruchtige opslagbackend deelt zonder rekening te houden met concurrentie.

Voor een kleine API-server is een verschil in ongebruikt geheugen van belang als een bepaalde configuratie tijdens belasting begint te swappen. Voor een CPU-intensieve worker met veel vrij RAM-geheugen kan hetzelfde applicatiebestand in principe dezelfde doorvoer leveren. Geen van beide uitkomsten kan echter met zekerheid worden vastgesteld vóórdat ze zijn getest.

Hoe tegenstrijdige benchmarkresultaten te interpreteren

• Minder geïnstalleerde programma's, maar gelijke CPU-prestaties: Dit is volkomen consistent. Minder geïnstalleerde programma's hoeven de rekenprestaties niet te beïnvloeden.
• Lager schijfgebruik maar gelijke IOPS: Vrije ruimte en apparaatsnelheid zijn verschillende eigenschappen. Kijk naar de opslaghardware, het I/O-patroon, het bestandssysteem en de caching.
• Snellere systemd-opstarttijd, maar even trage applicatiegereedheid: de bottleneck kan de applicatie-opstart, netwerkafhankelijkheden of databaseherstel zijn.
• Minder ongebruikt RAM-geheugen, maar gelijke aanvraaglatentie: Minimalisatie kan nuttige capaciteitsruimte opleveren, terwijl de huidige werkbelasting niet door het geheugen wordt beperkt.
• Sterk wisselende scores tussen runs: Onderzoek storende factoren zoals lawaaierige buren, CPU-frequentieschaling, updates, geplande taken, thermische throttling en cache-opwarming voordat u een winnaar aanwijst.

Als het gemeten voordeel slechts een kleine hoeveelheid ongebruikte schijfruimte is, maar uw operationele workflow herhaaldelijk ontbrekende beheertools vereist, kan de standaardinstallatie de productievere keuze zijn. Als uw servers automatisch worden geconfigureerd en een strikt gedefinieerde service uitvoeren, maakt een geminimaliseerde basisinstallatie de pakketselectie vaak eenvoudiger te controleren.

Moet je een bestaande server naar de geminimaliseerde modus overschakelen?

Meestal gaat het niet alleen om het behalen van benchmarkcijfers. Voor een goed werkende standaardinstallatie is het belangrijk om eerst de daadwerkelijk actieve services te inspecteren en de applicatie te meten. Het verwijderen van niet-relevante pakketten verbetert een reeds gezonde werkbelasting mogelijk niet, en onzorgvuldig verwijderen van pakketten kan netwerkproblemen, herstelproblemen, logboekregistratie of beheer op afstand veroorzaken. Canonical adviseert in haar Ubuntu-beveiligingsrichtlijnen voor onnodige pakketten om te kiezen voor een minimale basisinstallatie in plaats van lukraak standaardpakketten te verwijderen.

Als een herinstallatie zinvol is, maak dan een back-up van de gegevens en configuratie, controleer het herstel, installeer de geminimaliseerde optie op een nieuwe instantie en configureer expliciet de benodigde pakketten. Valideer de SSH-toegang, updates, tijdssynchronisatie, back-ups, monitoring, firewallbeleid en de status van de applicatie voordat u verkeer verplaatst. Als een beheerder regelmatig gebruikmaakt van meegeleverde diagnostische tools of verschillende rollen, kan de standaardinstallatie de voorkeur hebben, zelfs als deze een grotere footprint heeft.

Beveiliging is weliswaar gerelateerd, maar toch een apart aspect: minder pakketten kunnen de hoeveelheid software die u moet onderhouden verminderen, maar dit is geen bewijs voor een specifieke vermindering van CVE's. Beide installatietypen vereisen nog steeds beveiligingsupdates en het versterken van de service.

Definitieve verificatiechecklist

• Controleer of beide machines Ubuntu Server 24.04 LTS draaien met dezelfde architectuur, patchniveau, kernelversie en installatieprogrammageneratie.
• Documenteer de keuze voor de standaard- of geminimaliseerde versie, de optionele installatieopties en de later toegevoegde services.
• Vergelijk het aantal pakketten, het gebruik van het rootbestandssysteem en het beschikbare geheugen na identieke updates en een inactiviteitsperiode.
• Voer herhaalde metingen uit van het opstartproces en de gereedheid van applicaties gedurende meerdere herstarts, waarbij de mediaan in plaats van de beste waarde wordt gerapporteerd.
• Gebruik overeenkomende parameters voor CPU-, opslag- en applicatieworkloads en registreer fouten en latentieverdelingen.
• Voer de applicatie uit met identieke afhankelijkheden, configuratie en gegevens, en bepaal vervolgens of eventuele verschillen van invloed zijn op de capaciteit, betrouwbaarheid of implementatietijd.

Praktische conclusie: De geminimaliseerde configuratie is doorgaans de betere basisconfiguratie voor geautomatiseerde servers met een beperkte reikwijdte; de ​​standaardconfiguratie biedt een uitgebreidere standaardset aan tools. Geen van beide opties is universeel sneller. Op Ubuntu Server 24.04 LTS is de meest bruikbare benchmark diegene die uw service meet onder de daadwerkelijke werkbelasting die deze moet verwerken.