最近在给服务器迁移深度学习数据集(以 AI-TOD 遥感目标检测数据集为例),遇到了一个非常典型的性能卡顿问题。原本想着先用 zip -r dataset.zip AI-TOD/ 打包再传输,结果一看终端日志,进度条几秒钟才动一下,刷屏的全是 deflated 2%、deflated 4%……
几万张小图片压了半天,体积几乎没变,CPU 占用率却直接拉满。在万兆或千兆内网环境下,这种传输方式效率极其低下。今天就结合这次踩坑经验,详细梳理一下在 Linux 服务器之间高速传输海量图片数据集的最佳实践与原理分析。
一、 为什么你的 zip 压缩又慢又无用?
在寻找加速方案之前,我们需要先搞清楚为什么传统的“先 zip 压缩,再传输”在数据集场景下会失效:
- 图片本身已被无损/有损压缩: 常见的数据集格式(
PNG、JPG、WEBP)以及模型权重文件(.pth、.pt)本身就是高度压缩过的格式。再对其使用zip的Deflate算法,压缩率通常只有1% ~ 5%,做的是纯粹的无用功。 CPU成为最大算力瓶颈:zip默认是单线程串行压缩。几万张图片逐个计算Deflate散列,导致单核CPU被死死啃满,而内网百兆/万兆带宽却一直在空闲等CPU。- 海量小文件的磁盘
I/O暴击: 数据集通常包含成百上千个目录和数十万张几KB的小图片。如果直接传输小文件,频繁的磁盘寻道、文件元数据读写以及SSH连接握手开销,会导致传输速率骤降至几百KB/s。
核心结论: 内网传输已压缩的数据集,瓶颈永远在 CPU 压缩计算 和 小文件 I/O,而非网络带宽。记住八字原则:能流式不落地,能打包不压缩!
二、 方案一:TAR + PV + SSH 管道直传(首选推荐)
如果你是在内网两台 Linux 服务器之间传输数据集,强烈推荐使用 TAR 管道流式直传。它的最大优势是:不占用本地磁盘空间、CPU 零开销、数据流直接跑满网卡带宽。
1. 完整运行命令
|
1 |
tar cf - AI-TOD | pv -s $(du -sb AI-TOD | awk '{print $1}') | ssh root@10.170.0.236 "mkdir -p /data/datasets && tar xf - -C /data/datasets" |
2. 命令深度拆解
| 命令片段 | 作用与原理 |
|---|---|
tar cf - AI-TOD |
c 创建归档,f - 将打包数据直接输出到标准输出流(标准管道),只做文件合并不做任何压缩,CPU 负载接近 0。 |
pv -s $(du -sb ...) |
pv (Pipe Viewer) 实时监控管道数据流。du -sb 预先计算文件夹总字节数,传给 pv -s 用来绘制精准的进度条、传输速度及剩余时间 (ETA)。 |
| ssh root@IP "..." |
通过 SSH 通道把本地的标准输出流推送给远程服务器,并在远端执行后面的命令。 |
tar xf - -C /path |
远端服务器从标准输入流(管道)读取数据,一边接收一边解压落地到指定目录,目录结构与权限 1:1 还原。 |
3. 实际终端效果
|
1 |
2.4GB 00:01:22 [29.5MB/s] [===============> ] 71% ETA 00:00:33 |
三、 方案二:增量同步与断点续传(RSYNC 正确用法)
如果传输中断了,或者后续数据集有小范围更新、补传,使用 rsync 是最稳妥的方式。但很多人在内网使用 rsync 时犯了一个致命错误:习惯性加上了 -z (压缩) 参数。
1. 内网极速同步命令
|
1 2 |
# 注意:内网环境务必去掉 -z 参数 rsync -avh --progress AI-TOD root@10.170.0.236:/data/datasets/ |
2. 为什么一定要去掉 -z?
-z 参数会强制 rsync 在传输前对数据进行 CPU 压缩、传输后再解压。对于文本文件很有效,但对于已经压缩过的 PNG/JPG 图片,加上 -z 会导致速度瞬间下降 5~10 倍!
四、 方案三:本地备份打包(纯归档模式)
如果你因为某些原因(比如上传网盘、留存本地备份)必须在本地磁盘生成一个归档大包,请一定要开启 Store 模式(只打包,不压缩):
1. ZIP 极速纯打包
|
1 |
zip -0 -r AI-TOD_archive.zip AI-TOD |
-0 代表零压缩(Store 模式),此时 zip 仅将文件拼接到一个文件中,打包速度完全取决于磁盘写入读取速度,秒级完成。
2. 7z 多线程纯打包
|
1 |
7z a -mx0 -mmt=8 AI-TOD.7z AI-TOD |
-mx0 代表不压缩,-mmt=8 开启 8 线程并行,非常适合拥有多核心 CPU 的 GPU 服务器。
五、 各种场景下的最佳实践汇总
在实际运维和日常开发中,针对不同的传输场景,可以参考下表选择最优工具链:
| 传输场景 | 推荐策略与工具 | 核心优势 |
|---|---|---|
| 内网两机首次传输 | tar cf - | pv | ssh "tar xf -" |
零磁盘落地,CPU 零开销,跑满带宽,动态进度条。 |
| 增量更新 / 断点续传 | rsync -avh --progress(去掉 -z) |
自动比对差量,续传方便,避免无用开销。 |
| 本地生成归档备份 | zip -0 或 7z -mx0 |
纯文件拼接,速度极快,不白白浪费 CPU。 |
| 跨公网低带宽传输 | tar -I'zstd -1 -T8' ... |
仅在带宽极低时考虑,用 zstd 最低等级 + 多线程压缩。 |

![[mcj]Ubuntu16.04安装NVIDIA驱动+CUDA10.1+cudnn7.5.0附详细步骤-马春杰杰](https://ypyssl.machunjie.com/machunjie/20210408222433.png_machunjie.png)




最新评论
牛牛牛
同样
站长您好,亚马逊云咨询推广资源,望建立联系,可邮件,谢谢。
换友情链接吗?
看你的站做的挺不错的
恭喜!!太强了,硕博连读啊
雁过留毛,人过留名。
看不懂但大受震撼