La utilidad GZIP más rápida

18

Estoy buscando la gziputilidad más rápida (o zip). Tengo un volumen LVM que existe en un 95% en blanco 0, por lo que comprimirlo es muy fácil. Estoy buscando la solución más rápida y realmente no me importa la compresión, excepto la 0's.

Soy consciente de gzip -1(igual que gzip --fast) pero me preguntaba si hay algún método más rápido.

Gracias.

Editar: después de algunas pruebas, comparé gzip -1, lzop -1y pigz -1entre sí , y obtuve los siguientes resultados:

PIGZ:

time dd if=/dev/VPS/snap | pigz -1 | ssh backup-server "dd of=/home/backupvps/snap.pigz"

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 2086.87 seconds, 25.7 MB/s
7093985+266013 records in
7163950+1 records out
3667942715 bytes (3.7 GB) copied, 2085.75 seconds, 1.8 MB/s

real    34m47.147s

LZOP:

time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop" 

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1829.31 seconds, 29.3 MB/s
7914243+311979 records in
7937728+1 records out
4064117245 bytes (4.1 GB) copied, 1828.08 seconds, 2.2 MB/s

real    30m29.430s

GZIP:

time dd if=/dev/VPS/snap | gzip -1 | ssh backup-server "dd of=/home/backupvps/snap_gzip.img.gz

104857600+0 records in
104857600+0 records out
53687091200 bytes (54 GB) copied, 1843.61 seconds, 29.1 MB/s
7176193+42 records in
7176214+1 records out
3674221747 bytes (3.7 GB) copied, 1842.09 seconds, 2.0 MB/s

real    30m43.846s

Edición 2 :

Esto no está relacionado con mi pregunta inicial, sin embargo, al usar time dd if=/dev/VPS/snap | lzop -1 | ssh backup-server "dd of=/home/backupvps/snap.lzop"(tamaño de bloque cambiado a 16M), ¡el tiempo se reduce a real 18m22.442s!

linux compression gzip Devator
fuente
1
Tenga cuidado: es algo injusto usar timede esa manera. El rendimiento del dd utilizado para pigzes menor que los otros dos.
Henk
@Devator: al observar los tiempos, uno podría concluir que ahora empujar bytes a través del túnel ssh encriptado es el cuello de botella. ¿trataste de usar ssh con el indicador "-c" (compresión) y dejaste al precompresor fuera de la ecuación? También puede cambiar a un algoritmo de cifrado más rápido. aparte de eso: volver a comparar sin el túnel ssh (por ejemplo, usando / dev / null como el sumidero de salida)
akira
Como nota al margen, ¿podría usar un archivo disperso ? Entonces los ceros no ocuparían espacio en el disco. Su compresión también sería más rápida porque los ceros serían interpolados por el controlador del sistema de archivos (y no tendrían que leerse desde el disco)
Li-aung Yip
@ Li-aungYip No lo creo, ya que los "archivos" son volúmenes LVM.
Devator
Ah, ya veo. ¡Continua!
Li-aung Yip

Respuestas:

14

Si no le importa alejarse de DEFLATE, lzopes una implementación de LZO que favorece la velocidad sobre la relación de compresión.

Ignacio Vazquez-Abrams
fuente
1
o .. snappy: code.google.com/p/snappy
akira
Gracias, he descubierto que soy lzopel más rápido en mi situación. Es más rápido que de pigzalguna manera (probablemente debido a los lotes de 0).
Devator
23

Aunque personalmente aún no lo he usado, creo que usar gzip paralelo podría acelerar un poco las cosas:

pigz, que significa implementación paralela de gzip, es un reemplazo completamente funcional para gzip que explota múltiples procesadores y múltiples núcleos hasta el fondo al comprimir datos.

Pascal
fuente
1
Lo uso de forma rutinaria, y recomiendo absolutamente pigz si hay varios núcleos disponibles. Además de cambiar el nivel de compresión, este es, con mucho, el medio más accesible y directo para acelerar la compresión.
jgrundstad
3
El sitio se ve un poco extraño. Pero no se deje engañar por eso, pigz está escrito por uno de los desarrolladores de gzip y zlib, Mark Adler.
so_mv
Parece que el proyecto está abandonado en este momento.
AlexLordThorsen
Prefiero pensar en ello como "estable". No se actualiza a menudo, pero se actualiza.
Alan De Smet
7

Puede probar Parallel Gzip (Pascal lo vinculó) o Parallel BZIP.
En teoría, BZIP es mucho mejor para el texto, por lo que es posible que desee probar pbzip .

apache
fuente
2

Su disco está limitado a 30 MB / s

Todos los compresores funcionan lo suficientemente bien. Incluso puede reducir la transferencia de red utilizando bzip2 un poco más lento pero omnipresente.

$dd if=/dev/zero bs=2M count=512 | pigz -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 9.12679 s, 118 MB/s
8192+7909 records in
9488+1 records out
4857870 bytes (4.9 MB) copied, 9.13024 s, 532 kB/s
$dd if=/dev/zero bs=2M count=512 | bzip2 -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 37.4471 s, 28.7 MB/s
12+1 records in
12+1 records out
6533 bytes (6.5 kB) copied, 37.4981 s, 0.2 kB/s
$dd if=/dev/zero bs=2M count=512 | gzip -1 | dd > /dev/null
512+0 records in
512+0 records out
1073741824 bytes (1.1 GB) copied, 14.305 s, 75.1 MB/s
9147+1 records in
9147+1 records out
4683762 bytes (4.7 MB) copied, 14.3048 s, 327 kB/s

¿Has considerado rsync? Hace la suma de comprobación y luego comprime la diferencia solamente.

ZaB
fuente
1
Mi disco no está limitado a 30 MB / s. Acabo de hacer tu prueba: pigz -1: 1073741824 bytes (1.1 GB) copied, 8.6779 seconds, 124 MB/sy gzip -1: 1073741824 bytes (1.1 GB) copied, 11.6724 seconds, 92.0 MB/s. He pensado en rsync, pero eso comprobaría el archivo diferenciado y probablemente no ayudaría, ya que la mayoría de las veces ha cambiado mucho.
Devator
Si estás en la transferencia de ceros, mira lo impresionante que se ve la codificación bzip2 en comparación. Justo a qué lado mides la velocidad ... 4Mbit / s de pigz podría ser demasiado para una línea DSL común ... Se agrava aún más si tu disco es tan rápido.
ZaB
2

Re: lzop es más lento en su configuración estándar ... Ajustar puede la mitad del tiempo. Pero hay un reemplazo aún más rápido llamado blosc:

https://github.com/FrancescAlted/blosc

Hmm ... El tiempo que tardó en publicar esto y obtener respuestas probablemente sea al menos el doble del ahorro de tiempo que obtendrás ... Ahora discúlpame mientras recompilo mi kernel para eliminar otros .1s de mi tiempo de arranque de 2s.

technosaurus
fuente