☰

» »

Kompresija velikih fajlov

Kompresija velikih fajlov

MrStein ::

TLDR: lrzip

Long:

Za večje fajle (več gigabajtov) lrzip povozi "klasične" algoritme.

kaj                velikost          čas kompresije

original fajl       119 GB   
LZ4                  75 GB           zelo hitro
gzip                 65 GB           pol ure?
bzip2                64 GB           ura-dve
lrzip                50 GB           tri ure
lrzip -U             30 GB !!!       30 ur (!)

Detajli kompresije:

lrzip                
  Compression Ratio: 2.426. Average Compression Speed: 10.934MB/s.
  Total time: 03:06:07.02
lrzip -U         
  Compression Ratio: 4.060. Average Compression Speed:  0.849MB/s.
  Total time: 39:57:50.90


Testni fajl je image od sistemskega SSD, vsebuje Windows, nekaj programov, nekaj dokumentov, in nekaj virtualk. Zasedenih je okoli 100GB.

Vsi programi zagnani z default parametri (torej z nobenimi), razen zadnjega, kjer je bil podan parameter -U

lrzip je standarden program v večini linux distribucij.
Za Windows na voljo v cygwin (32 bitna verzija je bugasta! uporabite 64bitno).

Sorodne aplikacije: Rzip @ Wikipedia

Če kdo najde kaj s še večjo kompresijo, pa sem all ears


PS: lrzip zahteva (za kompresijo) ogromno RAM-a. Idealno toliko, kot je velik vhodni fajl. Se pa poznajo učinki tudi z manj RAM-a.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
  • spremenil: MrStein ()

hojnikb ::

PAQ8
#brezpodpisa

Miha 333 ::

Mislim, da če bi ostale programe zagnal z ukazom za večjo kompresijo, bi bil rezultat podoben (velikost in čas). Pač imajo za privzeto manjšo oz. hitrejšo kompresijo. Tu gre vedno za tradeoff med časom in stopnjo stiskanja.

SasoS ::

Primerjava z LZMA2 (7zip)?

terryww ::

Odvisno kaj iščeš, ampak načeloma je pri tem pomembnih več stvari, ne samo kompresija:

    čas dekompresije: če je tudi e.g. 30h, potem je uporabnost kvečjemu za arhiviranje
    zmožnost dekompresije on the fly - zip arhiv recimo ne rabiš celga razpakirat, da bi prišel do enega fajla. Lahko procesiraš celo zip-an arhiv ne da bi del arhiva (recimo nek PDF) potreboval odpakirat.
    primernost za dolgoročno shranjevanje: niso vsa kompresijska orodja primerna za dolgoročno arhiviranje - https://www.nongnu.org/lzip/xz_inadequa...
    uporaba resourceov: koliko RAM-a porabi in ali zna uporabit več jeder
It is the night. My body's weak.
I'm on the run. No time to sleep.

Zgodovina sprememb…

  • spremenil: terryww ()

MrStein ::

Miha 333 je izjavil:

Mislim, da če bi ostale programe zagnal z ukazom za večjo kompresijo, bi bil rezultat podoben (velikost in čas). Pač imajo za privzeto manjšo oz. hitrejšo kompresijo. Tu gre vedno za tradeoff med časom in stopnjo stiskanja.

Misliš ali veš? ;)

default kompresija za gzip je -6 in sprememba na -9 doprinese ... skoraj nič:
gzip (-6)       69.876.916.408 bytes
gzip -9         69.406.146.403 bytes


Tule je ena primerjava med Gzip, Bzip2, LZMA, XZ, LZ4 in LZO, kjer se vidi, da sprememba opcij malo spremeni, a ne more algoritma premakniti iz svojega razreda:

https://catchchallenger.first-world.inf...
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

hojnikb ::

na konc dneva dost zavisi od tega, kaj sploh stiskas. Ce je tvoja knjizica vecinoma slik, mp3jov in filmov, tut z paq kompresorji ne profitiras kej dost.
Profitiras pa ce pretvoris v kaksen drug, bol efficient format (filmovje v h265/VP9/AV1, muska v aac....)
#brezpodpisa

pegasus ::

... arraye in matrike float vrednosti z ZFP ali SZ ...

MrStein ::

Še en test (za VMDK fajl velikosti 48.707.076.096 bytes - ena virtualka z Windows, nekaj programi, nekaj dokumenti)

