Szybkie kompresowanie dużej liczby dużych plików

16

Codziennie generuję około 200 GB danych dziennika, rozmieszczonych w około 150 różnych plikach dziennika.

Mam skrypt, który przenosi pliki do tymczasowej lokalizacji i wykonuje tar-bz2 w katalogu tymczasowym.

Otrzymuję dobre wyniki, ponieważ dzienniki 200 GB są skompresowane do około 12-15 GB.

Problem polega na tym, że kompresja plików trwa wieczność. Zadanie cron jest uruchamiane codziennie o 2:30 i trwa do 17:00 - 18:00.

Czy istnieje sposób na poprawę szybkości kompresji i szybsze zakończenie pracy? Jakieś pomysły?

Nie martw się o inne procesy i wszystko, gdzie odbywa się kompresja, znajduje się na NAS , a ja mogę uruchomić zamontować NAS na dedykowanej maszynie wirtualnej i uruchomić skrypt kompresji z tego miejsca.

Oto wynik działania top w celach informacyjnych:

top - 15:53:50 up 1093 days,  6:36,  1 user,  load average: 1.00, 1.05, 1.07
Tasks: 101 total,   3 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s): 25.1%us,  0.7%sy,  0.0%ni, 74.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.1%st
Mem:   8388608k total,  8334844k used,    53764k free,     9800k buffers
Swap: 12550136k total,      488k used, 12549648k free,  4936168k cached
 PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7086 appmon    18   0 13256 7880  440 R 96.7  0.1 791:16.83 bzip2
7085  appmon    18   0 19452 1148  856 S  0.0  0.0   1:45.41 tar cjvf /nwk_storelogs/compressed_logs/compressed_logs_2016_30_04.tar.bz2 /nwk_storelogs/temp/ASPEN-GC-32459:nkp-aspn-1014.log /nwk_stor
30756 appmon    15   0 85952 1944 1000 S  0.0  0.0   0:00.00 sshd: appmon@pts/0
30757 appmon    15   0 64884 1816 1032 S  0.0  0.0   0:00.01 -tcsh

— anu
źródło

2

Jeśli masz wiele procesorów i możesz go podzielić na wiele plików tar, możesz uruchomić wiele kompresji.

— Jeff Schaller

@JeffSchaller czy byłoby możliwe uzyskanie wielu procesów bzip2 kompresujących różne pliki, ale zapisujących do tego samego tar.bz2pliku?

— anu

2

Czy pliki dziennika są generowane na dysku lokalnym przed przejściem na NAS? Jeśli tak, to kompresuj, a następnie przesuń się; w ten sposób podczas kompresji wysyłasz tylko 15 GB danych zamiast 100 (ruch), a następnie 115 (100 odczyt + 15 zapis). Alternatywnie wygląda na to, że możesz być związany procesorem z tym samym procesem bzip2, więc może działać wiele równolegle (jeden na procesor), dopóki nie osiągniesz limitu we / wy. Lub użyj prostszej kompresji (np. „Gzip -1”). Nie zaoszczędzi tyle miejsca na dysku, ale będzie działać szybciej.

— Stephen Harris

@ Sukminder Na pewno spróbuję tego i zobaczę różnicę wielkości. Dzięki.

— anu

Twoje topdane wyjściowe pokazują, że bzip2proces jednowątkowy wykorzystuje maksymalnie jeden rdzeń, ale używasz go w systemie czterordzeniowym (jeden proces z wykorzystaniem 100% procesora -> 25.1%czas procesora w przestrzeni użytkownika, 74% bezczynności). Tak więc przy drobnych zmianach możesz jechać 4x szybciej, chyba że coś innego stanie się wąskim gardłem. Przeczytaj uważnie odpowiedź Gillesa. Rozważ użycie procesora w tym samym polu, co dyski przechowujące dane w celu wykonania kompresji. (Możesz nawet kompresować niektóre pliki na jednym urządzeniu, inne na drugim i archiwizować później, więc oba procesory zostaną wykorzystane.)

— Peter Cordes

25

Pierwszym krokiem jest ustalenie, na czym polega wąskie gardło: czy jest to dyskowe we / wy, sieciowe we / wy czy procesor?

Jeśli wąskim gardłem jest dysk I / O, niewiele możesz zrobić. Upewnij się, że dyski nie obsługują wielu równoległych żądań, ponieważ może to tylko zmniejszyć wydajność.

Jeśli wąskim gardłem jest sieciowe we / wy, uruchom proces kompresji na komputerze, na którym przechowywane są pliki: uruchomienie go na maszynie z mocniejszym procesorem pomaga tylko wtedy, gdy procesor jest wąskim gardłem.

