Obecnie niedrogie serwery z wieloma procesorami, czy rdzeniami, są czymś powszechnym. Jednak standardowe programy do kompresji i dekompresji są nadal jednowątkowe, chociaż dostępne są też programy pakujące potrafiące wykorzystać wieloprocesorowość. Dlatego przeprowadziliśmy testy w tym zakresie. Analizując uzyskane dane można wybrać odpowiedni kompresor, w zależności od typu przetwarzanych danych, wymaganego stopnia kompresji, czy też szybkości działania. W ten sposób mamy dane pozwalające wybrać, do prowadzonych projektów najbardziej, adekwatny program.
Do testów wybrałem serwer Intel XEON E5-2699V3 @ 2,3GHz (turbo: 3,6 GHz), 22 nm 18 rdzeni, 36 wątków, 45 MB SmartCache wraz ze 120 GB RAM. Ponieważ pracuję na na maszynie wirtualnej dostępne do testów będzie 16 rdzeni, a dzięki technologii Hyper-Threading system operacyjny będzie widział 32 rdzenie. Serwer w tej konfiguracji wybrałem z powodu tego, że potrzeba zastąpienia standardowych kompresorów zazwyczaj wystąpi przy przetwarzaniu dużych ilości danych, a taki stan łącze ze średnimi i dużymi systemami informatycznymi.
Do testów wybrałem najbardziej popularne programu, a przez to najbardziej sprawdzone. Oprócz programów obecnych w minimalnych dystrybucjach, jak: tar, gzip, bzip2 testom poddaliśmy doinstalowane programy: pigz, lbzip2, pbzip2, squashfs. Należy dokładnie zapoznać się z instrukcjami od poszczególnych programów decyzją o ich użyciu. Czasami np. dekompresja wykorzystuje tylko ograniczoną liczbę rdzeni.
Do testów przygotowaliśmy cztery zestawy danych:
1) Wygenerowane pliki logów. Cztery pliki o rozmiarze 1 GB (po 20 milionów inni w każdym z plików), oraz dwa pliki 100 MB (po 2 miliony inni w każdym z plików). Łącznie 2,3 GB danych zawierających 84 miliony linii. Dane w likach zawierają wiele wspólnych elementów, jak to zazwyczaj w logach, i powinny podlegać znacznej kompresji.
2) 2,3 GB skompresowanych danych w 16 plikach. Do tego testu przygotowaliśmy celowo 16 identycznych plików, by pokazać ciekawą funkcjonalność jednego z użytych programów. Ten test polega na tym, by wykazać zachowanie się programów kompresujących, gdy dane są już mocno spakowane - dlatego filmy są idealne do takiego testu.
3) Kolejny test obejmuje strukturę 107 650 katalogów zawierającymi 380 607 plików. Trzykrotnie rozpakowałem kolekcję FreeBSD Ports (ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz). Tym sposobem można sprawdzić zachowanie się programów przy dużych ilościach plików i katalogów, gdyż nie zawsze obsługa systemu plików jest ich najmocniejszą stroną.
4) Test ostatni polegać będzie na kompresowaniu jednego dużego pliku. Symuluję tutaj kompresowanie dump'a z bazy danych. Zazwyczaj dump'y z bazy danych kompresują się podobnie, jak pliki tekstowe, w stosunku od 1:10 do 1:20. Kompresowanie pojedynczego pliku pozwala sprawdzić zachowanie sie kompresorów wieloprocesorowych w takiej sytuacji. Użyty plik jest prawdziwym dump'em bazy, a jego rozmiar jest kompromisem, pomiędzy zrzutem z dużej bazy, a czasem wykonania testów.
1) Wygenerowane pliki logów. Cztery pliki o rozmiarze 1 GB (po 20 milionów inni w każdym z plików), oraz dwa pliki 100 MB (po 2 miliony inni w każdym z plików). Łącznie 2,3 GB danych zawierających 84 miliony linii. Dane w likach zawierają wiele wspólnych elementów, jak to zazwyczaj w logach, i powinny podlegać znacznej kompresji.
2) 2,3 GB skompresowanych danych w 16 plikach. Do tego testu przygotowaliśmy celowo 16 identycznych plików, by pokazać ciekawą funkcjonalność jednego z użytych programów. Ten test polega na tym, by wykazać zachowanie się programów kompresujących, gdy dane są już mocno spakowane - dlatego filmy są idealne do takiego testu.
3) Kolejny test obejmuje strukturę 107 650 katalogów zawierającymi 380 607 plików. Trzykrotnie rozpakowałem kolekcję FreeBSD Ports (ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports/ports.tar.gz). Tym sposobem można sprawdzić zachowanie się programów przy dużych ilościach plików i katalogów, gdyż nie zawsze obsługa systemu plików jest ich najmocniejszą stroną.
4) Test ostatni polegać będzie na kompresowaniu jednego dużego pliku. Symuluję tutaj kompresowanie dump'a z bazy danych. Zazwyczaj dump'y z bazy danych kompresują się podobnie, jak pliki tekstowe, w stosunku od 1:10 do 1:20. Kompresowanie pojedynczego pliku pozwala sprawdzić zachowanie sie kompresorów wieloprocesorowych w takiej sytuacji. Użyty plik jest prawdziwym dump'em bazy, a jego rozmiar jest kompromisem, pomiędzy zrzutem z dużej bazy, a czasem wykonania testów.
Przygotowane dane do testów:
Poniżej zamieszczam screenshot'y z testów.
Dają istotne informacje o wykorzystaniu zasobów przez różne programy w czasie pracy - zarówno dla wielu plików, jak i dla pojedynczego pliku.
Dają istotne informacje o wykorzystaniu zasobów przez różne programy w czasie pracy - zarówno dla wielu plików, jak i dla pojedynczego pliku.
Wykorzystanie procesorów przez jednowątkowy program kompresujący bzip2:
Kompresowanie programem lbzip2:
Kompresowanie programem pbzip2:
Spakowane trzy typy danych, oprócz testu pliku dump.sql, z podziałem na programy kompresujące:
Kompresowanie programem squashfs wielu małych plików:
Kompresowanie programem squashfs dużego pojedynczego pliku:
System dysków nie był ograniczeniem dla tych testów:
Rozpakowanie programem pigz:
Rozpakowanie programem lbzip2:
Rozpakowanie programem squashfs wielu małych plików:
Rozpakowanie programem squashfs pojedynczego pliku:
Dane z testów:
| *** Compress *** | ||||
| Katalog: log | Rozmiar (kB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do time mksquashfs log/ "$i"log.sq ; done | 117 312 | 15,413 | 14,978 | 15,314 |
| for i in {1..3}; do time tar --use-compress-program=lbzip2 -cf "$i"log.lbzip2 log/; done | 180 927 | 4,826 | 4,842 | 4,911 |
| for i in {1..3}; do time tar -cjf "$i"log.tar.gz2 log/; done | 181 439 | 423,130 | 421,484 | 423,268 |
| for i in {1..3}; do time tar --use-compress-program=pbzip2 -cf "$i"log.pbzip2 log/; done | 181 662 | 16,600 | 15,987 | 16,376 |
| for i in {1..3}; do tar -czf $1log.tar.gz log/; done | 282 866 | 62,911 | 62,521 | 61,621 |
| for i in {1..3}; do time tar --use-compress-program=pigz -cf "$i"log.tar.pigz log/; done | 283 175 | 2,575 | 2,738 | 2,856 |
| for i in {1..3}; do time tar -cf "$i"log.tar log/; done | 2 289 000 | 1,926 | 1,925 | 1,911 |
| Katalog: movie | Rozmiar (kB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do time tar -cf "$i"movie.tar movie/; done | 2 337 000 | 1,949 | 1,967 | 1,949 |
| for i in {1..3}; do time tar --use-compress-program=pigz -cf "$i"movie.tar.pigz movie/; done | 2 335 000 | 3,698 | 3,682 | 3,557 |
| for i in {1..3}; do time tar --use-compress-program=lbzip2 -cf "$i"movie.lbzip2 movie/; done | 2 344 000 | 11,177 | 11,220 | 11,180 |
| for i in {1..3}; do time mksquashfs movie/ "$i"movie.sq ; done | 149 | 14,795 | 14,622 | 14,516 |
| for i in {1..3}; do time tar --use-compress-program=pbzip2 -cf "$i"movie.pbzip2 movie/; done | 2 344 000 | 15,924 | 16,125 | 16,900 |
| for i in {1..3}; do time tar -czf "$i"movie.tar.gz movie/; done | 2 334 000 | 90,480 | 91,467 | 90,887 |
| for i in {1..3}; do time tar -cjf "$i"movie.tar.gz2 movie/; done | 2 344 000 | 394,723 | 394,035 | 394,080 |
| Katalog: ports | Rozmiar (kB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do time tar --use-compress-program=pigz -cf "$i"ports.tar.pigz ports/; done | 156 749 | 3,494 | 3,422 | 3,499 |
| for i in {1..3}; do time tar --use-compress-program=lbzip2 -cf "$i"ports.lbzip2 ports/; done | 123 992 | 3,668 | 3,734 | 3,437 |
| for i in {1..3}; do time tar -cf "$i"ports.tar ports/; done | 1 077 000 | 3,822 | 3,447 | 3,471 |
| for i in {1..3}; do time tar --use-compress-program=pbzip2 -cf "$i"ports.pbzip2 ports/; done | 124 074 | 4,066 | 4,479 | 4,180 |
| for i in {1..3}; do time mksquashfs ports/ "$i"ports.sq ; done | 52 476 | 12,768 | 12,141 | 12,398 |
| for i in {1..3}; do time tar -czf "$i"ports.tar.gz ports/; done | 157 121 | 26,859 | 25,234 | 25,244 |
| for i in {1..3}; do time tar -cjf "$i"ports.tar.gz2 ports/; done | 121 771 | 92,581 | 92,070 | 92,169 |
Przed niektórymi poleceniami dałem komendy kasujące poprzednie archiwa, gdyż niektóre programy były na to "czułe".
Warto zwrócić uwagę na rozmiar archiwum katalogu "movie", gdy kompresorem był squashfs - przypomnę, że do tego testu przygotowaliśmy 16 kopii tego samego pliku. Jak widać program squashfs skorzystał z tego skwapliwie, podobnie jak potrafią to robić nowoczesne systemy plików (jak np.: ZFS).
| *** Decompres *** | ||||
| Katalog: log | Rozmiar (kB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do rm *.txt ; time unsquashfs -f -d . "$i"log.sq ; done | --- | 1,903 | 1,747 | 1,924 |
| for i in {1..3}; do time tar -xf "$i"log.tar ; done | --- | 2,022 | 2,375 | 2,542 |
| for i in {1..3}; do time tar --use-compress-program=pbzip2 -xf "$i"log.pbzip2 ; done | --- | 3,762 | 4,168 | 4,751 |
| for i in {1..3}; do time tar --use-compress-program=lbzip2 -xf "$i"log.lbzip2 ; done | --- | 3,844 | 3,738 | 4,302 |
| for i in {1..3}; do time tar --use-compress-program=pigz -xf "$i"log.tar.pigz ; done | --- | 4,703 | 5,896 | 5,416 |
| for i in {1..3}; do time tar -xzf "$i"log.tar.gz ; done | --- | 14,965 | 14,485 | 14,353 |
| for i in {1..3}; do time tar -xjf "$i"log.tar.gz2 ; done | --- | 71,027 | 71,135 | 71,540 |
| Katalog: movie | Rozmiar (kB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do rm *.mp4 ; time unsquashfs -f -d . "$i"movie.sq ; done | --- | 1,739 | 1,693 | 1,691 |
| for i in {1..3}; do time tar -xf "$i"movie.tar ; done | --- | 2,061 | 2,447 | 3,211 |
| for i in {1..3}; do time tar --use-compress-program=lbzip2 -xf "$i"movie.lbzip2 ; done | --- | 6,303 | 6,122 | 6,137 |
| for i in {1..3}; do time tar --use-compress-program=pigz -xf "$i"movie.tar.pigz ; done | --- | 6,711 | 7,104 | 6,487 |
| for i in {1..3}; do time tar --use-compress-program=pbzip2 -xf "$i"movie.pbzip2 ; done | --- | 7,084 | 7,157 | 7,251 |
| for i in {1..3}; do time tar -xzf "$i"movie.tar.gz ; done | --- | 17,350 | 17,447 | 17,518 |
| for i in {1..3}; do time tar -xjf "$i"movie.tar.gz2 ; done | --- | 197,856 | 197,948 | 199,170 |
| Katalog: ports | Rozmiar (kB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do rm -r ports ; time tar --use-compress-program=pbzip2 -xf "$i"ports.pbzip2 ; done | --- | 21,850 | 24,229 | 25,791 |
| for i in {1..3}; do rm -r ports-0? ; sync ;time unsquashfs -f -d . "$i"ports.sq ; done | --- | 22,526 | 23,980 | 22,605 |
| for i in {1..3}; do rm -r ports ; time tar -xf "$i"ports.tar ; done | --- | 25,382 | 25,485 | 26,900 |
| for i in {1..3}; do rm -r ports ; time tar --use-compress-program=lbzip2 -xf "$i"ports.lbzip2 ; done | --- | 25,940 | 24,944 | 26,902 |
| for i in {1..3}; do rm -r ports ; time tar --use-compress-program=pigz -xf "$i"ports.tar.pigz ; done | --- | 27,695 | 29,627 | 24,790 |
| for i in {1..3}; do rm -r ports ; time tar -xzf "$i"ports.tar.gz ; done | --- | 33,678 | 32,630 | 30,443 |
| for i in {1..3}; do rm -r ports ; time tar -xjf "$i"ports.tar.gz2 ; done | --- | 52,315 | 53,887 | 54,021 |
| *** SQL compress *** | Rozmiar (MB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do time tar -cf "$i"sql.tar sql/; done | 10 140 | 8,864 | 9,045 | 10,354 |
| for i in {1..3}; do time tar --use-compress-program=pigz -cf "$i"sql.tar.pigz sql/; done | 1 529 | 13,227 | 13,382 | 13,109 |
| for i in {1..3}; do time tar --use-compress-program=lbzip2 -cf "$i"sql.lbzip2 sql/; done | 1 146 | 22,387 | 21,839 | 22,362 |
| for i in {1..3}; do time mksquashfs sql/ "$i"sql.sq ; done | 1 467 | 33,979 | 34,232 | 33,757 |
| for i in {1..3}; do time tar --use-compress-program=pbzip2 -cf "$i"sql.pbzip2 sql/; done | 1 150 | 62,993 | 63,208 | 64,049 |
| for i in {1..3}; do time tar -czf "$i"sql.tar.gz sql/; done | 1 532 | 298,638 | 294,853 | 293,020 |
| for i in {1..3}; do time tar -cjf "$i"sql.tar.gz2 sql/; done | 1 149 | 1665,205 | 1662,265 | 1663,702 |
| *** SQL decompres *** | Rozmiar (MB) | Czas (s) | Czas (s) | Czas (s) |
| for i in {1..3}; do rm -r sqldump.sql ; sync ; time unsquashfs -f -d . "$i"sql.sq ; done | --- | 7,51 | 7,547 | 7,549 |
| for i in {1..3}; do time tar -xf "$i"sql.tar ; done | --- | 9,312 | 10,817 | 10,924 |
| for i in {1..3}; do rm -r sql/ ; time tar --use-compress-program=pbzip2 -xf "$i"sql.pbzip2 ; done | --- | 12,228 | 12,338 | 12,383 |
| for i in {1..3}; do rm -r sql/ ; time tar --use-compress-program=lbzip2 -xf "$i"sql.lbzip2 ; done | --- | 12,921 | 12,969 | 12,871 |
| for i in {1..3}; do rm -r sql/ ; time tar --use-compress-program=pigz -xf "$i"sql.tar.pigz ; done | --- | 27,580 | 27,962 | 28,936 |
| for i in {1..3}; do time tar -xzf "$i"sql.tar.gz ; done | --- | 74,247 | 76,322 | 79,398 |
| for i in {1..3}; do time tar -xjf "$i"sql.tar.gz2 ; done | --- | 273,099 | 272,989 | 272,595 |
Programy kompresujące:
Program gzip wykorzystuje algorytm kompresji znany jako "DEFLATE" - stosowany np.: w PNG, HTTP, SSH. Jego największa zaletą jest szybkość i niskie zużycie zasobów (choć wymaga czasami więcej pamięci).
Kompresor bzip2 powstał w 1996 r. Jego szczególną cecha jest wysoki stopień kompresji i powolne działania. Zaimplementowano w nie algorytmu Burrows-Wheeler, który jest dużo bardziej skomplikowany niż "DEFLATE" z gzip'a, ale nie wymaga więcej pamięci.
SquashFS w tym teście znalazł się, ponieważ ma bardzo dobre "osiągi". Nie jest to typowy program kompresujący i nie wszędzie znajdzie zastosowanie. Jest to skompresowany system plików (zamontowany jako system plików jest tylko do odczytu). Do kompresji używa programu gzip, ale potrafi też użyć: lzma, lzo, xz. Wykorzystany jest dystrybucje live CD, np.: Backtrack, Debian, Knoppix, OpenWrt. Przykłady użycia:
Przełączniki dla tar'a:
gzip:
tar czvf misc.tar.gz misc/
tar czvf misc.tar.gz misc/
bzip2:
tar cjvf misc.tar.bz2 misc/
tar cjvf misc.tar.bz2 misc/
xz:
tar cJvf misc.tar.xz misc/
tar cJvf misc.tar.xz misc/
***
Inne wpisy:
Oświetlenie miejsca pracy
Oświetlenie LED łazienki (małej)
Zużycie prądu przez suszarkę do ubrań i pralkę
Zużycie prądu przez urządzenia domowe i ich współczynnik mocy cos phi (cosφ)
Modernizacja oświetlenia głównego w dużym pokoju i przedpokoju
Oświetlenie LED łazienki (małej)
Zużycie prądu przez suszarkę do ubrań i pralkę
Zużycie prądu przez urządzenia domowe i ich współczynnik mocy cos phi (cosφ)
Modernizacja oświetlenia głównego w dużym pokoju i przedpokoju
Update: 2018.07.17
Create: 2018.07.17