Ubuntu Server 24.04 Minimal vs Standard: confronto delle prestazioni a confronto

Un server virtuale privato (VPS) sembra avere poca memoria disponibile, quindi reinstallando Ubuntu Server 24.04 LTS ci si trova subito di fronte a una scelta: l'installazione predefinita di Ubuntu Server o Ubuntu Server (minimizzato). È facile pensare che un minor numero di pacchetti si traduca automaticamente in richieste web più veloci, query di database più brevi e maggiore produttività della CPU. La differenza è più complessa. Un set di pacchetti iniziale più piccolo può ridurre l'utilizzo del disco e l'attività in background, ma di per sé non rende più veloci il processore o il dispositivo di archiviazione.

In sintesi: scegli l'installazione ridotta al minimo se desideri un punto di partenza snello e ti senti a tuo agio nell'aggiungere solo gli strumenti necessari. Scegli l'installazione standard se preferisci il set di strumenti server predefinito più ampio. Confronta separatamente i tempi di avvio, la memoria inattiva, l'ingombro su disco e le prestazioni effettive delle applicazioni, anziché raggrupparli in un'unica etichetta di "più veloce".

Nota (9 ottobre 2026): Questo articolo illustra un metodo di benchmarking riproducibile e i risultati che ogni parametro può fornire. Non presenta i punteggi misurati originali di due installazioni identiche di Ubuntu 24.04. Non vengono riportati dati non verificati relativi a RAM, disco, tempo di avvio o throughput come risultati dei test.

Qual è la differenza tra Ubuntu Server standard e Ubuntu Server minimizzato?

Il programma di installazione Subiquity di Ubuntu Server offre due sorgenti di installazione: una ubuntu-serverper l'installazione standard (quella predefinita) e una ubuntu-server-minimalper l'installazione minimizzata. Canonical documenta questi identificatori di sorgente e consiglia di verificarli casper/install-sources.yamlsull'immagine ISO scelta, poiché gli identificatori del programma di installazione possono cambiare. Consultare la documentazione di Canonical relativa alle sorgenti di installazione automatica di Subiquity .

Entrambe sono versioni di Ubuntu Server 24.04 LTS, non due architetture CPU ottimizzate in modo diverso o distribuzioni Linux separate. La differenza principale risiede nel software fornito al momento dell'installazione. I pacchetti inclusi dipendono dalla revisione del supporto di installazione, dalle opzioni selezionate, dagli aggiornamenti, dai driver e dalle applicazioni installate successivamente. Non bisogna dare per scontato che un elenco pubblicato per una specifica immagine di sistema sia valido senza modifiche per ogni versione di Ubuntu 24.04.

L'opzione server minimizzato non deve essere confusa con le immagini cloud minimali di Ubuntu , una famiglia di immagini separata, o con l'opzione di installazione minimale di Ubuntu Desktop. Le note di rilascio di Ubuntu 24.04 LTS descrivono una sostanziale riduzione del numero di pacchetti e delle dimensioni scaricabili delle immagini cloud minimali rispetto alle versioni precedenti. Gli esempi di immagini cloud pubblicati non costituiscono un benchmark controllato tra ISO di server live standard e minimizzate, e i loro valori non devono essere riutilizzati come se lo fossero.

Quali parametri di prestazione sono importanti?

Il comportamento previsto non è un risultato misurato. Una macchina ottimizzata potrebbe consumare meno risorse subito dopo l'installazione. Tuttavia, una volta che entrambe le macchine eseguono lo stesso database, runtime dei container, agente di monitoraggio e server web, la differenza osservata potrebbe ridursi, scomparire o invertirsi. L'unica conclusione attendibile deriva dalla misurazione del carico di lavoro target.

Inizia con una configurazione di test equa, non con un cronometro