lrzip v0.631 (cygwin)
zpaq64 v7.15
program      stisnjena velikost        čas stiskanja
-------------------------------------------------------
zpaq        14.678.374.745 bytes       11 minut
zpaq -m2    13.746.023.258 bytes       42 minut
zpaq -m5    10.610.201.221 bytes        7 ur
lrzip        9.397.430.931 bytes       42 minut
lrzip -l    13.978.839.455 bytes       29 minut


Če kdo ne pozna programov:

Za zpaq so "-m2" opcije za "stopnjo stiskanja", torej algoritem in parametri. Default je -m1 , višje številke pa bolj stisnejo (in dlje trajajo).

Za lrzip je -l "hitrejše stiskanje".
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

igorpec ::

SasoS je izjavil:

Primerjava z LZMA2 (7zip)?


@stein

Če se ravno igraš, probaj še 7z pod istimi pogoji ... BTW. Mi uporabljamo tar.lz4 za stiskanje rootfs, kar se je izkazalo za best compress speed/size/un-compress speed ratio. Vsaj za faile reda nekaj giga. Me tudi zanima, če obstaja kaj boljšega za takšen use case, kjer šteje vse.

MrStein ::

MrStein je izjavil:

TLDR


Dodajam v tabelo ZPAQ in 7zip (po prazni vrstici)
kaj                velikost          čas kompresije

original fajl       119 GB   
LZ4                  75 GB           zelo hitro
gzip                 65 GB           pol ure?
bzip2                64 GB           ura-dve
lrzip                50 GB           tri ure
lrzip -U             30 GB !!!       30 ur (!)

zpaq                 40 GB           pol ure
zpaq -m2             40 GB           pol ure
zpaq -m6             32 GB           65 ur
7zip -ultimate       55 GB           3-5 ur


zpaq je zpaq64.exe verzija 7.15
7-zip je verzija 19.00 (64 bit)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

WhiteAngel ::

MrStein je izjavil:

MrStein je izjavil:

TLDR


Dodajam v tabelo ZPAQ in 7zip (po prazni vrstici)

 kaj velikost čas kompresije
 
 original fajl 119 GB 
 LZ4 75 GB zelo hitro
 gzip 65 GB pol ure?
 bzip2 64 GB ura-dve
 lrzip 50 GB tri ure
 lrzip -U 30 GB !!! 30 ur (!)
 
 zpaq 40 GB pol ure
 zpaq -m2 40 GB pol ure
 zpaq -m6 32 GB 65 ur
 7zip -ultimate 55 GB 3-5 ur


zpaq je zpaq64.exe verzija 7.15
7-zip je verzija 19.00 (64 bit)


Tele številke bi bile zanimive, če bi imel 128GiB rama in bi šlo vse noter.

bf4ed ::

Zgleda je zpaq najboljši pri hitrost/kompresija...na 40GB v pol ure je super proti drugim.

krho ::

kje si pa zstd zgubil?
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

MrStein ::

Kaj, a samo jaz imam računalnik? Nihče vam ne brani, da svoje meritve izvedete.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

krho ::

Jah, če že testiraš ne moreš mimo najnovejšega compressorja. Pa če drugi testiramo nima smisla.. k nimamo tvojega fajla.
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net

MrStein ::

Testiraš pač na svojem fajlu. Ta moj nima nobenih posebnih lastnosti.

Lahko pa kdo linka zstd build za win64, pa testiram, če že drugi ne morete...
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

WizzardOfOZ ::

Test: na 32 threadih zapakirati en vhdx (virtualka: windows 10 + sql server + visual studio + celoten projek) v velikosti 49.5GB
(53.255.077.888)
Nastavitve 7Z:
Compression level: Ultra
compression method: LZMA2
dictionary size: 64Mb
word size: 64
solid block size: 4GB
cpu threads: 32
memory usage for compressing: 19GB
********************************************

Čas pakiranja: 00:16:49 (skoraj 17 minut)
compression ratio: 26%
7z file: 13GB (14.043.591.809)


xeon E5-2683 V4, 128GB rama NVME ssd disk Samsung 970 Evo 250GB

terryww ::

Tu je drugače en program, ki podpira tudi zstd ipd.: https://github.com/mcmilk/7-Zip-zstd
It is the night. My body's weak.
I'm on the run. No time to sleep.

MrStein ::

