Nejlepší nastavení komprese v 7zip

[Honza1]

Ale pokud jsou data velka do 150 MB na jeden zatah, nema smysl poustet vice vlaken a ani s RAM to nebude tak horke. Pak jeste je do naroku na RAM krome slovniku treba pripocist seznam souboru s kompletnimi cestami da cca 0.5-3 MB na tisic souboru (a nejvic pameti to sezere nakonci vytvareni archivu, kdyz se komprimuje filelist).

To je otázka, jestli pak není komprese s menším slovníkem u takových dat na 4 jádrovém či 8 jádrovém CPU výrazně rychlejší než to hrnout přes jedno jádro.

To je sice pravda, auto chce pro nejlepsi kompresi prave co nejvetsi slovnik (pokud maximum je 150 MB dat do archivu, staci slovnik 192 MB). Nejde mu tak o rychlost.

Avsak velke podobnosti budou i v zalohach z ruznych casu, takze pozdeji jednotlive archivy lze rozbalit a pak data zkomprimovat do jednoho archivu (napr, za den, za mesic, je to 288 zaloh da zen, radove 30-50 GB dat). 7zip umi podobnosti mezi soubory najit.

Ale proc ma zaloha bezet po 5 min, to je prehnane casto. Ono totiz 150 MB dat se maximali kompresi ani za 5 min nemusi stihnout (v pripade textovych dat, slabsi CPU). Pak pobezi vic procesu naraz z jedotlivych casu aproblem muze byt komprimace stejnych dat dvema ruznymi procesy. Pokud to nebude 7zip stihat za 5 min vice nez 50% pripadu, pocet soucasne spustenych procesu bude porad rust.

[Reklama]

[ByCzech]

Ale proc ma zaloha bezet po 5 min, to je prehnane casto. Ono totiz 150 MB dat se maximali kompresi ani za 5 min nemusi stihnout (v pripade textovych dat, slabsi CPU).

Právě proto tady po několikáté upozorňuji na možnost spuštění na více jádrech, protože s větším slovníkem bude snížení množství času nejspíše zanedbatelné, ale náročnost a tím pádem potřeba času stoupá často exponenciálně.

Já osobně bych to řešil úplně jinak, rychle bych to nalil do tarballu a ten bych potom komprimoval třeba paralelním xz (pxz). Ale tazatel se vyloženě ptal na 7-zip, co ho k tomu vede nevím. Třeba to má své důvody, které tady neuvedl, takže se snažím držet zadání i když se mi může zdát už zadání úkrok bokem.

[Lol Phirae]

Ale proc ma zaloha bezet po 5 min, to je prehnane casto.

Jak už konstatovala stará Jirsáková, takhle může "zálohovat" akorát magor. 

[ByCzech]

Ale proc ma zaloha bezet po 5 min, to je prehnane casto.

Jak už konstatovala stará Jirsáková, takhle může "zálohovat" akorát magor. 

Jak jsem už psal, osobně zadání příliš neřeším, kdo ví jaké k tomu má důvody i když mě osobně se to nezdá taky od počátku smysluplné.

[Honza1]

Ale proc ma zaloha bezet po 5 min, to je prehnane casto. Ono totiz 150 MB dat se maximali kompresi ani za 5 min nemusi stihnout (v pripade textovych dat, slabsi CPU).

Právě proto tady po několikáté upozorňuji na možnost spuštění na více jádrech, protože s větším slovníkem bude snížení množství času nejspíše zanedbatelné, ale náročnost a tím pádem potřeba času stoupá často exponenciálně.

To moc nechapu. S vetsim slovnikem se cas spise malicko zvysi. Snizeni velikosti vysledneho archivu je vetsinou minimalni, nekdy az desitky procent.

Pokud by samotna komprese trvala dele nez tech 5 min, zacali by se soucasne spustene ulohy hromadit, bez ohledu na velikost slovniku, az by dosla RAM (nebo nestihal disk), a archiv se nevytvori, na misto toho hlaska Cant't allocate required memory.

Tady vice vlaken nepomaha, velikost slovniku cas moc neovlivni, takze jestli pobezi jedna uloha kratce na vice vlaknech, nebo vic uloh jedno(dvou) vlaknovych - jeden proces zvlada 2 vlakna, tak to moc nesejde. Akorat kdyz kazdy proces zabere 11 GB RAM, tak vic procesu najednou muze byt problem.

Autor ale ma silny stroj, kde i jedno-slovnikovy beh naraz (tedy 2 vlakna) CPU zvladne prakticky vzdy za 5 min 150 MB (to je 0,5 MB/s, coz yvladaji i postarsi PC vetsinou).

