Ubuntu Server 24.04 Minimal vs Standard: Explicația testelor de performanță

Un server privat virtual pare să aibă o memorie insuficientă, așa că reinstalați Ubuntu Server 24.04 LTS și vă confruntați cu o alegere timpurie: instalarea implicită a serverului Ubuntu Server sau Ubuntu Server (minimizat). Este tentant să presupunem că mai puține pachete înseamnă automat solicitări web mai rapide, interogări mai scurte în baza de date și un debit CPU mai mare. Diferența este mai nuanțată. Un set de pachete inițial mai mic poate reduce utilizarea discului și activitatea în fundal, dar, în sine, nu face procesorul sau dispozitivul de stocare mai rapid.

Concluzie: Alegeți instalarea minimizată atunci când doriți un punct de plecare eficient și vă simțiți confortabil să adăugați doar instrumentele de care aveți nevoie. Alegeți instalarea standard atunci când doriți setul implicit mai larg de instrumente ale serverului. Comparați timpul de pornire, memoria inactivă, amprenta pe disc și performanța reală a aplicației separat, în loc să le comprimați într-o singură etichetă „mai rapid”.

Notă de verificare (9 octombrie 2026): Acest articol explică o metodă de benchmarking reproductibilă și rezultatele pe care fiecare metrică le poate stabili. Nu prezintă scorurile originale măsurate din două instalări Ubuntu 24.04 potrivite. Nu sunt reprezentate ca rezultate ale testelor cifre neverificate privind memoria RAM, disc, timpul de pornire sau debitul.

Care este diferența dintre serverul Ubuntu standard și cel minimizat?

Programul de instalare Subiquity al serverului Ubuntu oferă două surse de instalare: ubuntu-serverpentru standard (implicit) și ubuntu-server-minimalpentru minimizat. Canonical documentează acești identificatori de sursă și recomandă verificarea casper/install-sources.yamlfișierului ISO ales, deoarece identificatorii programului de instalare se pot schimba. Consultați documentația surselor pentru instalarea automată a fișierului Canonical Subiquity .

Ambele sunt Ubuntu Server 24.04 LTS, nu două arhitecturi de procesor optimizate diferit sau distribuții Linux separate. Ceea ce se schimbă în principal este software-ul livrat în momentul instalării. Pachetele care apar depind exact de versiunea suportului de instalare, de opțiunile opționale, de actualizări, de drivere și de aplicațiile instalate ulterior. Nu presupuneți că o listă publicată pentru o singură versiune de imagine se aplică neschimbată fiecărui program de instalare lansat la un punct 24.04.

Opțiunea de server minimizat nu trebuie confundată cu imaginile cloud Ubuntu minimale , o familie separată de imagini sau cu opțiunea de instalare minimală Ubuntu Desktop. Notele de lansare Ubuntu 24.04 LTS discută o reducere substanțială a numărului de pachete și a dimensiunii descărcabile a imaginilor cloud minimale în comparație cu versiunile anterioare. Aceste exemple de imagini cloud publicate nu reprezintă un benchmark ISO controlat pentru standarde versus servere live minimizate, iar numerele lor nu ar trebui reutilizate ca și cum ar fi.

Ce repere de performanță contează?

Comportamentul așteptat nu este un rezultat măsurat. O mașină minimizată poate consuma mai puține resurse imediat după instalare. Dar odată ce ambele mașini rulează aceeași bază de date, același runtime de container, agent de monitorizare și server web, decalajul observat se poate micșora, dispărea sau își poate schimba direcția. Singura concluzie justificabilă provine din măsurarea volumului de lucru țintă.

Începeți cu o configurație de testare corectă, nu cu un cronometru

Construiți două mașini virtuale de unică folosință din aceeași revizie ISO Ubuntu Server 24.04 LTS, una standard și una minimizată. Atribuiți un număr identic de vCPU-uri, memorie RAM, discuri virtuale, sisteme de fișiere, mod de boot, setări de hypervisor, atașamente la rețea și clasă de stocare. Pentru mașinile fizice, utilizați hardware echivalent și testați în condiții termice și de alimentare similare. Nu permiteți accesul mașinilor la traficul de producție.

Pe ambele sisteme, aplicați aceleași actualizări de securitate și reporniți sistemul. Înregistrați cat /etc/os-release, uname -r, și lscpu, plus versiunea imaginii de instalare și data testării. Ubuntu Server 24.04 utilizează în mod normal pista de kernel cu disponibilitate generală, dar poate utiliza opțional kerneluri Hardware Enablement; piste de kernel diferite ar compromite o comparație doar a tipului de instalare. Documentația kernelului Ubuntu despre kernelurile GA și HWE explică această distincție.

Colectați două seturi de măsurători:

1. Instalare nouă: Imediat după actualizări identice, înainte de instalarea unei sarcini de lucru. Aceasta izolează diferențele practice dintre setările implicite de instalare.
2. Linie de bază similară producției: După instalarea acelorași pachete de aplicații, activarea acelorași servicii și aplicarea unor configurații identice. Aceasta arată dacă diferența de amprentă inițială mai contează.