MrStein je izjavil:


Dodajam v tabelo ZPAQ in 7zip (po prazni vrstici)

... ter : čas dekompresije, zstd, ter kombinacija lrzip preprocesiranja z drugimi kompresorji (na koncu, kjer je plus znak)

kaj                velikost          čas kompresije   dekompresija

original fajl       119 GB   
LZ4                  75 GB           zelo hitro
gzip                 65 GB           pol ure?
bzip2                64 GB           ura-dve
lrzip                50 GB           tri ure
lrzip -U             30 GB !!!       30 ur (!)         1h 10min

zpaq                 40 GB           pol ure
zpaq -m2             40 GB           pol ure
zpaq -m6             32 GB           65 ur
7zip -ultimate       55 GB           3-5 ur

zstd -T4             64 GB           pol ure?
zstd -T4 -5          63 GB           26 min            9 minut
zstd -T4 -19         59 GB           3h 40min          25 minut

Preprocesiran fajl z lrzip -n -U:

lrzip -n -U          77 GB           29 ur
+zpaq                34 GB           22 minut          52 minut
+zpaq -m6            28 GB           19 ur             30-50 ur

+zstd -T4 -5         32,5 GB         okoli 1h          15 minut
+zstd -T4 -19        30,5 GB         2h 22min


zpaq je zpaq64.exe verzija 7.15
7-zip je verzija 19.00 (64 bit)
zstd je verzija 1.4.0-win64
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

MrStein ::

Še ena prednost zpaq: v arhivu izkorišča podobnost med fajli

Torej, če v isti arhiv dam zgoraj uporabljen fajl, ter potem še enega nekaj tednov starejšega (od istega diska), potem je končna velikost arhiva 50 GB.

Če je vsak fajl v svojem arhivu so velikosti 40 GB in 39 GB, kar je skupaj 79 GB. Napram 50 GB če sta v istem arhivu.


Po drugi strani bi lahko ves ta čas in denar izkoristil za nakup dodatnega diska in ne bi rabil nič kompresirati... ;)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

WizzardOfOZ ::

7zip deluje enako.

Napiši eno vrstico in jo daj v datoteko, pa jo pomnoži (recimo da jo milijonkrat zapišeš v datoteko), potem jo zapakiraj z zipom in pa s 7zipom, ter z zpaq pa poglej rezultate.

MrStein ::

Nope.

Sem dal 120GB disk image v 7 zip, rezultat: 60 GB arhiv

Sem potem dal še enkrat identičen fajl v isti arhiv: rezultat: 120GB

Še slika: (levi properties je arhiv, ki vsebuje samo eno kopijo, desni pa vsebuje dve)



Pomnimo, ista stvar z zpaq je velika 50GB (pa tam sploh nista ista fajla ampak zgolj podobna - disk image istega diska iz različnih časov).
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

WizzardOfOZ ::

Še enkrat.

7ZIP zna enake vrstice v isti datoteki odlično stiskat

file1.txt:
"To je test 1011000100010001"

100.000.000 enakih vrstic
velikost datoteke: 2.70 GB (2,900,000,000 bytes)

zip:
7.30 MB (7,665,652 bytes)
čas kompresiranja: 4min 43s (1 jedro - ne zna uporabljat več jeder)

7zip:
413 KB (423,378 bytes)
čas kompresiranja: 20s (32 jeder)

Zgodovina sprememb…

MrStein ::

Še enkrat:
zpaq drugo kopijo istega ali podobnega fajla zapiše z nekaj bajti.
7zip ga na novo v celoti kompresira

S številkami:
zpaq : 50 GB
7zip : 120 GB

WizzardOfOZ je izjavil:


7ZIP zna enake vrstice v isti datoteki odlično stiskat

Saj to zna vsaki algoritem kompresiranja.

To je tako, kot če bi na predavanju o diferencialnih enačbah prišel ven z 2 + 2 = 4

To v vsi v sobi vedo že 20 let.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

WizzardOfOZ ::

MrStein je izjavil:

Še enkrat:
zpaq drugo kopijo istega ali podobnega fajla zapiše z nekaj bajti.
7zip ga na novo v celoti kompresira

S številkami:
zpaq : 50 GB
7zip : 120 GB

Si probal odpakirat in preverit, če je res prav naredil?