Jeden plok-slovnik uziva 2 vlakna, neco v RAM si vezme system. Takze napr. pri 64 GB RAM a 12-vlaknovem CPU lze pri 1024 slovniku LZMA1 zvladat 5 slovniku-bloku naraz multivlaknove (sesty se nevejde do RAM), rychlost jednoho bloku-slovniku-procesu je podle typu dat na znacne rychlem CPU cca 1000-7000 kB/s, celkem tedy 5-35 MB/s, jen vyjimecne pri nekterych datech a ne uplne nejrychlejsim CPU da jeden proces pod 1000 kB/s. Pak je taky otazka, jak to bude stihat disk, 5 procesu najednou, pokud v kazde kmpriovane slozce budou kvanta malinkych souboru, to taky jak cteni z disku, tak samotny kompresni proces razantne zpomali (a zadrsarova struktura se seznamem souboru take vezme neco v RAM u kazdeho procesu).

[Reklama]

[ByCzech]

Právě proto tady po několikáté upozorňuji na možnost spuštění na více jádrech, protože s větším slovníkem bude snížení množství času nejspíše zanedbatelné, ale náročnost a tím pádem potřeba času stoupá často exponenciálně.

To moc nechapu. S vetsim slovnikem se cas spise malicko zvysi. Snizeni velikosti vysledneho archivu je vetsinou minimalni, nekdy az desitky procent.

Pardon chybka, snížení množství dat s větším slovníkem...

[ByCzech]

Autor ale ma silny stroj, kde i jedno-slovnikovy beh naraz (tedy 2 vlakna) CPU zvladne prakticky vzdy za 5 min 150 MB (to je 0,5 MB/s, coz yvladaji i postarsi PC vetsinou).

Otázka je, kde se teda bere těch 150 MB (nových/změněných) dat, když ten stroj z toho co píšete je nejspíš dedikovaný jen na zálohování? ;-)

Víme o tom dost málo, pak to svádí k takovým spekulacím. Nevíme jak moc je stroj vytížen jinými věcmi, či jak moc může být vytížen ve špičce. Velikost slovníku a výše komprese může zacloumat složitostí tedy i potřebným časem na zpracování výrazně a pak je otázka, jestli se to do 5 min stíhá nebo nebo ne. Dle mého názoru je nejlepší zvolit správný poměr mezi úrovní komprese a délkou zpracování, protože na to, abych ušetřil pár kB dat mi nemusí komprimovací program běžet 2× delší dobu, že? Ale jak říkám, víme o tom na co to tazatel potřebuje kulové, takže se trefit do ideálu je docela problém.

[Honza1]

Autor ma k dispozici relativne dost vykonu evidentne.

Ja mam k dispozici 16 GB RAM a 4-jadra - 8 vlaken I7 CPU na 2,2 GHZ.
pouzivam 7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z (pro 7zip-full, jinak je na zacatku misto 7z jen 7za)

Pokud je maximalni velikost slozky 150 MB (i kdyby tato velikost byla porad), pri rychlosti 600-800 kB/s (slozity text), 1300-2000 kB/s (normalni text, html), 2500-4000 kB/s (obrazky, mp3, video) to zvlasdne vzdy.

Jeden slovnik-blog zvladne obsadit 1 jadro - 2 vlakna a pri 1024 MB slovniku vic nez jeden nemuzu spustit.

Pri velikosti slozky 150 MB staci slovnik 256 MB, vic nejde, takhle je cely archiv jeden slovnik (stacil by i 192 MB), pri 256 MB to zabere 2,6 GB RAM (+filelist a adresarova struktutra) a muzi spustit vzhledem k RAM i CPU 4 slovniky-bloky-archivy najednou (u hodne hodne hodne malych soubory ale ne, nestiha ani disk, filelist obsadi ram)

Pokud je max. slozky 150 MB a cas 300 s (5 min), je rychlost potreba 500 Kb/s, coz prakticky VZDY da, mozna ne v nejslozitejsich textech v hodne malych souborech.
A kdyz nahodou ne (jen velmi vyjimecne, nebot velikost slozky jeste navic neni 150 MB alekolisa 5-150 MB, prumernou velikost a pocet souboru autor nezdelil), 2 procesy najednou nevadi a cas mam 10 min na archiv, 15 min pri trech procesech najednou a 20 min pri 4 procesech najednou. A to snad stihne vzdy (125 kB/s je na dost slabem NTB se slozitejsimi daty).

Tazatel ma ale vykonu mnohem vic nez ja, a zbyvajici vykon bude na dalsi veci. V naproste vetsine komprese vezme 2 vlakna a 2,6-3 GB Ram (velku pocetsouboru nebude predpokladam v 5-150 MB, jinak by to razantne zatizilo disk i pri jedne komprimaci najednou a i vic RAM by to sezralo).


RESENI ZADANI TEDY JE:
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=256m -ms=on JmenoArchivuZadane ZBashe.7z
Misto lzma lze i lzma2, nepatrne lepsi.
Neplnohodnota verze 7z ma na zacatku 7za misto 7z

