关键在于用pigz替代gzip实现多核压缩：tar --use-compress-program="pigz -p $(nproc)" -cf archive.tar.gz /path/to/dir，可提速4–7倍且保持.gz兼容性。
用 tar 打包数 GB 甚至 TB 级别的巨型目录时，瓶颈不在磁盘 IO（尤其用 NVMe SSD），而在于压缩环节的单线程限制。tar 本身只负责打包（单线程），真正拖慢速度的是默认调用的 gzip —— 它只能用 1 个 CPU 核心。要提速，关键不是换 tar，而是让压缩阶段并行化。最成熟、兼容性最好、开箱即用的方案是 pigz。
✅ 用 pigz 替代 gzip 实现多核压缩
pigz 是 gzip 的并行实现，能自动利用全部或指定数量的 CPU 核心，输出标准 .gz 格式文件，和 gzip 完全兼容，无需修改解压流程。
基本命令（推荐写法）
tar --use-compress-program="pigz -p $(nproc)" -cf archive.tar.gz /path/to/dir
-
--use-compress-program：让tar把压缩任务交给外部程序执行 -
pigz -p N：-p指定线程数，$(nproc)自动取系统逻辑核心总数（如 16 核就用 16 线程） -
-cf：打包不压缩（-c）+ 指定输出文件（-f），压缩由pigz完成
✅ 实测效果：4 核机器压缩 2GB 目录从 3 分钟降至 50 秒内；32 核服务器对 50GB 日志目录，压缩时间可缩短 4–7 倍。
⚙️ 进阶调优：更稳、更快、更可控
控制线程数与 CPU 绑定（避免干扰关键服务）
# 限定使用 8 个核心（编号 0–7），避免抢占其他业务资源 taskset -c 0-7 tar --use-compress-program="pigz -p 8" -cf backup.tar.gz /data/
-
taskset -c可绑定进程到特定 CPU 核心，减少上下文切换和缓存抖动 - 生产环境建议预留 2–4 核给系统和其他服务，不要无脑用满
nproc
处理海量小文件（防参数超长 + 提速）
find /data -type f -print0 | tar --null -cf - | pigz -p 12 > backup.tar.gz
-
find ... -print0 | tar --null避免Argument list too long错误（尤其百万级小文件） -
tar -cf -输出到 stdout，直接管道给pigz，全程内存流式处理，不生成中间.tar文件
压缩级别权衡（速度 vs 体积）
- 默认
-p已启用pigz最优策略，通常无需改级别 - 若需进一步提速（牺牲少量压缩率）：加
-1（最快） - 若磁盘紧张且 CPU 富余：可用
-6（平衡）或-9（高压缩，但速度下降明显，一般不推荐）
? 注意事项：哪些“加速法”其实无效或危险
-
tar -z本身无法多线程 —— 它只是调用单线程gzip，换再多核也白搭 - 不要用
split切割.tar.gz文件：gzip 流不支持随机分片，解压必报invalid compressed data -
xz或bzip2虽然也有并行版（pxz、pbzip2），但兼容性差、解压端不一定装了，pigz是最稳妥的替代 - 不要手动
tar cf - ... | gzip—— 这仍是单线程；必须换成pigz才生效
▶️ 解压也一样快：用 pigz 加速解压
tar --use-compress-program="pigz -p 8" -xf backup.tar.gz
或旧版 tar（不支持 --use-compress-program）：
pigz -p 8 -d backup.tar.gz | tar -xf -
解压速度提升同样显著，尤其对大文件（如单个 20GB 的 .tar.gz），CPU 利用率可拉满，不再卡在单核瓶颈上。
不复杂但容易忽略——关键是把 gzip 换成 pigz，一行命令就能释放多核潜力。
