使用GNU Parallel并行压缩未提升性能的问题排查

核心原因 #

1. 标准zip工具单线程限制：默认zip是单线程程序，并行启动多个zip进程仅能在多任务同时运行时利用多核；一旦大部分小任务完成，仅剩的大文件压缩会退化为单线程，导致后期CPU利用率骤降。
2. 任务负载不均衡：find仅遍历一级目录/文件，若存在单个超大目录，其他小任务完成后，CPU只能集中处理这一个单线程任务，无法发挥多核优势。
3. 临时目录潜在竞争：/tmp位于系统磁盘，并行写入多个zip文件可能引发磁盘调度竞争，间接拖慢压缩效率——即使iostat显示整体IO不高，随机写的开销仍会影响性能。

解决方案 #

1. 替换为多线程压缩工具 #

标准zip不支持多线程，改用p7zip（支持多线程的zip压缩）：

• 安装命令（macOS）：brew install p7zip
• 修改脚本中的并行压缩命令：

parallel -j $(parallel --number-of-cores) 7z a -tzip -mmt=on ${tmp_directory}/{/.}.zip {}

-mmt=on会让每个压缩任务自动利用多核，单个大文件压缩也能占满CPU，避免后期单核瓶颈。

2. 优化任务分配，拆分大负载 #

针对超大目录，拆分文件列表后分组并行压缩，避免单个大任务独占CPU：

# 替换原find和parallel部分，递归遍历所有文件并分组压缩
find . -type f | parallel --pipe -N1000 7z a -tzip -mmt=on ${tmp_directory}/chunk-{#}.zip {}

-N1000表示每1000个文件为一组，任务分配更均衡，持续利用多核。

3. 调整并行度，适配CPU架构 #

M2是4大核+4小核的混合架构，全8核并行可能导致调度开销增加，建议限制并行数为大核数量：

parallel -j4 zip -r ${tmp_directory}/{/.}.zip {}

或使用parallel --number-of-cores-1预留1核给系统进程，减少资源竞争。

4. 优化临时目录存储 #

• 使用内存盘：将临时文件放在内存中，彻底消除磁盘IO竞争：

# 创建1GB内存盘（按需调整ram://后的数值，每512字节为一个单位，1GB=2097152）
diskutil erasevolume HFS+ "RAMDisk" `hdiutil attach -nomount ram://2097152`
tmp_directory="/Volumes/RAMDisk/test-1"

• 使用外接高速SSD：若有外接SSD，将临时目录移至外接盘，提升写入速度。

5. 优化zipmerge合并步骤 #

zipmerge是单线程工具，若临时zip文件数量多，可先分组并行合并为中间文件，再合并最终归档：

# 分组合并临时zip
ls ${tmp_directory}/*.zip | parallel --pipe -N4 zipmerge -k ${tmp_directory}/merged-{#}.zip {}
# 合并中间文件为最终归档
zipmerge -k ../test-1.zip ${tmp_directory}/merged-*.zip

内容的提问来源于stack exchange，提问作者testing09