Koudink
Dalsi
Seznam
Predchozi
Autor: CePal (#@#%#^%&%*) on 'Koudink'
Cas: Ut 23.9.2014 18:31.56
Titulek: Re: Tip: Pruzkum efektivnosti soucasnych kompresoru na SQL du

                                                                                 
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

Dalsi Seznam Predchozi


[ Domu | Prstik | O Piskovisti | Deticky | Nastenky | Koutky ]