Puedes cambiar la velocidad de gzip usando --fast --best o -# donde # es un número entre 1 y 9 (1 es el más rápido pero con menos compresión, 9 es el más lento pero con más compresión). Por defecto gzipruns en el nivel 6.
La razón por la que tar toma tan poco tiempo en comparación con gzip es que hay muy poca sobrecarga computacional al copiar sus archivos en un solo archivo (que es lo que hace). gzip, por otro lado, en realidad está usando algoritmos de compresión para reducir el tamaño del archivo tar.
El problema es que gzip está restringido (como descubrió) a un solo hilo.
Ingrese pigz, que puede usar varios subprocesos para realizar la compresión. Un ejemplo de cómo usar esto sería:
tar -c --use-compress-program=pigz -f tar.file dir_to_zip
Hay un buen resumen sucinto de la opción --use-compress-program en un sitio hermano.
Parece que estoy usando una sola CPU aproximadamente al 100 %.
Eso implica que no hay un problema de rendimiento de E/S, sino que la compresión solo usa un subproceso (que será el caso con gzip).
Si logra obtener el acceso/acuerdo necesario para instalar otras herramientas, entonces 7zip también admite varios subprocesos para aprovechar las CPU de varios núcleos, aunque no estoy seguro de si eso se extiende al formato gzip así como al suyo propio.
Si está limitado a usar solo gzip por el momento y tiene varios archivos para comprimir, puede intentar comprimirlos individualmente; de esa manera, usará más de esa CPU multinúcleo al ejecutar más de un proceso en paralelo. Sin embargo, tenga cuidado de no exagerar porque tan pronto como se acerque a la capacidad de su subsistema de E/S, el rendimiento caerá precipitadamente (más bajo que si estuviera usando un proceso/subproceso) a medida que la latencia de los movimientos de la cabeza se vuelve significativa. cuello de botella.