Crea due macchine virtuali usa e getta dalla stessa revisione dell'immagine ISO di Ubuntu Server 24.04 LTS, una standard e una minimizzata. Assegna lo stesso numero di vCPU, RAM, dischi virtuali, filesystem, modalità di avvio, impostazioni dell'hypervisor, connessione di rete e classe di storage. Per le macchine fisiche, utilizza hardware equivalente ed esegui i test in condizioni termiche e di alimentazione simili. Mantieni le macchine non utilizzate in ambienti di produzione.

Su entrambi i sistemi, applicare gli stessi aggiornamenti di sicurezza e riavviare. Annotare cat /etc/os-release, uname -r, e lscpu, oltre alla versione dell'immagine di installazione e alla data del test. Ubuntu Server 24.04 utilizza normalmente il kernel di disponibilità generale, ma può facoltativamente utilizzare kernel di abilitazione hardware; l'utilizzo di kernel di disponibilità diversa comprometterebbe un confronto basato esclusivamente sul tipo di installazione. La documentazione del kernel di Ubuntu sui kernel GA e HWE spiega questa distinzione.

Raccogli due serie di misurazioni:

1. Configurazione di base per installazione pulita: immediatamente dopo aggiornamenti identici, prima di installare un carico di lavoro. Questo permette di isolare le differenze pratiche nelle impostazioni predefinite di installazione.
2. Scenario di riferimento simile a quello di produzione: dopo aver installato gli stessi pacchetti applicativi, abilitato gli stessi servizi e applicato configurazioni identiche. Questo permette di verificare se la differenza iniziale di ingombro è ancora rilevante.

Eseguire almeno diverse prove per ogni test, preferibilmente cinque o più dopo un periodo di riscaldamento, e confrontare le mediane e la variabilità. Riavviare il sistema e misurare il tempo di avvio su più avvii. Non confrontare mai un risultato di avvio a freddo su un sistema con un risultato di avvio a sistema già caldo su un altro.

Misura prima le differenze più semplici

1. Conta i pacchetti installati e controlla lo spazio su disco

Il numero di pacchetti e l'utilizzo dello spazio di archiviazione sono in genere le caratteristiche più semplici da controllare. Su ogni VM, eseguire:

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

Registra il numero di installazioni, lo spazio utilizzato sul filesystem di root e la struttura del filesystem. Assicurati che le partizioni di root abbiano dimensioni comparabili; altrimenti, una differenza apparente potrebbe derivare dal partizionamento. L'utilizzo del disco include anche i log, le cache dei pacchetti e i metadati del filesystem, quindi è importante che i tempi di installazione siano identici e che la cronologia degli aggiornamenti sia comparabile.

2. Confronta la RAM disponibile, non solo la RAM "libera".

Dopo che entrambi i sistemi sono rimasti inattivi per un periodo di tempo sufficiente a stabilizzarsi, eseguire:

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

Esamina la availablecolonna in freecosì come used. Linux utilizza la memoria altrimenti inattiva per la cache, che può essere recuperata quando le applicazioni ne hanno bisogno. Un valore inferiore nella freecolonna non indica automaticamente un problema. Verifica se l'utilizzo aggiuntivo della memoria appartiene a servizi che intendi effettivamente mantenere.

3. Confronta i tempi di avvio e individua i servizi lenti

Per ogni avvio, utilizzare gli strumenti systemd forniti con la distribuzione:

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

systemd-analyze timeIl comando `systemd -analyze` segnala i tempi della fase di avvio, ma ciò non significa necessariamente che l'applicazione sia pronta ad accettare richieste. L' blameelenco può anche essere fuorviante perché le unità potrebbero inizializzarsi in parallelo e alcuni tipi di servizio non vengono misurati allo stesso modo. Analizza la catena critica, quindi controlla separatamente l'endpoint del servizio specifico che ti interessa. Queste limitazioni sono documentate nel manuale di `systemd-analyze` di Ubuntu 24.04 .

