Ubuntu Server 24.04 Minimalny kontra Standardowy: Wyjaśnienie testów wydajności

Wirtualny serwer prywatny zużywa mało pamięci, więc instalujesz ponownie Ubuntu Server 24.04 LTS i stajesz przed wczesnym wyborem: domyślna instalacja Ubuntu Server lub Ubuntu Server (zminimalizowana). Kuszące jest założenie, że mniejsza liczba pakietów automatycznie oznacza szybsze żądania sieciowe, krótsze zapytania do bazy danych i wyższą przepustowość procesora. Różnica jest bardziej subtelna. Mniejszy zestaw pakietów początkowych może zmniejszyć obciążenie dysku i aktywność w tle, ale sam w sobie nie przyspiesza procesora ani urządzenia pamięci masowej.

Podsumowanie: Wybierz instalację zminimalizowaną, jeśli zależy Ci na uproszczeniu punktu wyjścia i chcesz dodać tylko potrzebne narzędzia. Wybierz instalację standardową, jeśli chcesz korzystać z szerszego, domyślnego zestawu narzędzi serwerowych. Porównaj czas rozruchu, pamięć bezczynności, obciążenie dysku i rzeczywistą wydajność aplikacji osobno, zamiast łączyć je w jedną etykietę „szybsza”.

Notatka dowodowa (9 października 2026 r.): W tym artykule wyjaśniono powtarzalną metodę benchmarkingu oraz wyniki, jakie można uzyskać za pomocą każdej metryki. Nie przedstawiono oryginalnych wyników pomiarów z dwóch dopasowanych instalacji Ubuntu 24.04. Nie przedstawiono żadnych niezweryfikowanych danych dotyczących pamięci RAM, dysku, czasu rozruchu ani przepustowości jako wyników testów.

Jaka jest różnica między standardową a zminimalizowaną wersją Ubuntu Server?

Instalator Subiquity w Ubuntu Server oferuje dwa źródła instalacji: ubuntu-serverstandardowe (domyślne) i ubuntu-server-minimalzminimalizowane. Canonical dokumentuje te identyfikatory źródeł i zaleca sprawdzenie casper/install-sources.yamlwybranego pliku ISO, ponieważ identyfikatory instalatora mogą się zmieniać. Zapoznaj się z dokumentacją źródłową autoinstalacji Subiquity w Canonical .

Oba to Ubuntu Server 24.04 LTS, a nie dwie odmiennie zoptymalizowane architektury procesorów ani oddzielne dystrybucje Linuksa. Zmienia się przede wszystkim oprogramowanie dostarczane podczas instalacji. To, które pakiety zostaną wyświetlone, zależy od wersji nośnika instalacyjnego, opcji opcjonalnych, aktualizacji, sterowników i instalowanych aplikacji. Nie należy zakładać, że lista opublikowana dla jednej kompilacji obrazu obowiązuje bez zmian dla każdego instalatora punktowego 24.04.

Opcji zminimalizowanego serwera nie należy mylić z minimalnymi obrazami w chmurze Ubuntu , osobną rodziną obrazów ani z opcją minimalnej instalacji Ubuntu Desktop. Informacje o wydaniu Ubuntu 24.04 LTS omawiają znaczną redukcję liczby pakietów i rozmiaru do pobrania minimalnych obrazów w chmurze w porównaniu z wcześniejszymi wersjami. Opublikowane przykłady obrazów w chmurze nie stanowią kontrolowanego porównania standardu ze zminimalizowanym serwerem w trybie rzeczywistym (ISO) i nie należy ich ponownie wykorzystywać, jakby nimi były.

Które testy wydajności są istotne?

Oczekiwane zachowanie nie jest mierzalnym rezultatem. Zminimalizowana maszyna może zużywać mniej zasobów bezpośrednio po instalacji. Jednak gdy obie maszyny korzystają z tej samej bazy danych, środowiska wykonawczego kontenera, agenta monitorującego i serwera WWW, obserwowana różnica może się zmniejszyć, zniknąć lub zmienić kierunek. Jedyny uzasadniony wniosek wynika z pomiaru obciążenia docelowego.

Zacznij od uczciwego testu, a nie od stopera