Folosiți cel puțin mai multe rulări per test, de preferință cinci sau mai multe după o încălzire, și comparați medianele, precum și variabilitatea. Reporniți și măsurați timpul de pornire pe mai multe porniri. Nu comparați niciodată un rezultat de pornire la rece pe un sistem cu un rezultat deja cald pe celălalt.

Măsoară mai întâi diferențele ușoare

1. Numără pachetele instalate și verifică spațiul pe disc

Numărul de pachete și utilizarea spațiului de stocare sunt de obicei cele mai simple caracteristici de inspectat. Pe fiecare mașină virtuală, executați:

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

Înregistrați numărul, spațiul utilizat pe sistemul de fișiere rădăcină și aspectul sistemului de fișiere. Asigurați-vă că partițiile rădăcină au dimensiuni comparabile; altfel, o diferență aparentă poate proveni din partiționare. Utilizarea discului include și jurnale, cache-uri de pachete și metadatele sistemului de fișiere, astfel încât timpii de instalare identici și istoricul de actualizare comparabil contează.

2. Comparați memoria RAM disponibilă, nu doar memoria RAM „liberă”

După ce ambele sisteme au fost inactive pentru o perioadă de stabilizare consistentă, executați:

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

Uitați-vă la availablecoloana din [numele fișierului], freeprecum și la [ numele fișierului used]. Linux folosește memorie inactivă pentru cache, care poate fi recuperată atunci când aplicațiile au nevoie de ea. O valoare mai mică în freecoloană nu indică automat o problemă. Verificați dacă utilizarea suplimentară a memoriei aparține serviciilor pe care intenționați de fapt să le păstrați.

3. Comparați timpul de pornire și găsiți serviciile lente

Pentru fiecare pornire, utilizați instrumentele systemd furnizate cu distribuția:

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

systemd-analyze timeraportează temporizarea etapei de pornire, dar nu înseamnă neapărat că aplicația este gata să accepte cereri. Lista blamepoate induce în eroare, deoarece unitățile se pot inițializa în paralel, iar unele tipuri de servicii nu sunt măsurate în același mod. Investigați lanțul critic, apoi verificați separat punctul final exact al serviciului care vă interesează. Aceste limitări sunt documentate în manualul Ubuntu 24.04 systemd-analyze .

De exemplu, dacă un server rulează o API HTTP, măsurați timpul de la repornire până la finalizarea cu succes a endpoint-ului de sănătate al API-ului. Dacă o gazdă rulează o bază de date, verificați dacă o interogare are succes. Această măsurare a disponibilității este mai ușor de acționat decât atingerea unei ținte de pornire de către sistemul de operare.

Apoi testați CPU-ul și stocarea sub sarcină controlată

4. Rulați aceeași sarcină de lucru CPU pe ambele mașini

Pentru o comparație simplă a procesoarelor, instalați o versiune identică de sysbench pe fiecare mașină virtuală de unică folosință după înregistrarea amprentei instalării noi. Apoi executați aceeași comandă:

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

Comparați evenimentele pe secundă și latența în rulări repetate. Documentația proiectului sysbench oferă sintaxa comenzii și testul CPU încorporat. Folosiți o a doua rulare cu același număr mai mare de fire de execuție numai dacă se încadrează în numărul de CPU atribuit. Un set de pachete redus nu justifică în sine revendicarea unei creșteri a vitezei CPU; diferențele neașteptate ar trebui să determine o verificare a contenției CPU-ului gazdă, a comportamentului ceasului, a versiunii kernelului și a proceselor din fundal.

5. Testarea I/O-urilor pe disc fără a evalua un disc de producție

Pentru un experiment opțional de stocare, instalați fio pe ambele mașini de testare și creați fișiere de testare identice pe un sistem de fișiere de unică folosință cu suficient spațiu liber. Următoarele comenzi creează un fișier de 256 MiB în directorul principal al utilizatorului curent, apoi rulați o sarcină de lucru cu citire aleatorie delimitată asupra acelui fișier:

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

Rulați ambele mașini cu discuri și parametri I/O identici. Un fișier de 256 MiB poate fi prea mic pentru a modela cu precizie baza de date sau dispozitivul de stocare; măriți fișierul și variați volumul de lucru numai atunci când este disponibil suficient spațiu de lucru și un mediu de testare sigur. Înregistrați distribuția IOPS, lățimea de bandă și latența, nu doar cea mai mare cifră a lățimii de bandă. Manualul Ubuntu 24.04 fio explică parametrii volumului de lucru. Nu îndreptați niciodată testele de scriere către un dispozitiv bloc brut care conține date utile.

6. Testați ultima dată aplicația reală

Instalați exact aceeași stivă de aplicații pe ambele mașini, inclusiv versiunile web sau de bază de date, limitele de conexiune, înregistrarea în jurnal, TLS, memorarea în cache și monitorizarea. Trimiteți un mix de cereri echivalent de la un generator de sarcină separat, cu aceeași concurență și durată de testare. Măsurați debitul, latența mediană și percentila 95 a răspunsului, rata de eroare, utilizarea CPU, presiunea memoriei și swapping-ul. Folosiți același set de date și asigurați-vă că niciuna dintre mașini nu partajează un backend de stocare zgomotos, fără a lua în considerare contențiile.

