¿Es posible acelerar el gzip
proceso?
Estoy usando
mysqldump "$database_name" | gzip > $BACKUP_DIR/$database_name.sql.gz
para hacer una copia de seguridad de una base de datos en un directorio $BACKUP_DIR
,.
la página del manual dice:
- # --fast --best
Regula la velocidad de compresión usando el dígito especificado #, donde -1 o --fast indica el método de compresión más rápido (menos compresión) y -9 o --best indica el método de compresión más lento ( mejor compresión). El nivel de compresión predeterminado es -6 (es decir, sesgado hacia una compresión alta a expensas de la velocidad).
- ¿Qué tan efectivo sería usar
--fast
? - ¿Está esto efectivamente reduciendo el uso de la CPU en una computadora moderna?
Los resultados de mi prueba
No noté ninguna aceleración:
- 7 min, 47 segundos (con relación predeterminada
-6
) - 8 min, 36 segundos (con relación
--fast
(= 9))
Entonces, ¿parece que lleva más tiempo usar la compresión rápida?
Solo una compresión más alta realmente lo ralentiza:
- 11 min, 57 segundos (con relación
--best
(= 1))
Después de obtener la Idea, también lzop
lo probé y realmente es más rápido:
- 6 min, 14 segundos con
lzop -1 -f -o $BACKUP_DIR/$database_name.sql.lzo
backup
compression
gzip
rubo77
fuente
fuente
gzip -1
no es lo suficientemente rápido, uselzop
lz4
que es aún más rápido ver este punto de referencia . Pero parece que lzop y lz4 necesitan mucha más memoria. ¿Será un problema en mi 1GB RAM de un solo núcleo que lz4 usa 30 veces más memoria en compresión que gzip cuando comprimo algunas bases de datos grandes?Respuestas:
Si tiene una máquina multinúcleo que usa pigz es mucho más rápido que el gzip tradicional.
Pigz se puede usar como un reemplazo directo para gzip. Tenga en cuenta que solo la compresión puede ser paralelizada, no la descompresión.
Usando pigz la línea de comando se convierte
fuente
pigz
aumenta el uso de la CPU, pero reduce el tiempo de reloj que tarda en multiprocesadoresDe
man gzip
:fuente
Si necesita que sea rápido debido a problemas de bloqueo de la base de datos, y tiene un disco lo suficientemente rápido / grande como para contener los datos sin comprimir temporalmente, puede considerar usar este método en su lugar:
Es decir, almacene primero la copia de seguridad (que es más rápida que comprimirla SI el disco es rápido y la CPU es lenta) y luego haga que la compresión ocurra en segundo plano.
Esto también podría permitirle usar un mejor algoritmo de compresión, ya que ya no importa (directamente) cuánto tiempo lleva la compresión.
fuente