Ad esempio, se un server esegue un'API HTTP, misurate il tempo che intercorre tra il riavvio e il momento in cui l'endpoint di integrità dell'API ha successo. Se un host esegue un database, verificate che una query abbia esito positivo. Questa misurazione dello stato di prontezza è più utile rispetto al raggiungimento di una destinazione di avvio da parte del sistema operativo.

Successivamente, testa la CPU e lo storage sotto carico controllato.

4. Eseguire lo stesso carico di lavoro della CPU su entrambe le macchine

Per un semplice confronto della CPU, installa una versione identica di sysbench su ogni VM usa e getta dopo aver registrato l'ingombro dell'installazione pulita. Quindi esegui lo stesso comando:

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

Confronta il numero di eventi al secondo e la latenza tra esecuzioni ripetute. La documentazione del progetto sysbench fornisce la sintassi del comando e il test CPU integrato. Utilizza una seconda esecuzione con lo stesso numero di thread più elevato solo se è compatibile con il numero di CPU assegnato. Una riduzione del set di pacchetti da sola non giustifica l'affermazione di un aumento di velocità della CPU; differenze inattese dovrebbero indurre a verificare la contesa della CPU host, il comportamento dell'orologio, la versione del kernel e i processi in background.

5. Testare l'I/O del disco senza eseguire il benchmarking di un disco di produzione

Per un esperimento di archiviazione facoltativo, installate fio su entrambe le macchine di test e create file di test identici su un filesystem temporaneo con ampio spazio libero. I seguenti comandi creano un file di 256 MiB nella directory home dell'utente corrente, quindi eseguite un carico di lavoro di lettura casuale limitata su tale file:

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

Eseguire entrambe le macchine con dischi e parametri I/O identici. Un file da 256 MiB potrebbe essere troppo piccolo per simulare accuratamente il database o il dispositivo di archiviazione; ingrandire il file e variare il carico di lavoro solo quando sono disponibili spazio di lavoro sufficiente e un ambiente di test sicuro. Registrare IOPS, larghezza di banda e distribuzione della latenza, non solo il valore massimo di larghezza di banda. Il manuale di fio su Ubuntu 24.04 spiega i parametri del carico di lavoro. Non eseguire mai test di scrittura su un dispositivo a blocchi raw contenente dati utili.

6. Testare per ultimo l'applicazione reale

Installa esattamente lo stesso stack applicativo su entrambe le macchine, incluse le versioni web o del database, i limiti di connessione, la registrazione, TLS, la cache e il monitoraggio. Invia un mix di richieste equivalente da un generatore di carico separato, con la stessa concorrenza e durata del test. Misura il throughput, la latenza di risposta mediana e al 95° percentile, il tasso di errore, l'utilizzo della CPU, la pressione della memoria e lo swapping. Utilizza lo stesso set di dati e assicurati che nessuna delle due macchine condivida un backend di archiviazione rumoroso senza tenere conto della contesa.

Per un piccolo server API, una differenza nella memoria inattiva è rilevante se una configurazione inizia a utilizzare lo swap sotto carico. Per un worker con risorse CPU limitate e molta RAM disponibile, lo stesso file binario dell'applicazione potrebbe offrire prestazioni sostanzialmente simili. Nessuno dei due risultati può essere garantito prima di aver effettuato dei test.

Come interpretare risultati di benchmark contrastanti

• Minore numero di pacchetti installati ma punteggi CPU invariati: questo è assolutamente coerente. Un minor numero di strumenti installati non influisce necessariamente sulle prestazioni di calcolo.
• Minore utilizzo del disco ma IOPS uguali: lo spazio libero e la velocità del dispositivo sono proprietà diverse. Analizza l'hardware di archiviazione, il modello di I/O, il file system e la cache.
• Avvio di systemd più rapido, ma altrettanto lenta la preparazione delle applicazioni: il collo di bottiglia potrebbe risiedere nell'avvio delle applicazioni, nelle dipendenze di rete o nel ripristino del database.
• Meno RAM inattiva ma latenza di richiesta uguale: la minimizzazione può offrire un margine di capacità utile, ma il carico di lavoro attuale non è limitato dalla memoria.
• Punteggi che cambiano drasticamente tra un'esecuzione e l'altra: prima di dichiarare un vincitore, è necessario esaminare i processi che generano interferenze, la scalatura della frequenza della CPU, gli aggiornamenti, le attività pianificate, la limitazione termica e il riscaldamento della cache.