Pentru un server API mic, o diferență în memoria inactivă este importantă dacă o configurație începe să se permute în timpul încărcării. Pentru un worker cu funcție CPU și multă memorie RAM liberă, fișierul binar identic al aplicației poate oferi un debit în esență similar. Niciun rezultat nu poate fi afirmat înainte de testare.

Cum se interpretează rezultatele contradictorii ale testelor de referință

• Număr mai mic de pachete, dar scoruri CPU egale: Acest lucru este complet consecvent. Mai puține instrumente instalate nu trebuie să modifice performanța de calcul.
• Utilizare mai mică a discului, dar IOPS egale: Spațiul liber și viteza dispozitivului sunt proprietăți diferite. Analizați hardware-ul de stocare, modelul I/O, sistemul de fișiere și memoria cache.
• Pornire systemd mai rapidă, dar pregătire la fel de lentă pentru aplicații: Blocajul poate fi pornirea aplicației, dependențele de rețea sau recuperarea bazei de date.
• Mai puțină memorie RAM inactivă, dar latență egală a solicitărilor: Minimizarea poate oferi un spațiu de capacitate util, dar sarcina de lucru curentă nu este limitată de memorie.
• Scoruri care se schimbă rapid între rulări: Investigați vecinii zgomotoși, scalarea frecvenței CPU, actualizările, activitățile programate, limitarea termică și încălzirea memoriei cache înainte de a declara un câștigător.

Dacă avantajul măsurat este doar o cantitate mică de spațiu pe disc inactiv, dar fluxul de lucru operațional necesită în mod repetat lipsă de utilitare de administrare, instalarea standard poate fi alegerea mai productivă. Dacă serverele dvs. sunt furnizate automat și rulează un serviciu strict definit, o bază minimizată face adesea ca selecția pachetelor să fie mai ușoară de auditat.

Ar trebui să minimizezi un server existent?

De obicei, nu doar pentru a urmări valorile de referință. Pentru o instalare standard funcțională, inspectați mai întâi serviciile active și măsurați aplicația. Eliminarea pachetelor care nu au legătură poate să nu îmbunătățească o sarcină de lucru deja sănătoasă, iar eliminarea neglijentă a pachetelor poate perturba funcționarea rețelei, a recuperării, a înregistrării în jurnal sau a gestionării de la distanță. Ghidul de securitate Ubuntu de la Canonical privind pachetele inutile recomandă alegerea unei instalări inițiale minimale adecvate în loc să eliminați fără discernământ pachetele implicite.

Dacă este necesară o reconstrucție, faceți o copie de rezervă a datelor și a configurației, verificați o restaurare, instalați opțiunea minimizată pe o instanță nouă și furnizați în mod explicit pachetele necesare. Validați accesul SSH, actualizările, sincronizarea orei, copiile de rezervă, monitorizarea, politica firewall și starea aplicației înainte de a muta traficul. Dacă un administrator se bazează în mod regulat pe diagnostice incluse sau pe roluri variate, instalarea standard poate fi preferabilă chiar dacă amprenta instalată recent este mai mare.

Securitatea este legată, dar separată: mai puține pachete pot reduce cantitatea de software necesară pentru întreținere, dar acest lucru nu este o dovadă a unei reduceri specifice a expunerii la valul de efecte negative (CVE). Ambele tipuri de instalare necesită în continuare actualizări de securitate și consolidarea serviciilor.

Listă de verificare finală pentru verificare

• Confirmați că ambele mașini sunt Ubuntu Server 24.04 LTS cu aceeași arhitectură, nivel de patch, pistă de kernel și generație de instalare.
• Documentați selecția dintre standard și minimizat, opțiunile opționale pentru instalator și serviciile adăugate ulterior.
• Comparați numărul de pachete, utilizarea sistemului de fișiere rădăcină și memoria disponibilă după actualizări identice și o perioadă de inactivitate.
• Repetați măsurătorile de pornire și de pregătire a aplicațiilor pe parcursul mai multor reporniri, raportând mediane în loc de o singură rulare optimă.
• Folosește parametri potriviți pentru sarcinile de lucru ale procesorului, stocării și aplicațiilor și înregistrează erorile și distribuțiile de latență.
• Rulați aplicația cu dependențe, configurație și date identice, apoi decideți dacă vreo diferență afectează capacitatea, fiabilitatea sau timpul de implementare.

Concluzie practică: Minimizarea este de obicei cea mai bună opțiune de pornire pentru serverele automatizate, cu scop restrâns; versiunea standard oferă un set de instrumente implicit mai complet. Niciuna dintre opțiuni nu este universal mai rapidă. Pe Ubuntu Server 24.04 LTS, cel mai util benchmark este cel care măsoară serviciul în funcție de volumul de lucru pe care trebuie să îl gestioneze efectiv.