Jeśli wąskim gardłem jest procesor, pierwszą rzeczą do rozważenia jest zastosowanie szybszego algorytmu kompresji. Bzip2 niekoniecznie jest złym wyborem - jego główną słabością jest szybkość dekompresji - ale możesz użyć gzip i poświęcić trochę czasu na szybkość kompresji, lub wypróbować inne formaty, takie jak lzop lub lzma. Możesz także dostroić poziom kompresji: domyślnie bzip2 to -9(maksymalny rozmiar bloku, więc maksymalna kompresja, ale także najdłuższy czas kompresji); ustaw zmienną środowiskową BZIP2na wartość podobną -3do wypróbowania poziomu kompresji 3. Ten wątek i ten wątek omawiają popularne algorytmy kompresji; w szczególności ten post na blogu cytowany przez derobert podaje pewne punkty odniesienia, które sugerują, że gzip -9lubbzip2 na niskim poziomie może być dobrym kompromisem w porównaniu do bzip2 -9. Ten inny punkt odniesieniaktóry zawiera również lzma (algorytm 7zip, więc możesz użyć 7zzamiast tar --lzma) sugeruje tolzma na niskim poziomie można szybciej osiągnąć stopień kompresji bzip2. Prawie każdy wybór inny niż bzip2 poprawi czas dekompresji. Należy pamiętać, że współczynnik kompresji zależy od danych, a szybkość kompresji zależy od wersji programu kompresji, sposobu jego kompilacji i procesora, na którym jest wykonywany.

Inną opcją, jeśli wąskim gardłem jest procesor i masz wiele rdzeni, to równoległe kompresowanie. Można to zrobić na dwa sposoby. Jednym z algorytmów kompresji jest kompresja plików osobno (indywidualnie lub w kilku grupach) i jednoczesne paralleluruchamianie poleceń archiwizacji / kompresji. Może to zmniejszyć współczynnik kompresji, ale zwiększa szybkość pobierania pojedynczego pliku i działa z dowolnym narzędziem. Drugim podejściem jest użycie równoległej implementacji narzędzia do kompresji; ten wątek zawiera kilka.

— Gilles „SO- przestań być zły”
źródło

4

„Jeśli wąskim gardłem są dyskowe operacje we / wy, niewiele można zrobić”. Prawdopodobnie jest to prawda, ponieważ współczynnik kompresji jest już dobry, ale ogólnie, gdy We / Wy jest wąskim gardłem, warto rozważyć użycie większej ilości procesora, aby uzyskać lepszy współczynnik kompresji (przy użyciu różnych ustawień kompresji lub innego algorytmu). .. nie można tak naprawdę zredukować „ja” (ponieważ trzeba odczytać wszystkie dane), ale czasami można znacznie zmniejszyć „O” :-)

— psmears

1

Jeśli powiesz, 7zaby nie tworzyć „stałego” archiwum lub ograniczać rozmiar „stałych” bloków, będzie on uruchamiał wiele wątków LZMA równolegle, IIRC. dane pliku dziennika są szczególnym przypadkiem kompresji, ponieważ zazwyczaj są bardzo redundantne (duże podobieństwo między wierszami). Na pewno warto badania gzip, bzip2i xzna specyficzny plików dziennika PO za, zamiast po prostu patrząc na ogólnych wzorców kompresji, aby wykluczyć wszelkie opcje. Nawet szybko sprężarki są warte rozważenia ( lzop, lz4, snappy).

— Peter Cordes

Preferowany obecnie kompresor LZMA xz. Użyj tar -Jlub --xznie --lzma. .lzmajest uważany za „starszy” format pliku . Wielokrotne iteracje formatów plików do kompresji LZMA to trochę zawstydzenie i coś, co powinni mieć za pierwszym razem. Ale AFAIK jest teraz w zasadzie dobry, a .xz nie zostanie zastąpiony innym formatem plików dla tego samego strumienia kompresji.

— Peter Cordes

7z ma doskonałą kompresję i wielowątkowość, ale ze względu na format archiwum (wymaga indeksu, a może błędów?) Nie sądzę, że można go użyć w środku potoku - nie użyje stdin i stdout w tym samym czasie

— Xen2050

To było naprawdę pomocne i wnikliwe. Mój zespół uznał, że operacja nad NFS była dużym wąskim gardłem.

— anu

16

Możesz zainstalować pigzrównoległy gzip i używać tar z kompresją wielowątkową. Lubić:

tar -I pigz -cf file.tar.gz *

Gdzie -Ijest opcja:

-I, --use-compress-program PROG
  filter through PROG

Oczywiście, jeśli twój NAS nie ma wielu rdzeni / mocnego procesora, i tak jesteś ograniczony mocą procesora.

Szybkość dysku twardego / macierzy, na której działa maszyna wirtualna i kompresja, może również stanowić wąskie gardło.

— labirynty
źródło

1

A jeśli chcesz użyć bzip2, możesz użyć pbzip2lub lbzip2.

— Radovan Garabík

2