Se il vantaggio misurabile si limita a una minima quantità di spazio su disco inutilizzato, ma il flusso di lavoro operativo richiede ripetutamente l'utilizzo di utilità amministrative mancanti, l'installazione standard può risultare la scelta più produttiva. Se i server vengono configurati automaticamente ed eseguono un servizio ben definito, una configurazione di base ridotta spesso semplifica la verifica della selezione dei pacchetti.

È consigliabile ridurre a icona un server esistente?

Di solito, non si tratta solo di inseguire i valori di riferimento. Per un'installazione standard funzionante, è necessario prima esaminare i servizi effettivamente attivi e misurare le prestazioni dell'applicazione. La rimozione di pacchetti non correlati potrebbe non migliorare un carico di lavoro già ottimale e una rimozione indiscriminata può compromettere la rete, il ripristino, la registrazione dei log o la gestione remota. Le linee guida di sicurezza di Canonical per Ubuntu sui pacchetti non necessari raccomandano di scegliere un'installazione iniziale minima e appropriata anziché rimuovere indiscriminatamente i pacchetti predefiniti.

Se una reinstallazione è opportuna, eseguire il backup dei dati e della configurazione, verificare il ripristino, installare l'opzione minimizzata su una nuova istanza e predisporre esplicitamente i pacchetti necessari. Prima di spostare il traffico, convalidare l'accesso SSH, gli aggiornamenti, la sincronizzazione dell'ora, i backup, il monitoraggio, le policy del firewall e lo stato di salute dell'applicazione. Se un amministratore si affida regolarmente a strumenti di diagnostica integrati o a ruoli diversi, l'installazione standard potrebbe essere preferibile, anche se l'ingombro di una nuova installazione è maggiore.

La sicurezza è un aspetto correlato ma distinto: un minor numero di pacchetti può ridurre la quantità di software da manutenere, ma ciò non implica necessariamente una riduzione delle vulnerabilità CVE. Entrambi i tipi di installazione richiedono comunque aggiornamenti di sicurezza e interventi di protezione del servizio.

Lista di controllo per la verifica finale

• Conferma che entrambe le macchine siano Ubuntu Server 24.04 LTS con la stessa architettura, livello di patch, versione del kernel e generazione del programma di installazione.
• Documentare la selezione tra la versione standard e quella minimizzata, le opzioni di installazione e i servizi aggiunti successivamente.
• Confronta il numero di pacchetti, l'utilizzo del filesystem di root e la memoria disponibile dopo aggiornamenti identici e un periodo di assestamento inattivo.
• Ripetere le misurazioni di avvio e di prontezza delle applicazioni su più riavvii, riportando i valori mediani anziché il singolo risultato migliore.
• Utilizza parametri corrispondenti per i carichi di lavoro di CPU, archiviazione e applicazioni e registra le distribuzioni di errori e latenza.
• Esegui l'applicazione con dipendenze, configurazione e dati identici, quindi valuta se eventuali differenze influiscono sulla capacità, sull'affidabilità o sui tempi di implementazione.

In conclusione: la configurazione "Minimizzata" è generalmente la scelta migliore per server automatizzati con ambito ristretto; la configurazione "Standard" offre un set di strumenti predefinito più completo. Nessuna delle due opzioni è universalmente più veloce. Su Ubuntu Server 24.04 LTS, il benchmark più utile è quello che misura le prestazioni del servizio sotto il carico di lavoro che deve effettivamente gestire.