S 7zip pakiram kar nekaj backupov in vem kakšne so prednosti 7zip vs zip.
Ne vem pa kako lahko zpaq 2 različni datoteki (praviš da sta različni) skompresira kot eno.


MrStein je izjavil:


WizzardOfOZ je izjavil:


7ZIP zna enake vrstice v isti datoteki odlično stiskat

Saj to zna vsaki algoritem kompresiranja.

To je tako, kot če bi na predavanju o diferencialnih enačbah prišel ven z 2 + 2 = 4

To v vsi v sobi vedo že 20 let.


Očitno zip tega ne počne dovolj dobro.

MrStein ::

WizzardOfOZ je izjavil:


Si probal odpakirat in preverit, če je res prav naredil?

Itak da sem.

WizzardOfOZ je izjavil:


Ne vem pa kako lahko zpaq 2 različni datoteki (praviš da sta različni) skompresira kot eno.

Saj ne.

Beri bolj pozorno.

zpaq je dve podobni datoteki zapakiral na manj prostora, kot je 7zip eno od teh (v dveh kopijah).

Torej: fajl A, in fajl B (ki je 80% enak kot fajl A) , oba velika 120GB
zpaq: A in B zapakira v arhiv velik 50 GB, ki vsebuje obe datoteki
7zip: A in A zapakira v arhiv velik 120 GB, ki vsebuje A in še eno kopijo A (preimenovano sicer v A1, ker ne moreta biti dva fajla z enakim imenom v arhivu)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

MrStein ::

Še to: dodajanje novega fajla v obstoječi ZPAQ arhiv je veliko hitrejše, če sta arhiv in nov fajl na različnih diskih (verjetno pomaga tudi, če sta na enem, ki pa je hiter SSD)

Konkretno:
V arhiv, ki ima dva 120GB fajla, je dodajanje tretjega fajla iste velikosti trajalo:
- oba na lokalnem disku: 3900 sekund
- fajl lokalno, arhiv na mrežnem disku: 1200 sekund
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

WizzardOfOZ ::

total commander podpira zpaq. Odlično.
https://www.ghisler.ch/board/viewtopic....

MrStein ::

MrStein je izjavil:

Še to: dodajanje novega fajla v obstoječi ZPAQ arhiv je veliko hitrejše, če sta arhiv in nov fajl na različnih diskih (verjetno pomaga tudi, če sta na enem, ki pa je hiter SSD)

Konkretno:
V arhiv, ki ima dva 120GB fajla, je dodajanje tretjega fajla iste velikosti trajalo:
- oba na lokalnem disku: 3900 sekund
- fajl lokalno, arhiv na mrežnem disku: 1200 sekund

Podobno je pri extrakciji:

oba na lokalnem HDD:
9702.906 seconds (all OK)
arhiv na mrežnem disku, ekstrahiranje na lokalni HDD:
5760.985 seconds (all OK)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

WizzardOfOZ ::

branje in pisanje na isti disk, pa imaš verjetno sata diske. Imaš možnost sprobat na SAS?

Zgodovina sprememb…

MrStein ::

Ne.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Lonsarg ::

Kompresija v arhive je preveč dela. Filesystem-level kompresije je the way to go za prišparat plac, ne stisne tako veliko ampak so pa algoritmi hardwersko podprti in ima zadeva neopazen overhead ko se to realtime bere iz diska (lahko komot kompresiraš celotne diske z windows in inštalacijami vred brez posledic). Osebno sem sprobal sicer samo od Windowsa NTFS compression, na linuxu je izbira še večja.

MrStein ::

Se hecaš? NTFS kompresija prinese nekaj procentov in več problemov kot koristi. Na linux pa je verjetno še slabše.
ReFS pa sploh nima tega.

PS: Kje vidiš hardversko podporo za to ???
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

MrStein ::

Glede ZPAQ: to je žal bolj akademski projekt, kot resna rešitev.
- ni podprt že tri leta
- ne zna brati iz device fajlov ( kot /dev/sda )
- kup manjših zadev (recimo je verbose by default, za kompresijo enega fajla izpiše nekih 200 vrstic "informacij", in nima opcije, da bi to izklopil)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

SasoS ::

MrStein je izjavil:

Še enkrat:
zpaq drugo kopijo istega ali podobnega fajla zapiše z nekaj bajti.
7zip ga na novo v celoti kompresira


