Ubuntu Server 24.04 Minimal vs Standard: Performance Benchmarks Explained

A virtual private server feels tight on memory, so you reinstall Ubuntu Server 24.04 LTS and face an early choice: the default Ubuntu Server installation or Ubuntu Server (minimized). It is tempting to assume that fewer packages automatically mean faster web requests, shorter database queries, and higher CPU throughput. The difference is more nuanced. A smaller starting package set can reduce disk use and background activity, but it does not, by itself, make the processor or storage device faster.

Bottom line: Choose the minimized installation when you want a lean starting point and are comfortable adding only the tools you need. Choose standard when you want the broader default server toolset. Compare boot time, idle memory, disk footprint, and actual application performance separately rather than collapsing them into a single "faster" label.

Evidence note (October 9, 2026): This article explains a reproducible benchmarking method and the results each metric can establish. It does not present original measured scores from two matched Ubuntu 24.04 installations. No unverified RAM, disk, boot-time, or throughput figures are represented as test findings.

What is the difference between standard and minimized Ubuntu Server?

Ubuntu Server's Subiquity installer offers two installation sources: ubuntu-server for standard (the default) and ubuntu-server-minimal for minimized. Canonical documents these source identifiers and advises checking casper/install-sources.yaml on the chosen ISO because installer identifiers can change. See the Canonical Subiquity autoinstall source documentation.

Both are Ubuntu Server 24.04 LTS, not two differently optimized CPU architectures or separate Linux distributions. What primarily changes is the software delivered at installation time. Exactly which packages appear depends on the installation media revision, optional choices, updates, drivers, and subsequently installed applications. Do not assume that a list published for one image build applies unchanged to every 24.04 point-release installer.

The minimized server option should not be confused with minimal Ubuntu cloud images, a separate image family, or with the Ubuntu Desktop minimal-install option. The Ubuntu 24.04 LTS release notes discuss a substantial reduction in the package count and downloadable size of minimal cloud images relative to earlier releases. Those published cloud-image examples are not a controlled standard-versus-minimized live-server ISO benchmark, and their numbers should not be reused as if they were.

Which performance benchmarks matter?

Expected behavior is not a measured result. A minimized machine may consume fewer resources immediately after installation. But once both machines run the same database, container runtime, monitoring agent, and web server, the observed gap may shrink, disappear, or change direction. The only defensible conclusion comes from measuring the target workload.

Start with a fair test setup, not a stopwatch

Build two disposable virtual machines from the same Ubuntu Server 24.04 LTS ISO revision, one standard and one minimized. Assign identical vCPU counts, RAM, virtual disks, filesystems, boot mode, hypervisor settings, network attachment, and storage class. For physical machines, use equivalent hardware and test under similar thermal and power conditions. Keep the machines off production traffic.

On both systems, apply the same security updates and reboot. Record cat /etc/os-release, uname -r, and lscpu, plus the installer image version and test date. Ubuntu Server 24.04 normally uses the general-availability kernel track but can optionally use Hardware Enablement kernels; different kernel tracks would compromise an installation-type-only comparison. The Ubuntu kernel documentation on GA and HWE kernels explain this distinction.

Collect two sets of measurements:

1. Configuration de référence après installation : Immédiatement après des mises à jour identiques, avant l’installation d’une charge de travail. Cela permet d’isoler les différences pratiques dans les paramètres d’installation par défaut.
2. Configuration de référence en conditions de production : après installation des mêmes applications, activation des mêmes services et application de configurations identiques, on peut déterminer si la différence d’empreinte initiale a encore une incidence.

Effectuez au moins plusieurs essais par test, idéalement cinq ou plus après une période de préchauffage, et comparez les médianes ainsi que la variabilité. Redémarrez le système et mesurez le temps de démarrage sur plusieurs redémarrages. Ne comparez jamais un résultat de démarrage à froid sur un système avec un résultat obtenu après un démarrage à chaud sur l'autre.

Commencez par mesurer les différences les plus faciles.

1. Comptez les paquets installés et vérifiez l'espace disque.

Le nombre de paquets et l'utilisation du stockage sont généralement les caractéristiques les plus simples à examiner. Sur chaque machine virtuelle, exécutez :

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

Notez le nombre de partitions, l'espace utilisé sur le système de fichiers racine et son organisation. Assurez-vous que les partitions racine ont des tailles comparables ; sinon, une différence apparente peut provenir du partitionnement. L'utilisation du disque inclut également les journaux, les caches de paquets et les métadonnées du système de fichiers ; par conséquent, des dates d'installation identiques et des historiques de mises à jour comparables sont importants.

