par komentu k tematu:
- XZ ma jeste "extreme" (-x) mode, vzdy o dost delsi casy, nekdy zajimave
vylepseni maximalni komprese - to pouze pridava vypocetni narocnost beze zmeny
naroku na pamet - v ucritych situacich muze byt vyhodnejsi pouzit -6e namisto
-9, aby se usetrila RAM pri cca stejnem vysledku komprese srovnej:
Preset DictSize CompCPU CompMem DecMem
-0 256 KiB 0 3 MiB 1 MiB
-1 1 MiB 1 9 MiB 2 MiB
-2 2 MiB 2 17 MiB 3 MiB
-3 4 MiB 3 32 MiB 5 MiB
-4 4 MiB 4 48 MiB 5 MiB
-5 8 MiB 5 94 MiB 9 MiB
-6 8 MiB 6 94 MiB 9 MiB
-7 16 MiB 6 186 MiB 17 MiB
-8 32 MiB 6 370 MiB 33 MiB
-9 64 MiB 6 674 MiB 65 MiB
Preset DictSize CompCPU CompMem DecMem
-0e 256 KiB 8 4 MiB 1 MiB
-1e 1 MiB 8 13 MiB 2 MiB
-2e 2 MiB 8 25 MiB 3 MiB
-3e 4 MiB 7 48 MiB 5 MiB
-4e 4 MiB 8 48 MiB 5 MiB
-5e 8 MiB 7 94 MiB 9 MiB
-6e 8 MiB 8 94 MiB 9 MiB
-7e 16 MiB 8 186 MiB 17 MiB
-8e 32 MiB 8 370 MiB 33 MiB
-9e 64 MiB 8 674 MiB 65 MiB
- XZ se da narozdil od LZMA taky paralelizovat, defaultne zalezi na buildu,
ale myslim, ze to edefaultne bezi ve dvou vlaknech; tim se snizuje ovsem
stupen komprese, protoze se vlastne vytvareji dva solid archivy, namisto
jednoho (nebo vic nez dva pri vyssim stupni paralelizace)
- na serverech obvykle nechceme vsechna jadra zatizit jednou archivacni
operaci, ktera klidanko muze bezet hodiny, aniz by to nekoho trapilo, naopak,
je vyhodne co nejmin zatizit I/O, pokud predpokladame, ze na danem serveru
bezi dulezita sluzba, a komprimujeme pouze nejake logy, ktere se nasledne
budou nekam odsouvat, a nemusi to byt HNED, ale naopak to nesmi vyrazne
zpomalit chod primarni aplikace... samozrejme, pokud jde o loghost, jehoz
jedina funkce je sbirat a komprimovat logy, pak chceme, aby komprese zabrala
co nejmene strojoveho casu - ale tady zase klidne muze bezet nekolik
soubeznych kompresi ruznych logu z ruznych serveru a spis ne paralelizace
jedne konkretni komprimacni ulohy nas zajima rychlost komprese na jedno
vlakno, aby loghost (pokud se to z nejakeho duvodu nekomprimuje uz na
zdrojovem serveru - pred prenosem pres sit) stihal komprimovat (nebo
prekomprimovat z gzip na xz napriklad) aspon stejnou rychlosti, jakou
prichazeji nove logy...
Mimochodem, kvuli NE-paralelizaci ma prave LZMA2 o trosku lepsi kompresi, nez
XZ.
U XZ (i LZMA, mam pocit) se daji nastavit dalsi parametry. Jako "block-size" -
muze byt indefinite, cimz vytvarime jeden solid block.
LZMA a XZ maji posunuty stupne komprese a taky maji jiny defaultni stupen
komprese:
The default preset level in LZMA Utils is -7 while in XZ Utils it is -6, so
both use an 8 MiB dictionary by default.
dictionary size (cca decompression RAM demands)
Level xz LZMA Utils
-0 256 KiB N/A
-1 1 MiB 64 KiB
-2 2 MiB 1 MiB
-3 4 MiB 512 KiB
-4 4 MiB 1 MiB
-5 8 MiB 2 MiB
-6 8 MiB 4 MiB
-7 16 MiB 8 MiB
-8 32 MiB 16 MiB
-9 64 MiB 32 MiB
compressor memory usage:
Level xz LZMA Utils 4.32.x
-0 3 MiB N/A
-1 9 MiB 2 MiB
-2 17 MiB 12 MiB
-3 32 MiB 12 MiB
-4 48 MiB 16 MiB
-5 94 MiB 26 MiB
-6 94 MiB 45 MiB
-7 186 MiB 83 MiB
-8 370 MiB 159 MiB
-9 674 MiB 311 MiB
Jeste tu je jedna vec: nevim jak lbzip2 a pbzip2, ale lzma/xz maji pomerne
vysoke pametove naroky na kompresi (vyrazne nizsi pak na dekompresi. Pokud
server, ktery provadi kompresi, potrebuje nemit pamet znicehonic zabranou
nejakym silenym kompresnim programem, kterej na jedno vlakeno sezere 674MB,
zvlast pokud komprese probiha na celkem malem virtualnim webserveru s MySQL a
my nechceme, aby se MySQL odswapovaval, pak i jedno vlakno se 674MB pozadavkem
muze byt neprijatelnej narok drasticky (a ne na uplne kratkou dobu)
redukujici vykon primarni aplikace silenym swapovanim...
NO a v neposledni rade tu je otazka, jak casto se predpoklada, ze
zakomprimovana data budem potrebovat dekomprimovat a jake nastroje k tomu
mame u konkretni kompresni metody - v tehle oblasti celkem jasne vede XZ/LZMA,
kterej ma relativne smesny naroky na RAM pri dekompresi a rychlost je vicemene
az neuveritelna (zejmena ve srovnani s Bzip2, dokonce je srovnatelna s gzip
dekompresi - a pokud mame pomale uloziste (USB disk, iSCSI pres 100Mbit...) a
rychly CPU, muze byt u XZ i rychlejsi nez u gzip).
Osobne jsem nadsencem xz -6e nebo -9e ve dvou vlaknech - drtiva vetsina
serveru ma dnes dostatek procesorovych jader, aby dve vytizena vlakna
neovlivnila beh primarni sluzby, ale obcas je problem pozadavek na 2x674MB RAM
pro kompresi fakt moc... takze jeste je dobry to vsechno poustet ve skriptu,
kterej si spocita pocet uz bezicich LZMA nebo XZ vlaken, a ceka, dokud drive
spustenych kompresi bezi nadlimitni mnozstvi pro danej server...
Na loghostech se snazim paralelizovat jen po maximalni rozumne zatizeni,
takze i tam kontrola na podkriticke mnozstvi soubezne bezicich komprimaci je
nutnosti. Lze dodat i umelou inteligenci - mit tech limitu vic, jeden limit
pouze odlozi kompresi, druhy limit preradi na rychlejsi kompresi - pokud je
riziko, ze server nestiha komprimovat potrebnou rychlosti, pripadne snizit na
nizsi pametove naroky, pokud hrozi, ze nebudeme delat nic jineho, nez
swapovat, pripadne i zmena kompresniho programu (prechod od XZ ke GZIPu... s
kontrolnim centralnim souborem, ktery tyto kontroly vytizenosti, resp.
zafronotovanosti systemu si budou centralne udrzovat - nejlepsi je, kdyz
tyhle vsechny skriptiky budou zapisovat do nejakyho souboru cislo aktualne
cekajicich kompresi a velikost souboru ke kompresi, a nasledne by se
aplikoval rozhodujici mechanismus (ten neni sranda pro konkretni vykonnostni
kapacitu serveru odladit, ale da se to), ktery na zaklade "delky fronty"
(spis velikost cekajicich dat ale se zohlednenim na POCET souboru - aby jeden
velkej soubor nezamaval s rozhodovacim procesem nezadoucim zpusobem) budou
urcovat, jaka se pouzije kompresni metoda a parametry, aby fronta nenabyla
oblydnych velikosti - a zase, jakmile se fronta zmensi, lze "pritvrdit" a
nastavit narocnejsi kompresi... A samozrejme idealni by bylo, kdyby se tenhle
celkem jednoduchej mechanismus sam dokazal ucit (coz uz ale zacina byt trochu
narocnejsi tema, nicmene se asi podivam, jestli se timhle uz nekdo zabejval,
protoze ja to vzdycky zatim resil "od oka" a tak, aby to proste ten loghost
stihal s rezervou, resp. se to komprimovalo na zdrojovych serverech, ktery
mely na praci jiny veci, takze komprimovlay xz -
Kazdopadne je dobre mit srovnani casove narocnosti a vysledne komprese! Jen ve
vetsine pripadu tech faktoru k posouzeni je daleko vic, jak jsem popsal
vyse... a pak nastupuji ruzne priority...
Nejlepsi je asi procist si nasledujici stranku:
http://www.maximumcompression.com/
Chtel jsem se ujistit, ze si vybiram dobry kompresor na data. A zjistuju, ze
jsem asi ponekud unahlene presel na xz, i kdyz je velmi pomaly, ale mne se
zdal moderni.
Na typicke uloze vyseku 5*10^8 bajtu textoveho SQL dumpu postgresu (pg_dump)
jsem provedl srovnani a zde je tabulka pro bezne pouzivane i modernejsi
kompresory, tri parametry kvality komprese, dobu komprese a pomer vysledku
k originalu:
lzma -9 476s 12%
xz -9 404s 12%
lzma -6 315s 13%
xz -6 300s 13%
lzma -3 176s 14%
bzip2 -6 49s 15%
bzip2 -9 50s 15%
lbzip2 -9 13s 15%
pbzip2 -9 14s 15%
xz -3 103s 15%
bzip2 -3 46s 16%
lbzip2 -3 10s 16%
lbzip2 -6 12s 16%
pbzip2 -3 10s 16%
pbzip2 -6 11s 16%
gzip -9 38s 19%
gzip -6 16s 20%
gzip -3 8s 23%
Jde o osmijadrovy stroj, takze paralelizacni kompresory lbzip2 a pbzip2
velmi
zamavaji s casy!
Razeno podle posledniho sloupce. Treba se vam to hodi,
T.
CePal
|