Zbuduj dwie maszyny wirtualne jednorazowego użytku z tej samej wersji ISO Ubuntu Server 24.04 LTS – jedną standardową i jedną zminimalizowaną. Przypisz identyczną liczbę procesorów wirtualnych (vCPU), pamięć RAM, dyski wirtualne, systemy plików, tryb rozruchu, ustawienia hiperwizora, połączenie sieciowe i klasę pamięci masowej. W przypadku maszyn fizycznych użyj równoważnego sprzętu i przetestuj je w podobnych warunkach temperaturowych i energetycznych. Wyłącz maszyny z ruchu produkcyjnego.

W obu systemach należy zastosować te same aktualizacje zabezpieczeń i uruchomić ponownie. Zapisz cat /etc/os-release, uname -r, i lscpu, a także wersję obrazu instalatora i datę testu. Ubuntu Server 24.04 zazwyczaj korzysta ze ścieżki jądra o ogólnej dostępności, ale opcjonalnie może korzystać z jąder Hardware Enablement; różne ścieżki jądra mogłyby utrudnić porównanie wyłącznie typu instalacji. Dokumentacja jądra Ubuntu dotycząca jąder GA i HWE wyjaśnia to rozróżnienie.

Zbierz dwa zestawy pomiarów:

1. Baza świeżo zainstalowanej instalacji: Bezpośrednio po identycznych aktualizacjach, przed zainstalowaniem obciążenia. Pozwala to na wyizolowanie praktycznych różnic w domyślnych ustawieniach instalacji.
2. Poziom bazowy zbliżony do produkcyjnego: po zainstalowaniu tych samych pakietów aplikacji, włączeniu tych samych usług i zastosowaniu identycznych konfiguracji. Pokazuje to, czy początkowa różnica w zajmowanym obszarze nadal ma znaczenie.

Wykonaj co najmniej kilka przebiegów testu, najlepiej pięć lub więcej po rozgrzewce, i porównaj mediany oraz zmienność. Uruchom ponownie system i zmierz czas rozruchu w kilku rozruchach. Nigdy nie porównuj wyniku zimnego rozruchu w jednym systemie z wynikiem rozgrzanego rozruchu w drugim.

Najpierw zmierz łatwe różnice

1. Policz zainstalowane pakiety i sprawdź ilość miejsca na dysku

Liczba pakietów i wykorzystanie pamięci masowej to zazwyczaj najłatwiejsze do sprawdzenia parametry. Na każdej maszynie wirtualnej uruchom:

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

Rejestruj liczbę partycji, zajęte miejsce w systemie plików głównych oraz układ systemu plików. Upewnij się, że partycje główne mają porównywalne rozmiary; w przeciwnym razie pozorna różnica może wynikać z partycjonowania. Użycie dysku obejmuje również logi, pamięć podręczną pakietów i metadane systemu plików, dlatego liczą się identyczne czasy instalacji i porównywalne historie aktualizacji.

2. Porównaj dostępną pamięć RAM, a nie tylko „wolną” pamięć RAM

Po upływie określonego czasu bezczynności obu układów należy uruchomić:

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

Sprawdź również availablekolumnę w . Linux wykorzystuje w innym przypadku niewykorzystaną pamięć podręczną, którą można odzyskać, gdy aplikacje jej potrzebują. Mniejsza wartość w tej kolumnie nie oznacza automatycznie problemu. Sprawdź, czy dodatkowa pamięć jest wykorzystywana przez usługi, które faktycznie planujesz zachować.freeusedfree

3. Porównaj czas rozruchu i znajdź wolne usługi

Przy każdym uruchomieniu należy używać narzędzi systemd dostarczonych wraz z dystrybucją:

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

systemd-analyze timeRaportuje czas rozruchu, ale niekoniecznie oznacza to, że aplikacja jest gotowa do przyjmowania żądań. Lista blamemoże również wprowadzać w błąd, ponieważ jednostki mogą inicjalizować się równolegle, a niektóre typy usług nie są mierzone w ten sam sposób. Zbadaj łańcuch krytyczny, a następnie osobno sprawdź konkretny punkt końcowy usługi, który Cię interesuje. Te ograniczenia są udokumentowane w podręczniku systemd-analyze dla Ubuntu 24.04 .

Na przykład, jeśli serwer obsługuje interfejs API HTTP, należy zmierzyć czas od ponownego uruchomienia do momentu pomyślnego uruchomienia punktu końcowego interfejsu API. Jeśli host obsługuje bazę danych, należy sprawdzić, czy zapytanie zakończyło się powodzeniem. Ten pomiar gotowości jest bardziej wiarygodny niż osiągnięcie przez system operacyjny celu rozruchu.

