bzip2 jest zbyt wolny. Dostępnych jest wiele rdzeni

Uruchamiam to polecenie:

pg_dumpall | bzip2 > cluster-$(date --iso).sql.bz2

To trwa zbyt długo. Patrzę na procesy z top. Proces bzip2 zajmuje około 95%, a postgres 5% jednego rdzenia. waWpis jest niska. Oznacza to, że dysk nie stanowi wąskiego gardła.

Co mogę zrobić, aby zwiększyć wydajność?

Może niech bzip2 użyje więcej rdzeni. Serwery mają 16 rdzeni.

Lub użyj alternatywy dla bzip2?

Co mogę zrobić, aby zwiększyć wydajność?

Istnieje wiele algorytmów kompresji i bzip2jest to jeden z tych wolniejszych. Zwykły jest gzipzwykle znacznie szybszy, przy zwykle niewiele gorszej kompresji. Kiedy prędkość jest najważniejsza, lzopjest moim ulubionym. Słaba kompresja, ale och, tak szybko.

Postanowiłem się zabawić i porównać kilka algorytmów, w tym ich równoległe implementacje. Plik wejściowy jest wynikiem pg_dumpallpolecenia na mojej stacji roboczej, pliku SQL 1913 MB. Sprzęt to starszy czterordzeniowy i5. Czasy są zegarem ściennym samego kompresji. Równoległe implementacje są ustawione na wykorzystanie wszystkich 4 rdzeni. Tabela posortowana według prędkości kompresji.

Algorithm     Compressed size        Compression          Decompression

lzop           398MB    20.8%      4.2s    455.6MB/s     3.1s    617.3MB/s
lz4            416MB    21.7%      4.5s    424.2MB/s     1.6s   1181.3MB/s
brotli (q0)    307MB    16.1%      7.3s    262.1MB/s     4.9s    390.5MB/s
brotli (q1)    234MB    12.2%      8.7s    220.0MB/s     4.9s    390.5MB/s
zstd           266MB    13.9%     11.9s    161.1MB/s     3.5s    539.5MB/s
pigz (x4)      232MB    12.1%     13.1s    146.1MB/s     4.2s    455.6MB/s
gzip           232MB    12.1%     39.1s     48.9MB/s     9.2s    208.0MB/s
lbzip2 (x4)    188MB     9.9%     42.0s     45.6MB/s    13.2s    144.9MB/s
pbzip2 (x4)    189MB     9.9%    117.5s     16.3MB/s    20.1s     95.2MB/s
bzip2          189MB     9.9%    273.4s      7.0MB/s    42.8s     44.7MB/s
pixz (x4)      132MB     6.9%    456.3s      4.2MB/s     7.9s    242.2MB/s
xz             132MB     6.9%   1027.8s      1.9MB/s    17.3s    110.6MB/s
brotli (q11)   141MB     7.4%   4979.2s      0.4MB/s     3.6s    531.6MB/s

Jeśli 16 rdzeni twojego serwera jest na tyle bezczynnych, że wszystkie mogą być użyte do kompresji, pbzip2prawdopodobnie zapewnią ci bardzo znaczne przyspieszenie. Ale wciąż potrzebujesz większej prędkości i możesz tolerować ~ 20% większe pliki, gzipto prawdopodobnie najlepszy wybór.

Aktualizacja: Dodałem brotli(patrz odpowiedź TOOGAM) wyniki do tabeli. brotlis ustawienie jakości kompresji ma bardzo duży wpływ na współczynnik kompresji i prędkości, więc dodałam trzy ustawienia ( q0, q1, i q11). Domyślnie jest q11, ale jest bardzo powolny i wciąż gorzej niż xz. q1wygląda jednak bardzo dobrze; taki sam współczynnik kompresji jak gzip, ale 4-5 razy szybszy!

Aktualizacja: Dodano lbzip2(patrz komentarz gmathts) i zstd(komentarz Johnny'ego) do tabeli i posortowano według szybkości kompresji. lbzip2stawia bzip2powrót rodziny w prowadzeniu przez kompresję trzy razy tak szybko, jak pbzip2z wielkim stopniu sprężania! zstdrównież wygląda rozsądnie, ale pokonuje go brotli (q1)zarówno stosunek, jak i prędkość.

Mój oryginalny wniosek, że zwykły gzipjest najlepszym zakładem, zaczyna wyglądać niemal głupio. Choć dla wszechobecności wciąż nie da się go pokonać;)

Użyj pbzip2.

Instrukcja mówi:

pbzip2 jest równoległą implementacją kompresora plików bzip2 sortującego bloki, który wykorzystuje pthreads i osiąga prawie liniowe przyspieszenie na maszynach SMP. Dane wyjściowe tej wersji są w pełni zgodne z wersją bzip2 v1.0.2 lub nowszą (tzn. Wszystko skompresowane za pomocą pbzip2 można zdekompresować za pomocą bzip2).

Automatycznie wykrywa liczbę posiadanych procesorów i odpowiednio tworzy wątki.