BTW NECHCE NAHODOU TAZATEL ZALOHOVAT LOGY NA OBRIM SERVERU ?
Pri 150 MB a velikost logu 150 B je to milion souboru, kazdy ma svuj sektor na disku. Komprese bude ponekud pomalejsi (na mem PC tak 250-500 kB/s - slozity text, hodne souboru), filelist vezme cca 1,5 GB RAM na kazdy proces a vic jak 2 procesy najednou by muj PC nedal moc dobre (mozna 3, ale to disk bude docela problem, i pri dvou, ale jestli ma autor SSD, tak neresit). Doba komprese 6-10 minut (az 10) a povetsinou 1-2 procesy na jednou (na mem stroji). JENZE nez proskenuje pruzkum adresare celou slozku,jen to bude i prez 5 min mozna a navic velka zatez disklu. takze to by mimo SSD stejne cely plan spadnul.

[Ondrej Nemecek]

Zálohování každých 5min - to vypadá spíš jako replikace :-) Jinými slovy, možná by se našel příhodnější postup.

[tisnik]

Budu zalohovat kazdych 5min slozky ktere maji asi 5-150mb
a potrebuji nejlepsi kompresi (cpu a ramky me nezajimaji)

Jaky je presny duvod, resp. co presne resis za problem? Nestaci nakonec napriklad jen stary dobry rsync?

[oldschool]

Tak jsem vyzkousel ten paq8px. Je to hrozne pomaly, a tudiz dost neprakticky Ale ten vysledok byl dobrej. Pokusni adresar byl 49MB - webarina, node moduly, multimedia. Vsechny kompresni utilitky byli nastaveny na maximalni kompresi. 7z sem pouzil takhle:

Kód: [Vybrat]

7z a -t7z -mmt=2 -mx=9 -mfb=273 -md=1024m -ms=on pokus.7z pokus/
Porovnani

Kód: [Vybrat]

   5.8M Mar 25 10:38 pokus.7z
   8.1M Mar 25 10:23 pokus.rar
   9.0M Mar 25 10:20 pokus.tar.bz2
    11M Mar 25 10:20 pokus.tar.gz
   5.9M Mar 25 10:25 pokus.tar.lzma
   4.4M Mar 25 18:50 pokus.tar.paq8px
    15M Mar 25 10:21 pokus.zip

Paq stazen odtud http://dhost.info/paq8/paq8px_v69.zip a kompilace pres

Kód: [Vybrat]

g++ paq8px_v69.cpp -DUNIX -DNOASM -O3 -march=core2 -Os -s -fomit-frame-pointer -o paq8px_v69

Komprimovalo to bratru skoro 2h

Kód: [Vybrat]

Total 48447488 bytes compressed to 4636908 bytes.
Time 5842.26 sec, used 905898471 bytes of memory


[JardaP .]

@oldschool: Jeste byste pro psinu mohl pridat ppmd, schvalne, jak dopadne.

[Honza1]

@oldschool:

Multimedia (obazky a videa) nezkomprimuje moz zadny komresor, nebot jiz komprimovana jsou.

Obrazky BMP, text, html, dokumenty Office (nekoprimovany format hlavne, bez obrazku) zvladne vse dobre, rozdily RAR,ZIP,7z jsou velke (7z je novejsi a lepsi).

Dulezota je moznost najit podobnosti mezi ruznymi soubory akomprimace filelist, adresarove struktury.

paq8px dal cca 25 MB za hodinu, to je cca 7,2 kB/s (cca 3000-5000x pomalejsi nez 7z), 2x rychlejsi nez pripojeni dial up a stahovani dat. Archiv je velky 76% velikosti 7z archivu. Jaka je spotreba CPU,RAM ?

[Herkulesk]

Pro bezneho smrtelnika uz 7zip staci pro maximalni kompresi dat -mx=9 a pouzijese lzma ze?

[Lojza]

mohl by mi nekdo priblizit co to je a jak funguje ten "slovnik"? to ma v sobe 7zip nebo si ho z neceho vytvari ? stejne tak nerozumim jak bych mel 7zip nastavit aby vyuzival "podobnosti"s jiz vytvorenymi archivy

jinak pred par lety jsem cetl par benchamrku a rar mel nejlepsi pomer rychlost/vysledna velikost archivu, 7zip byl o par procent lepsi co do velikosti vysledneho archivu ale za cenu ze byl o mnoho pomalejsi

imho nastaveni maximalni komprese (aspon u raru) ma za nasledek zcela neobhajitelne zvyseni casu vytvareneho archivu za cenu jen par jednotek procent  snizeni velikosti vysledneho archivu (predpokladam podobne chovani i u 7zip mezi volbou komprese normal a ultra, nezkousel jsem)