Następnie przetestuj procesor i pamięć masową pod kontrolowanym obciążeniem

4. Uruchom to samo obciążenie procesora na obu maszynach

Aby przeprowadzić proste porównanie procesora, zainstaluj identyczną wersję sysbencha na każdej maszynie wirtualnej po zarejestrowaniu śladu po świeżej instalacji. Następnie uruchom to samo polecenie:

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

Porównaj liczbę zdarzeń na sekundę i opóźnienie w powtarzanych przebiegach. Dokumentacja projektu sysbench zawiera składnię poleceń i wbudowany test procesora. Użyj drugiego przebiegu z tą samą, wyższą liczbą wątków tylko wtedy, gdy pasuje ona do przypisanej liczby procesorów. Sam zmniejszony zestaw pakietów nie uzasadnia twierdzenia o przyspieszeniu procesora; nieoczekiwane różnice powinny skłonić do sprawdzenia rywalizacji o procesor hosta, zachowania zegara, wersji jądra i procesów w tle.

5. Przetestuj wejście/wyjście dysku bez przeprowadzania benchmarkingu dysku produkcyjnego

W ramach opcjonalnego eksperymentu z pamięcią masową zainstaluj fio na obu maszynach testowych i utwórz identyczne pliki testowe w jednorazowym systemie plików z dużą ilością wolnego miejsca. Poniższe polecenia tworzą plik o rozmiarze 256 MiB w katalogu domowym bieżącego użytkownika, a następnie uruchamiają na tym pliku ograniczone obciążenie odczytu losowego:

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

Uruchom obie maszyny z identycznymi dyskami i parametrami wejścia/wyjścia. Plik o rozmiarze 256 MiB może być zbyt mały, aby dokładnie odwzorować bazę danych lub urządzenie pamięci masowej; powiększ plik i zmień obciążenie tylko wtedy, gdy dostępna jest wystarczająca ilość miejsca na dane robocze i bezpieczne środowisko testowe. Rejestruj rozkład IOPS, przepustowości i opóźnień, a nie tylko największą wartość przepustowości. Podręcznik systemu Ubuntu 24.04 FIO wyjaśnia parametry obciążenia. Nigdy nie kieruj testów zapisu na surowe urządzenie blokowe zawierające użyteczne dane.

6. Na końcu przetestuj rzeczywistą aplikację

Zainstaluj dokładnie ten sam stos aplikacji na obu maszynach, uwzględniając wersje webowe lub bazodanowe, limity połączeń, logowanie, TLS, buforowanie i monitorowanie. Wyślij równoważny zestaw żądań z oddzielnego generatora obciążenia, z tą samą współbieżnością i czasem trwania testu. Zmierz przepustowość, medianę i opóźnienie odpowiedzi (95. percentyl), współczynnik błędów, wykorzystanie procesora, obciążenie pamięci i wymianę. Użyj tego samego zestawu danych i upewnij się, że żadna z maszyn nie współdzieli zaplecza pamięci masowej o dużej ilości danych, bez uwzględniania konfliktów.

W przypadku małego serwera API różnica w pamięci bezczynnej ma znaczenie, jeśli jedna z konfiguracji zaczyna się zamieniać podczas ładowania. W przypadku serwera o dużym obciążeniu procesora i dużej ilości wolnej pamięci RAM, identyczny plik binarny aplikacji może zapewnić zasadniczo podobną przepustowość. Żadnego z tych wyników nie można potwierdzić przed testowaniem.

Jak interpretować sprzeczne wyniki testów porównawczych

• Mniejsza liczba pakietów, ale takie same wyniki procesora: To jest całkowicie spójne. Mniejsza liczba zainstalowanych narzędzi nie musi wpływać na wydajność obliczeniową.
• Niższe zużycie dysku przy równym IOPS: Wolne miejsce i prędkość urządzenia to różne parametry. Zwróć uwagę na sprzęt pamięci masowej, wzorzec wejścia/wyjścia, system plików i buforowanie.
• Szybszy rozruch systemd, ale równie powolna gotowość aplikacji: wąskim gardłem może być uruchamianie aplikacji, zależności sieciowe lub odzyskiwanie bazy danych.
• Mniej wolnej pamięci RAM, ale takie samo opóźnienie żądań: Zminimalizowanie może zapewnić użyteczną przestrzeń dyskową, ale bieżące obciążenie nie jest ograniczone pamięcią.
• Bardzo zmienne wyniki pomiędzy przebiegami: sprawdź głośnych sąsiadów, skalowanie częstotliwości procesora, aktualizacje, zadania zaplanowane, ograniczanie termiczne i nagrzewanie się pamięci podręcznej przed ogłoszeniem zwycięzcy.