• Brotli Google to nowszy format, który zyskał ostatnio szerokie wsparcie w przeglądarkach, ponieważ ma imponującą kompresję, imponującą szybkość i być może najbardziej imponującą kombinację / równowagę obu tych funkcji.

  Niektóre dane:

  Porównanie algorytmów kompresji Brotli, Deflate, Zopfli, LZMA, LZHAM i Bzip2

  • np. ten wykres raportujący liczby pokazujące, że Brotli jest około 6-14 szybszy niż Bzip2.

  CanIUse.com: funkcja: brotli pokazuje obsługę Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari, Opera (ale nie Opera Mini ani Microsoft Internet Explorer).

  Porównanie: Brotli vs deflate vs zopfli vs lzma vs lzham vs bzip2

  • Jeśli szukasz prędkości kompresji, to czego szukasz, to, które linie znajdują się dalej na tym wykresie. (Wpisy na górze tego wykresu pokazują ścisły współczynnik kompresji. Wyższy = węższy. Jeśli jednak priorytetem jest szybkość kompresji, warto zwrócić większą uwagę na to, które linie sięgają dalej na prawo na wykresie.)
  Porównanie: współczynnik kompresji vs prędkość kompresji dla metod 7-Zip ZStandard

• ZStandard Facebooka to kolejna opcja, która dąży do zmniejszenia liczby bitów, ale także kładzie duży nacisk na przechowywanie danych w sposób, który zmniejsza pominięte prognozy, umożliwiając w ten sposób większą prędkość. Strona główna znajduje się pod: Mniejsza i szybsza kompresja danych dzięki ZStandard
• Jaszczurka nie osiąga tak wysokiego poziomu kompresji jak Brotli lub ZStandard, ale może być nieco bardziej zbliżona do kompresji i być nieco szybsza (przynajmniej według tego wykresu, który dotyczy prędkości, chociaż raportuje dekompresję)

Nie wspominałeś o systemie operacyjnym. Jeśli Windows, 7-Zip ze ZStandardem (wersje) to wersja 7-Zip, która została zmodyfikowana w celu zapewnienia obsługi wszystkich tych algorytmów.

Użyj ZSTD . Jeśli jest wystarczająco dobry dla Facebooka, prawdopodobnie jest również wystarczająco dobry dla ciebie.

Mówiąc poważniej, jest całkiem niezły . Teraz używam go do wszystkiego, ponieważ po prostu działa i pozwala handlować prędkością na współczynnik na dużą skalę (najczęściej i tak prędkość ma większe znaczenie niż rozmiar, ponieważ przechowywanie jest tanie, ale prędkość jest wąskim gardłem).
Przy poziomach kompresji, które osiągają porównywalną ogólną kompresję jak bzip2, jest to znacznie szybsze, a jeśli chcesz zapłacić trochę więcej czasu procesora, możesz prawie osiągnąć wyniki podobne do LZMA (chociaż wtedy będzie wolniejsze niż bzip2). Przy nieco gorszych współczynnikach kompresji jest znacznie szybszy niż bzip2 lub jakakolwiek inna alternatywa głównego nurtu.

Teraz kompresujesz zrzut SQL, który jest tak żenująco trywialny, jak to tylko możliwe. Nawet najbiedniejsze kompresory osiągają dobre wyniki na tego rodzaju danych.
Możesz więc działać zstdz niższym poziomem kompresji, który będzie działał dziesiątki razy szybciej i nadal osiąga 95-99% tej samej kompresji dla tych danych.

Jako bonus, jeśli będziesz to robił często i chcesz zainwestować trochę więcej czasu, możesz „trenować” zstdsprężarkę przed czasem, co zwiększa zarówno współczynnik sprężania, jak i prędkość. Pamiętaj, że aby trening działał dobrze, musisz podać mu indywidualne rekordy, a nie całość. Sposób działania narzędzia wymaga treningu wielu małych i nieco podobnych próbek, a nie jednej dużej kropli.

Wygląda na to, że dostosowanie (obniżenie) rozmiaru bloku może mieć znaczący wpływ na czas kompresji.

Oto niektóre wyniki eksperymentu przeprowadzonego na mojej maszynie. Użyłem timepolecenia do pomiaru czasu wykonania. input.txtto plik tekstowy o wielkości ~ 250 MB zawierający dowolne rekordy JSON.

Używanie domyślnego (największego) rozmiaru bloku ( --bestjedynie wybiera domyślne zachowanie):

# time cat input.txt | bzip2 --best > input-compressed-best.txt.bz

real    0m48.918s
user    0m48.397s
sys     0m0.767s

Używając najmniejszego rozmiaru bloku ( --fastargument):

# time cat input.txt | bzip2 --fast > input-compressed-fast.txt.bz

real    0m33.859s
user    0m33.571s
sys     0m0.741s

Było to nieco zaskakujące odkrycie, biorąc pod uwagę, że dokumentacja mówi:

Rozmiar bloku nie ma wpływu na szybkość kompresji i dekompresji