Ostatnia aktualizacja: 20 sierpnia 2026
GZIP vs BZIP2 vs XZ: Który format kompresji w Linuksie jest najlepszy?
Niezależnie od tego, czy pakujesz codzienne zrzuty baz danych, rotujesz wielogigabajtowe logi serwera WWW, czy dystrybuujesz skompilowane pliki binarne do tysięcy węzłów, kompresja jest codzienną rzeczywistością w administracji Linuksem.
Podczas wywoływania tar lub przetwarzania danych strumieniowych przez standardowe wejście, zazwyczaj napotykasz trzy standardowe narzędzia: GZIP (.gz), BZIP2 (.bz2) i XZ (.xz).
Podczas gdy wszystkie trzy narzędzia mają na celu ściśnięcie surowych bajtów w kompaktowe archiwa, podejmują zasadniczo różne kompromisy inżynieryjne między współczynnikiem kompresji, czasem działania CPU a zużyciem pamięci. Wybranie niewłaściwego formatu może cicho stać się wąskim gardłem w twoich zautomatyzowanych wdrożeniach, opóźnić zaplanowane okna backupu lub marnować cenną przestrzeń dyskową z czasem.
Ten przewodnik wyjaśnia, jak każdy format działa pod maską, jak wypada w realistycznych obciążeniach oraz jak wybrać właściwy dla twojej infrastruktury.
1. Szybkie profile techniczne: Trzej pretendentowie
GZIP (GNU Zip)
- Underlying Algorithm: DEFLATE (kombinacja LZ77 i kodowania Huffmana)
- Domyślne rozszerzenie:
.tar.gz,.tgz,.gz - Era wydania: 1992 (stworzony przez Jean-loup Gailly i Mark Adler jako wolna od patentów alternatywa dla
compress) - Główna zaleta: Niezrównana prędkość wykonania i prawie uniwersalne wsparcie ekosystemu.
- Główna wada: Niższy współczynnik kompresji w porównaniu do nowoczesnych statystycznych i słownikowych enkoderów.
GZIP służy jako domyślny konik roboczy środowisk Unix od ponad trzech dekad. Ponieważ jego algorytm DEFLATE działa na małych oknach przesuwających się (32 KB), GZIP wymaga znikomego zużycia pamięci zarówno podczas kompresji, jak i dekompresji.
BZIP2
- Podstawowy algorytm: Burrows-Wheeler Transform (BWT) połączony z transformacją Move-to-Front (MTF) oraz kodowaniem Huffmana
- Domyślne rozszerzenie:
.tar.bz2,.tbz2,.bz2 - Era wydania: 1996 (stworzony przez Julian Seward)
- Główna zaleta: Lepsze współczynniki kompresji przy powtarzalnych plikach ASCII i strukturalnych plikach logów niż GZIP.
- Główna wada: Wolniejszy we wszystkich aspektach, szczególnie podczas dekompresji, i w dużej mierze wycofany przez nowsze algorytmy.
BZIP2 przetwarza dane w dyskretnych blokach (zazwyczaj 900 KB) przy użyciu odwracalnych permutacji, które grupują podobne znaki przed kodowaniem. Choć w późnych latach 90. i w latach 2000 był szeroko chwalony za uzyskiwanie mniejszych rozmiarów plików niż GZIP, jego koszt obliczeniowy jest stosunkowo wysoki.
XZ (LZMA2)
- Podstawowy algorytm: LZMA2 (Lempel-Ziv-Markov chain Algorithm, improved)
- Domyślne rozszerzenie:
.tar.xz,.txz,.xz - Era wydania: 2009 (wprowadzono, aby zastąpić starszy format
lzma) - Główna zaleta: Niezwykle wysokie współczynniki kompresji oraz szybka, lekka dekompresja.
- Główna wada: Duże zużycie pamięci RAM oraz wydłużony czas pracy procesora podczas początkowej kompresji.
XZ wykorzystuje zmienne rozmiary słownika (często do 32 MB lub 64 MB domyślnie), aby znajdować powtarzające się wzorce bajtów w znacznie szerszych oknach danych niż GZIP. Dzięki temu jest niezwykle skuteczny w zmniejszaniu dużych, redundantnych plików, takich jak nośniki instalacyjne systemu operacyjnego, drzewa źródeł jądra i obrazy firmware.
2. Macierz porównawcza wydajności
Poniższa tabela podsumowuje praktyczną dynamikę wydajności każdego narzędzia przy uruchamianiu domyślnych konfiguracji na standardowym sprzęcie serwerowym:
| Metryka / Wymiar | GZIP (-6) | BZIP2 (-9) | XZ (-6) |
|---|---|---|---|
| Współczynnik kompresji | Umiarkowane (~65-75% redukcji) | Dobre (~75-80% redukcji) | Wyjątkowe (~80-88% redukcji) |
| Szybkość kompresji | Bardzo szybki | Wolno | Bardzo wolno |
| Szybkość dekompresji | Niezwykle szybki | Wolny do umiarkowanego | Szybki |
| Użycie pamięci RAM przy kompresji | Pomijalne (~1–2 MB) | Niskie (~8–10 MB) | Wysokie (~100–700 MB+) |
| Użycie pamięci RAM przy dekompresji | Pomijalne (< 1 MB) | Niskie (~4 MB) | Umiarkowany (~10–65 MB) |
| Główny optymalny punkt | Logi, potoki CI/CD, strumienie w czasie rzeczywistym | Kompatybilność z archiwami starszej generacji | Repozytoria pakietów, obrazy ISO systemów operacyjnych, zimne przechowywanie |
3. Wnioski z benchmarków w rzeczywistych warunkach
Aby zrozumieć, jak te narzędzia zachowują się przy realistycznym obciążeniu, rozważ reprezentatywny surowy dziennik dostępu serwera o pojemności 1 GB oraz nieskompresowany katalog kodu źródłowego o wielkości 500 MB.
Scenariusz A: Kompresowanie dużych plików dziennika (tekst 1 GB)
- GZIP: Zakończa w mniej niż 12 sekund, tworząc archiwum o wielkości około 180 MB.
- BZIP2: Zakończa w przybliżeniu 45–50 sekund, zmniejszając plik do około 130 MB.
- XZ: Trwa 80–90 sekund przy domyślnych ustawieniach, dając archiwum o wielkości około 95 MB.
Scenariusz B: Obciążenia dekompresji
Krytyczna miara, często pomijana, to asymetria.
- GZIP dekompresuje w 2–3 sekundy przy mikroskopijnym zużyciu pamięci.
- XZ dekompresuje w 4–6 sekund. Chociaż początkowa kompresja była wolna, rozpakowywanie
.xzjest prawie tak szybkie jak rozpakowywanie.gz. - BZIP2 wymaga około 25–30 sekund tylko na rozpakowanie, ponieważ odwracanie transformacji Burrowsa‑Wheelera jest obliczeniowo symetryczne wobec jej kodowania.
4. Dlaczego BZIP2 traci popularność
W nowoczesnej infrastrukturze BZIP2 znajduje się w niezręcznym środku:
- Przegrywa w szybkości z GZIP: Jeśli istotne są opóźnienia przetwarzania lub niskie zużycie CPU, GZIP jest znacznie szybszy.
- Przegrywa w gęstości z XZ: Jeśli ważna jest oszczędność pasma i efektywność przechowywania, XZ generuje znacznie mniejsze archiwa.
- Przegrywany pod względem szybkości dekompresji przez oba: W systemach dystrybucji oprogramowania klienci ponoszą wymierny koszt CPU przy rozpakowywaniu plików
.tar.bz2w porównaniu do.tar.gzlub.tar.xz.
W konsekwencji główne dystrybucje Linuksa (w tym Debian, Arch i Fedora) przeniosły swoje oficjalne pakiety oraz archiwa jądra z BZIP2 na XZ (a ostatnio na Zstandard w operacjach runtime).
5. Praktyczne użycie wiersza poleceń
Integracja z Tar (najbardziej powszechny przepływ pracy)
Nowoczesne implementacje GNU tar automatycznie rozpoznają format kompresji na podstawie rozszerzenia pliku, ale używanie jawnych flag wciąż jest standardową praktyką:
# GZIP: Fast archive creation
tar -czvf project-backup.tar.gz /var/www/project/
# BZIP2: Legacy high-ratio archive
tar -cjvf project-backup.tar.bz2 /var/www/project/
# XZ: Maximum space savings
tar -cJvf project-backup.tar.xz /var/www/project/
# Generic extraction (tar auto-detects the format)
tar -xvf archive-name.tar.*
Samodzielna kompresja plików
Aby skompresować pojedyncze pliki bez łączenia:
# Compress keeping the original file intact (-k)
gzip -k access.log # Output: access.log.gz
bzip2 -k access.log # Output: access.log.bz2
xz -k access.log # Output: access.log.xz
# Decompress individual files
gzip -d access.log.gz
bzip2 -d access.log.bz2
xz -d access.log.xz
Wykorzystanie systemów wielordzeniowych
Domyślnie jednowątkowe implementacje tych narzędzi używają tylko jednego rdzenia CPU. Jeśli kompresujesz archiwa wielogigabajtowe na nowoczesnych serwerach wielordzeniowych, przetwarzanie jednowątkowe może trwać godziny.
- Wielowątkowość XZ: Natywne wsparcie poprzez
-Tlub--threads:xz -T0 -k database_dump.sql # Uses all available CPU cores - Równoległy GZIP (
pigz): Bezpośredni zamiennik, który wykorzystuje wszystkie rdzenie CPU do operacji GZIP:pigz -k database_dump.sql - Równoległy BZIP2 (
pbzip2): Wielowątkowa implementacja dla BZIP2:pbzip2 -k database_dump.sql
6. Jak wybrać: Praktyczne ramy decyzyjne
Wybierz narzędzie w oparciu o główne ograniczenie w twoim przepływie pracy:
Użyj GZIP, jeśli:
- Konfigurujesz kompresję strumieniową w czasie rzeczywistym lub transmisję sieciową, gdzie przepustowość jest czynnikiem ograniczającym.
- Zarządzasz automatycznym rotowaniem logów (
logrotate) na serwerach produkcyjnych, gdzie zasoby CPU muszą być zarezerwowane dla obciążeń aplikacji. - Wymagana jest maksymalna przenośność pomiędzy starszymi systemami wbudowanymi a standardowymi obrazami bazowymi.
Użyj XZ, jeśli:
- Publikujesz artefakty wydań, kompilacje jądra, obrazy bazowe kontenerów lub statyczne repozytoria pakietów, które są często pobierane przez podmioty trzecie.
- Przygotowujesz długoterminowe zimne archiwa (zdalne cotygodniowe/miesięczne kopie zapasowe), w których koszty przechowywania przewyższają jednorazowy czas kompresji.
- Potrzebujesz małych rozmiarów plików, ale twoi odbiorcy nadal wymagają szybkiego pobierania i krótkiego czasu rozpakowywania.
Zachowaj BZIP2 tylko, jeśli:
- Utrzymujesz kompatybilność wsteczną ze starszymi skryptami, istniejącymi procedurami przywracania kopii zapasowych lub urządzeniami programowymi, które nie dostarczają dekompresora XZ.
7. Najczęściej zadawane pytania (FAQ)
P1. Który format zapewnia najmniejszy rozmiar archiwum? XZ konsekwentnie generuje najmniejszy rozmiar archiwum spośród trzech, dzięki większym oknom słownika LZMA2.
P2. Czy XZ jest wolniejszy niż GZIP przy dekompresji plików? XZ jest tylko nieco wolniejszy niż GZIP przy dekompresji, ale jest znacznie szybszy niż BZIP2.
P3. Czy GZIP i XZ mogą korzystać z wielu rdzeni CPU? XZ obsługuje natywne wielowątkowość przy użyciu flagi -T0, podczas gdy GZIP może być równolegle uruchamiany na wielu rdzeniach przy użyciu narzędzia pigz.
P4. Dlaczego dystrybucje Linuksa rezygnują z BZIP2? Dystrybucje w dużej mierze wycofały BZIP2, ponieważ XZ kompresuje do mniejszych rozmiarów i dekompresuje szybciej, podczas gdy GZIP pozostaje szybszy w szybkich operacjach.
P5. Czy wyższy poziom kompresji, taki jak -9, robi zauważalną różnicę? Ustawienie poziomu -9 przynosi jedynie marginalne zmniejszenie rozmiaru o 1% do 3% średnio, przy jednoczesnym dramatycznym zwiększeniu zużycia cykli CPU i obciążenia pamięci.