accelerare la compressione gzip

È possibile accelerare il gzipprocesso?

sto usando

mysqldump "$database_name" | gzip > $BACKUP_DIR/$database_name.sql.gz

per eseguire il backup di un database in una directory $BACKUP_DIR,.

la manpage dice:

- # --fast --best
Regola la velocità di compressione utilizzando la cifra specificata #, dove -1 o --fast indica il metodo di compressione più veloce (meno compressione) e -9 o --best indica il metodo di compressione più lento ( miglior compressione). Il livello di compressione predefinito è -6 (ovvero, distorto verso un'elevata compressione a scapito della velocità).

Quanto sarebbe efficace da usare --fast?
Questo sta effettivamente riducendo l'utilizzo della CPU su un computer moderno?

I miei risultati del test

Non ho notato alcuna accelerazione:

7 min, 47 secondi (con rapporto predefinito -6)
8 min, 36 secondi (con rapporto --fast(= 9))

Quindi sembra ci vuole ancora più tempo per usare la compressione veloce?

Solo una compressione più alta la rallenta davvero:

11 min, 57 secondi (con rapporto --best(= 1))

Dopo aver ottenuto l'idea con lzopho provato anche quello ed è davvero più veloce:

6 min, 14 secondi con lzop -1 -f -o $BACKUP_DIR/$database_name.sql.lzo

backup compression gzip

— rubo77
fonte

Correlati: unix.stackexchange.com/questions/87111/…

— slm

Sei preoccupato per il tempo della CPU o del tempo complessivo (di clock)? --best è 9, --fast è 1.

— Stéphane Chazelas,

Se gzip -1non è abbastanza veloce, usalzop

— Stéphane Chazelas il

C'è anche lz4che è ancora più veloce vedere questo benchmark . Ma sembra che lzop e lz4 abbiano bisogno di molta più memoria. sarà un problema sul mio single-core RAM da 1 GB che lz4 utilizza 30 volte più memoria in compressione rispetto a gzip quando comprimo alcuni database di grandi dimensioni?

— rubo77,

lz4 non ha bisogno di tanta memoria. Se si utilizza l'utilità lz4c, quasi tutta la memoria viene allocata per il buffer I / O. Puoi ridurlo utilizzando buffer più piccoli (opzione -B4 per buffer da 64 KB). Poiché i buffer più piccoli significano anche una compressione peggiore, è utile abilitare la compressione a blocchi concatenati (opzione -BD). Vedi: fastcompression.blogspot.fr/2013/08/…

— Ciano,

Risposte:

Se hai una macchina multi-core che usa pigz è molto più veloce del tradizionale gzip.

pigz, che sta per implementazione parallela di gzip, è un sostituto completamente funzionale di gzip che sfrutta più processori e più core fino in fondo quando comprime i dati. pigz è stato scritto da Mark Adler e utilizza le librerie zlib e pthread.

Pigz può essere usato come sostituto drop-in per gzip. Nota che solo la compressione può essere parallelizzata, non la decompressione.

Usando pigz la riga di comando diventa

mysqldump "$database_name" | pigz > $BACKUP_DIR/$database_name.sql.gz

— Marco
fonte

questo accelera anche il processo su un core?

— rubo77,

@ rubo77 - no, questo fa uscire la compressione su più core.

— slm

pigzaumenta l'utilizzo della CPU ma riduce il tempo di clock impiegato dai multi-processori

— Stéphane Chazelas,

Anzi, e questo è spesso ciò che si desidera. E di solito (a seconda dell'hardware) la compressione gzip è legata alla CPU (prestazioni a thread singolo) e la compressione pigz è spesso associata a IO.

— Marco,

Da man gzip:

   -# --fast --best
          Regulate  the  speed  of compression using the
          specified digit #, where -1  or  --fast  indi‐
          cates  the  fastest  compression  method (less
          compression) and -9 or  --best  indicates  the
          slowest compression method (best compression).
          The default compression level is -6 (that  is,
          biased  towards high compression at expense of
          speed).

— terdon
fonte

Se è necessario che sia veloce a causa di problemi di blocco del database e si dispone di un disco abbastanza veloce / grande da contenere temporaneamente i dati non compressi, è possibile prendere in considerazione l'utilizzo di questo metodo:

mysqldump "$database_name" > "$BACKUP_DIR"/"$database_name".sql
nice gzip "$BACKUP_DIR"/"$database_name".sql &

Vale a dire prima memorizzare il backup (che è più veloce del gzip se il disco è veloce e la CPU è lenta) e quindi si verifica il gzip in background.

Ciò potrebbe anche consentire di utilizzare un algoritmo di compressione migliore, poiché non importa più (direttamente) quanto tempo impiega la compressione.

— frostschutz
fonte