Rsync 跨 WAN 很慢？先找瓶颈的调校指南
拆解扫描、变更判断、SSH、压缩、磁盘与小文件瓶颈，创建可重现的 rsync WAN 测试。
Rsync 跨站拷贝很慢，可能在数据开始发送前就已花掉大部分时间。大量目录扫描与文件比对，和网络发送不足，需要不同的调整方式。
先记录多久才开始发送内容，再比较一个大文件与一份真实文件夹的完整耗时。搭配两端 CPU、磁盘与网络纪录，便能逐步确认时间花在扫描、差异计算、SSH 传输还是目的端写入。
先创建基准
先预览 rsync 认为会变更的项目：
rsync -a --dry-run --itemize-changes source/ user@example.com:/data/destination/再跑正式测试：
rsync -a --info=progress2 --stats source/ user@example.com:/data/destination/记录「多久才开始送有效数据」、检查与实际发送的文件数、实际发送／比对相符数据、两端 CPU、来源读取、目的写入，以及端到端总耗时。Rsync 默认以大小与修改时间做快速检查，现代版本还会增量递归；但百万文件仍需大量文件系统工作。官方行为以 rsync man page为准。
1. 不要把 --checksum 当成通用加速或安全开关
--checksum 会在判断变更时读取两端文件内容，可能在传输前就造成大量磁盘 I/O。它与接收端对已传输内容的重建验证不同。只有文件内容可能改变、但大小与修改时间仍相同时才使用，并先独立测量扫描时间。
2. 用一个工作阶段与范围明确的清单
不要用 Shell 循环每个文件启动一次 rsync，否则会重复 SSH、进程、清单交换与 WAN 延迟。若上游已知精确变更路径，可测试排序后的 --files-from：
rsync -a -r --files-from=changed-files.txt source/ user@example.com:/data/destination/使用 --files-from 时，-a 不会自动包含 recursion，所以需要时加 -r。先用 --dry-run 验证；若清单不完整，就不能拿它做完整变更发现。
--delete-before、--delete-after、--prune-empty-dirs、--delay-updates 等选项可能要求完整文件清单并停用增量递归。若语意必要就保留，但要把额外预扫描算进时间。
3. 只对可压缩数据测 -z
rsync -a --stats source/ user@example.com:/data/destination/
rsync -az --stats source/ user@example.com:/data/destination/文本可能受益，JPEG、MP4、ZIP 通常不会。两端版本也会影响 zstd、lz4、zlib 等协商。只在 CPU 没饱和且完整时间改善时保留压缩。
4. 为中断保留未完成的数据
rsync -a --partial --partial-dir=.rsync-partial source/ user@example.com:/data/destination/把未完成的目录放在只有可信用户可写的位置，并测试空间与清理。这对中断的大文件很有用，但无法消除数万小文件的元数据成本；也要确认它与 --whole-file、--inplace、延后更新的交互。
5. 把 --whole-file 当成实验
--whole-file 会停用差分算法，直接传完整的已选文件。若目的端既有文件读取很慢、文件几乎全部变更、WAN 尚有余裕，可能更快；若计量带宽有限，或大型文件只改少量区块，反而浪费。用 --stats 比较实际发送字节与完整时间。
6. 分开测大文件与小文件
| 结果 | 可能瓶颈 | 下一步 |
|---|---|---|
| 大文件与文件夹都慢 | WAN、SSH CPU、磁盘、流量整形 | 比较 iperf3、CPU 与本地磁盘 |
| 大文件快、文件夹慢 | 枚举与逐档元数据 | 量开始发送内容前的等待时间与文件/s |
| 本地文件夹也慢 | 来源／目的文件系统 | 查元数据 IOPS 与背景索引 |
| 压缩只改善文本 | 带宽与数据型态 | 依工作负载建设置组合 |
| 第二次明显变快 | 缓存或目的端既有数据 | 分别报告冷缓存／暖缓存测试 |
50,000 个文件若串行化地多一次 80ms 等待，延迟预算就是 4,000 秒。Rsync 会处理流程，所以这不是预测值，但说明文件数与 RTT 必须一起看。延伸阅读：大量小文件为何很慢。
何时保留 rsync，何时比较其他流程
需要 POSIX 元数据、文件选择规则、差异更新、自动化与标准 SSH 时，rsync 仍是好工具。若需求是大型首批拷贝、小文件占多数、外部浏览器交付、集中管理或不想维护两端 SSH／rsync，才比较其他方式。
WarpSend 不是 rsync 选项、拥有者、硬链接或删除语意的可直接替换的工具；它是支持端点间的另一种文件交付流程。用相同来源、目的、路由与数据集比较，才有意义。
本文选项已依 2026-08-06 的官方 rsync 3.4.4 文档核对。正式变更前，仍需测试删除、权限、链接、稀疏文件、延伸属性、中断与还原。
常见问题
为什么 rsync 通过 WAN 很慢？
瓶颈可能在目录扫描、逐档元数据、RTT、SSH CPU、目的端写入、丢包，或不必要的 --checksum 预扫描。先分别测量开始发送前等待、文件数、RTT、丢包、CPU、磁盘与完整总耗时。
rsync 适合传大量小文件吗？
rsync 会处理流程并使用增量递归，但每个文件仍需枚举、比对、创建与元数据操作。大量小文件可能受文件系统或延迟限制，即使 WAN 带宽还有空间。
通过网络 rsync 应该加压缩吗？
用真实文件测试。文本、纪录、CSV 可能减少传输量；JPEG、MP4、ZIP 通常收益很小，反而增加 CPU。保留能改善完整时间的设置，不看单一压缩率。
加 --checksum 会更安全吗？
它改变的是传输前的变更判断，会让两端读取文件内容，可能增加大量 I/O。rsync 对已传输文件另有重建验证。只有大小与修改时间不可信时，才应测试并使用 --checksum。