Un serveur privé virtuel (VPS) consomme peu de mémoire, vous réinstallez donc Ubuntu Server 24.04 LTS et vous vous retrouvez rapidement face à un choix : l’installation par défaut d’Ubuntu Server ou Ubuntu Server (minimisé). Il est tentant de penser que moins de paquets signifient automatiquement des requêtes web plus rapides, des requêtes de base de données plus courtes et un débit CPU plus élevé. La différence est plus nuancée. Un ensemble de paquets initial plus restreint peut réduire l’utilisation du disque et l’activité en arrière-plan, mais cela n’améliore pas, en soi, la vitesse du processeur ou du périphérique de stockage.
En résumé : choisissez l’installation minimale si vous souhaitez une configuration minimale et que vous n’avez pas de problème à ajouter uniquement les outils nécessaires. Choisissez l’installation standard si vous préférez bénéficier de l’ensemble des outils serveur par défaut. Comparez séparément le temps de démarrage, la mémoire inactive, l’espace disque utilisé et les performances réelles des applications plutôt que de les regrouper sous l’appellation « plus rapide ».
Note de preuve (9 octobre 2026) : Cet article décrit une méthode d’évaluation comparative reproductible et les résultats que chaque métrique peut fournir. Il ne présente pas les scores mesurés à partir de deux installations Ubuntu 24.04 identiques. Les données non vérifiées concernant la RAM, le disque, le temps de démarrage ou le débit ne sont pas présentées comme résultats de test.
L'installateur Subiquity d'Ubuntu Server propose deux sources d'installation : ubuntu-serverune standard (par défaut) et ubuntu-server-minimalune minimale. Canonical documente ces identifiants et recommande de les vérifier casper/install-sources.yamlsur l'ISO choisi, car ils peuvent changer. Consultez la documentation de Canonical sur les sources d'installation automatique de Subiquity .
Il s'agit dans les deux cas d'Ubuntu Server 24.04 LTS, et non de deux architectures CPU optimisées différemment ou de distributions Linux distinctes. La principale différence réside dans les logiciels fournis lors de l'installation. Les paquets présents dépendent de la révision du support d'installation, des options choisies, des mises à jour, des pilotes et des applications installées ultérieurement. Ne considérez pas qu'une liste publiée pour une image système donnée s'applique à toutes les versions mineures d'Ubuntu Server 24.04.
L'option de serveur minimal ne doit pas être confondue avec les images cloud Ubuntu minimales (une famille d'images distincte) ni avec l'option d'installation minimale d'Ubuntu Desktop. Les notes de version d'Ubuntu 24.04 LTS mentionnent une réduction significative du nombre de paquets et de la taille téléchargeable des images cloud minimales par rapport aux versions précédentes. Les exemples d'images cloud publiés ne constituent pas un test comparatif contrôlé entre une image ISO standard et une image minimale pour serveur live, et leurs résultats ne doivent pas être utilisés comme tels.
| Métrique | Ce qui est minimisé pourrait changer | Que vous révèle réellement ce chiffre ? |
|---|---|---|
| Nombre de paquets installés | Généralement, moins de paquets sont nécessaires avant d'ajouter votre charge de travail. | Empreinte de maintenance, et non vitesse de traitement |
| Espace disque utilisé | Le système de base occupe potentiellement moins d'espace. | Capacité disponible ; et non IOPS disque ou latence |
| Mémoire inactive disponible | Avantage potentiel si moins de services en arrière-plan sont actifs | Marge disponible pour le cache de l'application et du système de fichiers |
| Temps de démarrage et de disponibilité pour le service | La situation pourrait s'améliorer si moins d'emplois de start-up se trouvaient sur le chemin critique. | Délai de remise en service d'un serveur après redémarrage |
| Benchmark CPU uniquement | Aucun gain de performance intrinsèque suite à la suppression de paquets non liés | Principalement des conditions relatives au processeur, au noyau, au planificateur, à l'état d'alimentation et aux tests de performance |
| Benchmark d'E/S de stockage | Aucune amélioration garantie sur le même appareil et le même système de fichiers | Bande passante, IOPS et latence spécifiques à la charge de travail |
| Temps de réponse de l'application | Cela dépend des processus actifs, de la mémoire disponible et de la configuration. | Ce qui compte pour les utilisateurs réels sous une charge comparable |
Le comportement attendu ne correspond pas nécessairement au résultat mesuré. Une machine aux ressources minimales peut consommer moins de ressources immédiatement après son installation. Cependant, une fois que les deux machines exécutent la même base de données, le même environnement d'exécution de conteneurs, le même agent de surveillance et le même serveur web, l'écart observé peut se réduire, disparaître ou s'inverser. Seule la mesure de la charge de travail cible permet de tirer une conclusion valable.
Créez deux machines virtuelles jetables à partir de la même image ISO d'Ubuntu Server 24.04 LTS : une version standard et une version allégée. Attribuez-leur le même nombre de vCPU, la même quantité de RAM, les mêmes disques virtuels, les mêmes systèmes de fichiers, le même mode de démarrage, les mêmes paramètres d'hyperviseur, la même connexion réseau et la même classe de stockage. Pour les machines physiques, utilisez du matériel équivalent et effectuez les tests dans des conditions thermiques et d'alimentation similaires. Assurez-vous que ces machines ne sont pas utilisées en production.
Sur les deux systèmes, appliquez les mêmes mises à jour de sécurité et redémarrez. Notez les valeurs de cat /etc/os-release, uname -r, et lscpu, ainsi que la version de l'image d'installation et la date du test. Ubuntu Server 24.04 utilise normalement le noyau standard, mais peut également utiliser des noyaux compatibles avec l'activation matérielle (HWE). L'utilisation de noyaux différents fausserait une comparaison basée uniquement sur le type d'installation. La documentation du noyau Ubuntu relative aux noyaux GA et HWE explique cette distinction.
Recueillez deux séries de mesures :
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.
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 -fNotez 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 ; il est donc important que les dates d'installation soient identiques et que l'historique des mises à jour soit comparable.
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-pagerExaminez 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.
Pour chaque démarrage, utilisez les outils systemd fournis avec la distribution :
systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chainsystemd-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.
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 runComparez 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.
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_reportingExé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.
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.
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.
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 liée à la sécurité, mais reste un sujet 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.
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.
Identifiez les incohérences de formules liées à la syntaxe, aux séparateurs régionaux, aux recalculs, aux systèmes de dates ou aux fonctions non prises en charge, puis vérifiez le classeur avant de le partager.
Voyez ce que les données des versions récentes peuvent — et ne peuvent pas — prouver, puis comparez les deux suites bureautiques sur les mêmes fichiers et le même ordinateur.
Comparez les correspondances exactes, les recherches à gauche, la gestion des valeurs manquantes et la prise en charge des versions afin de choisir une formule Calc fiable.
Découvrez comment les styles de page de Writer et les liens de section de Word affectent les pages de couverture, les chiffres romains et les redémarrages de la numérotation lorsque vous déplacez un document.
Comparez Pardus Software Center aux commandes APT pour trouver, installer, supprimer et mettre à jour des paquets en utilisant la méthode qui convient à votre tâche.
Découvrez la signification des exigences de RAM publiées par Pardus, puis comparez XFCE et GNOME sur le même PC avec des lectures MemAvailable reproductibles.
Découvrez où HamoniKR 8.0 s'intègre dans un plan de bureau professionnel, quelles sont ses fonctionnalités axées sur le marché coréen et ce qu'il faut vérifier avant un déploiement plus large.
Comprenez comment la vérification du démarrage et les protections d'exécution de Gooroom fonctionnent ensemble, ce que signifie le terme « sandbox » et quels paramètres vous devez vérifier sur votre appareil.
Comparez les exigences de HamoniKR 8.0 LTS et Lite, puis testez le Wi-Fi, les graphismes et les commandes de l'ordinateur portable à partir d'une clé USB active avant l'installation.
Comparez les installations minimales et standard d'Ubuntu Server 24.04 en termes de RAM, d'espace disque, de temps de démarrage, de processeur et de charges de travail réelles, sans affirmations trompeuses concernant les benchmarks.