2. Comparez la RAM disponible, et non seulement la RAM « libre ».

Une fois que les deux systèmes sont restés inactifs pendant une période de stabilisation constante, exécutez :

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

Examinez la availablecolonne correspondante free. usedLinux utilise la mémoire inactive comme cache, qui peut être récupérée lorsque les applications en ont besoin. Une valeur plus faible dans cette freecolonne n'indique pas automatiquement un problème. Vérifiez si l'utilisation de mémoire supplémentaire est liée à des services que vous souhaitez conserver.

3. Comparez le temps de démarrage et identifiez les services lents.

Pour chaque démarrage, utilisez les outils systemd fournis avec la distribution :

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

systemd-analyze timeLe rapport indique le temps d'initialisation, mais cela ne signifie pas nécessairement que l'application est prête à recevoir des requêtes. La blameliste peut également être trompeuse, car les unités peuvent s'initialiser en parallèle et certains types de services ne sont pas mesurés de la même manière. Examinez la chaîne critique, puis vérifiez séparément le point de terminaison précis du service qui vous intéresse. Ces limitations sont documentées dans le manuel de systemd-analyze d'Ubuntu 24.04 .

Par exemple, si un serveur exécute une API HTTP, mesurez le temps écoulé entre le redémarrage et la réussite de l'accès à l'API. Si un hôte exécute une base de données, vérifiez qu'une requête aboutit. Cette mesure de disponibilité est plus exploitable que la simple vérification que le système d'exploitation atteigne une cible de démarrage.

Testez ensuite le processeur et le stockage sous charge contrôlée.

4. Exécutez la même charge de travail du processeur sur les deux machines.

Pour une comparaison simple des processeurs, installez une version identique de sysbench sur chaque machine virtuelle jetable après avoir enregistré l'empreinte mémoire de l'installation initiale. Exécutez ensuite la même commande :

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

Comparez le nombre d'événements par seconde et la latence lors d'exécutions répétées. La documentation du projet sysbench fournit la syntaxe des commandes et le test CPU intégré. N'effectuez une seconde exécution avec un nombre de threads plus élevé que si cela est compatible avec le nombre de cœurs CPU alloué. Une réduction du nombre de paquets ne justifie pas à elle seule d'affirmer un gain de vitesse du processeur ; des différences inattendues doivent inciter à vérifier la contention du processeur hôte, le comportement de l'horloge, la version du noyau et les processus en arrière-plan.

5. Tester les E/S disque sans utiliser un disque de production comme référence

Pour une expérience de stockage optionnelle, installez fio sur les deux machines de test et créez des fichiers de test identiques sur un système de fichiers éphémère disposant d'un espace libre suffisant. Les commandes suivantes créent un fichier de 256 Mio dans le répertoire personnel de l'utilisateur actuel, puis exécutent une charge de travail de lecture aléatoire limitée sur ce fichier :

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

Exécutez les deux machines avec des disques et des paramètres d'E/S identiques. Un fichier de 256 Mio peut s'avérer insuffisant pour modéliser précisément votre base de données ou votre périphérique de stockage ; augmentez sa taille et modifiez la charge de travail uniquement si vous disposez d'un espace de travail suffisant et d'un environnement de test sécurisé. Enregistrez les IOPS, la bande passante et la distribution de la latence, et non pas seulement la valeur de bande passante maximale. Le manuel fio d'Ubuntu 24.04 explique les paramètres de charge de travail. Ne dirigez jamais les tests d'écriture vers un périphérique de stockage bloc contenant des données utiles.

6. Testez l'application réelle en dernier.

Installez exactement la même pile applicative sur les deux machines, y compris les versions web et de base de données, les limites de connexion, la journalisation, le protocole TLS, la mise en cache et la surveillance. Envoyez un mélange de requêtes équivalent depuis un générateur de charge distinct, avec la même concurrence et la même durée de test. Mesurez le débit, la latence de réponse médiane et au 95e percentile, le taux d'erreur, l'utilisation du processeur, la pression sur la mémoire et le recours à la pagination. Utilisez le même jeu de données et assurez-vous qu'aucune des deux machines ne partage un système de stockage saturé sans tenir compte des conflits d'accès.

Pour un petit serveur API, une différence de mémoire inactive a son importance si une configuration commence à utiliser la mémoire virtuelle pendant la charge. Pour un nœud de calcul gourmand en ressources CPU et disposant de beaucoup de RAM disponible, le même binaire d'application peut offrir un débit sensiblement identique. Aucun de ces résultats ne peut être affirmé avant des tests.