7zip naredi isto, če delaš solid arhiv.
Imaš pa nekaj opcij, npr. velikost solid bloka, če fajla nista v istem solid bloku, potem se ne more izkoristiti podobnosti med njima. Slabost je, da 1 napaka pokvari cel solid blok (v zipu crc error na eni datoteki ne pokvari ostalih, v solid arhivu so pokvarjene vse, ki so zapisane v istem solid bloku za mestom napake).

Po defaultu dela 7z 4GB solid bloke (tudi na ultra kompresiji). Če hočeš večji blok, moraš ročno dodati v parametre.

MrStein ::

Teoretično, samo ...
- koliko je max velikost solid bloka?
- pri dodajanju mora odpakirati celoten blok, in potem na novo zapakirati. Pri fajlih čez 100GB to potem traja celo večnost. Pir zpaq je enako hitro, kot navadno pakiranje.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

Lonsarg ::

MrStein je izjavil:

Se hecaš? NTFS kompresija prinese nekaj procentov in več problemov kot koristi. Na linux pa je verjetno še slabše.
ReFS pa sploh nima tega.

PS: Kje vidiš hardversko podporo za to ???

Meni je NTFS kompresije prinesla enkrat 10% drugič 15% ko sem v dveh različnih scenarijih probal(enkrat domači PC z 150GB slike + 350GB inštalacijami programov/iger, drugič 250GB inštalacij programov ko sem to na službenemm naredil).

Vsi sodobni procesorji zmeljejo ta preprosti LZ77 algoritem ki ga ta kompresija uporablja tako da tudi pri 500MB/s zadeva sub 5% obremeni CPU. Ko je disk šibka točka(dejansko večina primerov) bo kompresija dejansko pohitrila operacijo in ne upočasnila, skratka predvsem plusi, minus so random read operacije, tako da če imaš placa dovolj se vseeno ne splača vklapljat.

Zgodovina sprememb…

  • spremenil: Lonsarg ()

MrStein ::

10% je "nekaj procentov" (mimogrede, kako si izmeril?)

To da CPU izvaja algoritem je ravno nasprotno od izraza "hardwersko podprti".

Slabosti pa so nedelovanje z nekaterimi programi (ravno takimi, ki delajo z velikimi fajli in bi kompresija prav prišla, recimo Exchange, VMWare in še kaj... je nekje en blog naštel primere).

V glavnem, NTFS kompresija je več problemov kot koristi. Sploh za tistih nekaj %.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Lonsarg ::

50GB(iz 5GB na 55GB fraj placa) pri 500GB SSDju me je rešilo pred nakupom novega SSDja, jaz bi temu rekel zelo koristnih 10%.

Zgodovina sprememb…

  • spremenil: Lonsarg ()

hojnikb ::

sandforce je mel kr spodobn hw compression, žal sicer ne user accessible.
#brezpodpisa

SasoS ::

@Lonsarg
NTFS kompresija ima en velik problem, da ne dela za fajle večje od cirka 40 GB. Disk začne javljat I/O errorje in fajl je neuporaben...
Sem se prvič orenk usral, da je šel disk...potem sem našel bug in od takrat ne gledam več te kompresije za resne podatke (drugo je za loge in podobne textualne (ter bolj ali manj nepomembne) zadeve, tam pride bolj prav).

Nisem pa delal resnih testov z ZFS recimo...

jb_j ::

A se kompresija podatkov še izplača?
300€ za 10tera disk.

MrStein ::

Še en primer, ko ZPAQ ni tako dober. Gre za 3 PST (outlook mail) fajle, lrzip kompresira ločeno, zpaq v en arhiv.

originalna velikost PST datotek skupaj : 12.0 GB

skupna velikost LRZ fajlov : 3,26 GB
ZPAQ : 5.26 GB
ZPAQ -m2 : 4.51 GB
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

katero kompresijo uporabljate za backupe

Oddelek: Programska oprema		142183 (1198) MrStein
»

Stiskanje datotek (strani: 1 2 )

Oddelek: Pomoč in nasveti		5412243 (6453) Oberyn
»

enkripcija folderjev z 7zip - AES-256

Oddelek: Pomoč in nasveti		51102 (1039) Netrunner
»

je že kdo poizkusil xz archiver ?

Oddelek: Programska oprema		5887 (815) Brane2
»

Najboljši program za stiskanje datotek

Oddelek: Programska oprema		113546 (3414) Tilen

Več podobnih tem