To twoja najlepsza odpowiedź. Ale najpierw upewnij się, że twój pierwszy ruch jest w tym samym systemie plików, co oryginalne pliki. W przeciwnym razie twój „ruch” jest tak naprawdę bajtem-kopiuj-następnie-usuń. W tym samym systemie plików ruch to zmiana układu łączy systemu plików. To o rząd wielkości szybciej. Dla moich plików logów, które mają setki gigabajtów, Pigz zrobił różnicę. Możesz powiedzieć, ile równoległych wątków ma zostać uruchomionych. Tak długo, jak twój procesor ma wiele rdzeni, nie spędziłbym dużo czasu na badaniu. Prawdopodobnie będziesz chciał Pigz w każdym przypadku; możesz natychmiast uzyskać przyspieszenie.

— Mike S

Gdy będziesz świrować, spójrz na wyjścia htop i iostat i obserwuj wydajność systemu, jeśli chcesz dalej badać swój system. Ale znowu nie będę już próbował kompresować dużych plików bez Pigz. W nowoczesnym systemie wielordzeniowym głupio jest po prostu go nie używać. To taka natychmiastowa wygrana - zobaczysz.

— Mike S

7

Zdecydowanie najszybszym i najskuteczniejszym sposobem kompresji danych jest wygenerowanie ich mniej.

Jakie rodzaje dzienników generujesz? 200 GB dziennie wydaje się całkiem sporo (chyba że korzystasz z Google lub usługodawcy internetowego ...), weź pod uwagę, że 1 MB tekstu to około 500 stron, więc generujesz równowartość 100 milionów stron tekstu dziennie, będziesz wypełnij bibliotekę kongresową w ciągu tygodnia.

Sprawdź swoje dane dziennika, jeśli możesz je jakoś zmniejszyć i nadal uzyskać to, czego potrzebujesz z dzienników. Na przykład poprzez obniżenie poziomu dziennika lub użycie formatu dziennika terser. Lub jeśli używasz dzienników do statystyk, przetwarzaj statystyki w locie i zrzuć plik z podsumowaniem, a następnie filtruj dzienniki przed kompresją do przechowywania.

— Emily L.
źródło

1

To interesujące rozwiązanie filozoficzne. Rozwiązaniem większości problemów życiowych jest całkowite uniknięcie problemu, prawda? Dopóki ktoś nie przyjrzy się dokładnie sugestii i nie zda sobie sprawy, że jest setki osób i tysiące aprobat, przez które trzeba przejść, aby to osiągnąć.

— anu

1

@anu Nie podano kontekstu do pytania, więc założyłem, że nie. Czy możesz mi powiedzieć, skąd masz tysiące pozwoleń? Wydaje mi się, że to właśnie wymyśliłeś.

— Emily L.,

Głosuję za tym. Jest to często pomijane, ale zauważone, wyjątkowe rozwiązanie wielu problemów życiowych.

— jrw32982 obsługuje Monikę

1

Cóż .. teraz, gdy już tam nie pracuję, mogę przynajmniej powiedzieć, że był to problem w Apple. Mówiąc dokładniej na stosie usług, który obsługuje sklep z aplikacjami online ... więc tak, tysiące zatwierdzeń to właściwie rzeczywistość, ponieważ mają tysiące mikrousług i każda z nich tworzy dzienniki, które muszą zostać skompresowane i będą musiały się podpisać po zmianie ich poziomy rejestrowania itp ... W każdym razie ... opracowaliśmy rozwiązanie dla tego wewnętrznego btw .., które jest prawie równoważne równoległemu gzipowi, który jest przenoszony do innych mikrousług.

— anu

3

Możesz zmniejszyć stopień kompresji (pod względem zaoszczędzonej przestrzeni), aby przyspieszyć. Na początek, bzip2 jest DUŻO wolniejszy niż gzip, choć kompresuje mniejszy. Możesz także zmienić poziom kompresji bzip2, gzip lub większości programów do kompresji, aby zmienić rozmiar na szybkość.

Jeśli nie chcesz handlować rozmiarem prędkości, prawdopodobnie nadal możesz uzyskać taki sam lub mniejszy rozmiar, a jednocześnie uzyskać poprawę prędkości za pomocą kompresora korzystającego z LZMA (na przykład xz).

Jeśli szukasz, znajdziesz testy porównawcze, ale najlepszym rozwiązaniem jest przeprowadzenie testów z własnym plikiem na docelowym sprzęcie.

— EricS
źródło

3

Jeśli jedynym wymaganiem jest to, że kompresja jest szybka , bardzo poleciłbym lz4 .

Jest stosowany w wielu miejscach, w których szybkość kompresji jest ważniejsza niż współczynnik kompresji (np. Systemy plików z przezroczystą kompresją, takie jak ZFS)

— pdo
źródło

Nigdy wcześniej o tym nie słyszałem, czy istnieje program, który prawdopodobnie jest już zainstalowany praktycznie wszędzie, który go używa, np. Xz?

— Xen2050