Comment interpréter des résultats de référence contradictoires

• Moins de paquets installés mais des scores CPU identiques : c’est parfaitement cohérent. Moins d’outils installés n’ont pas forcément d’incidence sur les performances de calcul.
• Utilisation disque réduite mais IOPS identiques : l’espace libre et la vitesse du périphérique sont deux propriétés distinctes. Examinez le matériel de stockage, le modèle d’E/S, le système de fichiers et la mise en cache.
• Démarrage systemd plus rapide, mais préparation des applications tout aussi lente : le goulot d’étranglement peut provenir du démarrage de l’application, des dépendances réseau ou de la récupération de la base de données.
• Moins de RAM inactive mais une latence de requête identique : la mémoire réduite peut offrir une marge de manœuvre utile, mais la charge de travail actuelle n’est pas limitée par la mémoire.
• Des scores très variables d'une exécution à l'autre : examinez les processus voisins bruyants, la mise à l'échelle de la fréquence du processeur, les mises à jour, les tâches planifiées, la limitation thermique et le réchauffement du cache avant de déclarer un vainqueur.

Si le gain constaté se limite à un espace disque inutilisé minime, mais que votre flux de travail opérationnel nécessite régulièrement des utilitaires d'administration manquants, l'installation standard peut s'avérer plus productive. Si vos serveurs sont provisionnés automatiquement et exécutent un service bien défini, une installation minimale facilite souvent l'audit du choix des paquets.

Faut-il réduire au minimum un serveur existant ?

Il est généralement déconseillé de supprimer des paquets uniquement pour atteindre des performances de référence. Pour une installation standard fonctionnelle, il est préférable d'examiner d'abord les services actifs et de mesurer l'application. Supprimer des paquets non pertinents n'améliorera pas forcément une charge de travail déjà stable, et une suppression imprudente peut perturber le réseau, la récupération, la journalisation ou la gestion à distance. Les recommandations de sécurité de Canonical pour Ubuntu concernant les paquets inutiles préconisent de choisir une installation minimale appropriée plutôt que de supprimer systématiquement les paquets par défaut.

Si une reconstruction est justifiée, sauvegardez les données et la configuration, vérifiez la restauration, installez l'option minimale sur une nouvelle instance et provisionnez explicitement les paquets nécessaires. Validez l'accès SSH, les mises à jour, la synchronisation horaire, les sauvegardes, la surveillance, la politique de pare-feu et l'état des applications avant de rediriger le trafic. Si un administrateur utilise régulièrement les outils de diagnostic intégrés ou occupe différents rôles, l'installation standard peut être préférable, même si elle est plus gourmande en ressources.

La sécurité est un aspect lié à la sécurité, mais distinct : un nombre réduit de paquets peut diminuer la quantité de logiciels à maintenir, mais cela ne garantit pas une réduction spécifique des vulnérabilités CVE. Les deux types d’installation nécessitent toujours des mises à jour de sécurité et un renforcement des services.

Liste de vérification finale

• Vérifiez que les deux machines sont Ubuntu Server 24.04 LTS avec la même architecture, le même niveau de correctif, la même branche du noyau et la même génération d'installateur.
• Documentez le choix de la configuration standard ou minimale, les options d'installation et les services ajoutés ultérieurement.
• Comparez le nombre de paquets, l'utilisation du système de fichiers racine et la mémoire disponible après des mises à jour identiques et une période de stabilisation inactive.
• Effectuer des mesures répétées du démarrage et de la disponibilité des applications sur plusieurs redémarrages, en indiquant les médianes plutôt qu'une seule meilleure performance.
• Utilisez des paramètres correspondants pour les charges de travail du processeur, du stockage et des applications, et enregistrez les erreurs et les distributions de latence.
• Exécutez l'application avec des dépendances, une configuration et des données identiques, puis déterminez si une différence quelconque affecte la capacité, la fiabilité ou le temps de déploiement.

Conclusion pratique : l’ option « Minimisée » est généralement la plus adaptée pour les serveurs automatisés à périmètre restreint ; l’option « Standard » offre un ensemble d’outils par défaut plus complet. Aucune des deux options n’est systématiquement plus rapide. Sur Ubuntu Server 24.04 LTS, le test de performance le plus pertinent est celui qui mesure les performances de votre service dans les conditions réelles de charge de travail.