Jeśli mierzalną korzyścią jest jedynie niewielka ilość wolnego miejsca na dysku, ale Twój proces operacyjny stale wymaga braku narzędzi administracyjnych, standardowa instalacja może być bardziej produktywnym wyborem. Jeśli Twoje serwery są automatycznie konfigurowane i obsługują ściśle zdefiniowaną usługę, zminimalizowana baza często ułatwia audyt wyboru pakietów.

Czy warto zminimalizować istniejący serwer?

Zazwyczaj nie tylko po to, by śledzić wyniki testów porównawczych. Aby instalacja działała prawidłowo, należy najpierw sprawdzić jej aktywne usługi i zmierzyć wydajność aplikacji. Usunięcie niepowiązanych pakietów może nie poprawić i tak już sprawnego obciążenia, a nieostrożne usunięcie pakietów może zakłócić działanie sieci, odzyskiwanie danych, rejestrowanie zdarzeń lub zdalne zarządzanie. Wskazówki Canonical dotyczące bezpieczeństwa Ubuntu dotyczące zbędnych pakietów zalecają wybór odpowiednio minimalnej instalacji początkowej zamiast bezmyślnego usuwania domyślnych pakietów.

Jeśli odbudowa jest opłacalna, utwórz kopię zapasową danych i konfiguracji, zweryfikuj przywracanie, zainstaluj zminimalizowaną wersję na nowej instancji i jawnie zainstaluj niezbędne pakiety. Przed przeniesieniem ruchu sprawdź poprawność dostępu SSH, aktualizacji, synchronizacji czasu, kopii zapasowych, monitorowania, zasad zapory sieciowej i stanu aplikacji. Jeśli administrator regularnie korzysta z dołączonej diagnostyki lub zróżnicowanych ról, standardowa instalacja może być lepszym rozwiązaniem, nawet jeśli jej rozmiar po instalacji jest większy.

Bezpieczeństwo jest powiązane, ale odrębne: mniejsza liczba pakietów może zmniejszyć ilość oprogramowania, które trzeba utrzymywać, ale nie świadczy to o konkretnej redukcji CVE. Oba typy instalacji nadal wymagają aktualizacji zabezpieczeń i wzmocnienia usług.

Lista kontrolna ostatecznej weryfikacji

• Sprawdź, czy oba komputery to Ubuntu Server 24.04 LTS z tą samą architekturą, poziomem poprawek, ścieżką jądra i generacją instalatora.
• Udokumentuj wybór wersji standardowej lub zminimalizowanej, opcjonalne opcje instalatora i usługi dodane później.
• Porównaj liczbę pakietów, użycie głównego systemu plików i dostępną pamięć po identycznych aktualizacjach i okresie bezczynności.
• Powtarzaj pomiary rozruchu i gotowości aplikacji po wielokrotnych restartach, raportując mediany zamiast pojedynczego najlepszego przebiegu.
• Używaj dopasowanych parametrów do obciążeń procesora, pamięci masowej i aplikacji oraz rejestruj błędy i rozkład opóźnień.
• Uruchom aplikację z identycznymi zależnościami, konfiguracją i danymi, a następnie zdecyduj, czy jakiekolwiek różnice wpłyną na wydajność, niezawodność lub czas wdrożenia.

Praktyczny wniosek: Minimalizacja to zazwyczaj lepszy początkowy rozmiar dla wąskopasmowych, zautomatyzowanych serwerów; standard oferuje pełniejszy domyślny zestaw narzędzi. Żadna z opcji nie jest uniwersalnie szybsza. W Ubuntu Server 24.04 LTS najbardziej użytecznym benchmarkiem jest ten, który mierzy wydajność usługi w kontekście obciążenia, jakie musi ona faktycznie obsłużyć.