我正在尝试使用以下命令将数千个小文件从一台服务器传输到另一台服务器：
rsync -zr --delete /home/user/ [email protected]::backup
目前传输需要很长时间（我还没有计时）。有没有办法让它更快？我应该使用其他工具吗？我应该使用 rsync over ssh 而不是使用 rsync 协议吗？
答案1
您需要确定瓶颈。它不是 rsync。它可能不是您的网络带宽。因为@Zoredache建议这很可能是所有调用产生的大量 iops stat()。任何同步工具都需要统计文件。同步时运行iostat以验证。
那么问题来了：如何优化统计数据？两个简单的答案：
- 获得更快的磁盘子系统（如果需要的话在两台主机上都使用）并且
- 调整你的文件系统（例如，对于 ext3 安装，
noatime并添加dir_index）。
如果碰巧不是您的磁盘 iops 限制，那么您可以尝试将目录树拆分为多个不同的树并运行多个 rsync。
答案2
对于小文件（例如，小于 100 字节），压缩不是很有用。对于小文件，有时压缩版本甚至可能比原始版本还要大。尝试rsync不带-z标志的命令。
ssh有利于安全，但不会使传输速度更快。事实上，由于需要加密/解密，它会使传输速度更慢。
rsync第一次运行可能看起来不太快，因为要传输大量数据。但是，如果您计划定期运行此命令，后续运行可能会快得多，因为它rsync会智能地不传输未更改的文件。
答案3
如果涉及 ext3 或 ext4 文件系统，请检查两者是否都具有dir_index 功能启用！在我的例子中，这使 rsync 吞吐量增加了三倍。
请参阅我的回答中的详细信息：https://serverfault.com/a/759421/80414
答案4
添加-v --progress到你的 rsync 命令行
rsync 分两步完成：
- 深度浏览两个平台上的所有文件以比较它们的大小和mdate
- 进行实际转移
如果你在嵌套目录中 rsync 了数千个小文件，那么 rsync 可能会花费大部分时间进入子目录并查找所有文件
如果没有花费时间进行浏览，则该时间可能仅仅是由于每次新文件传输开始时的所有延迟相加而产生的。