我在两台服务器之间启动一个 rsync 简单命令。两台服务器在绑定上都有两个 eth 接口。当我使用 rsync 从一台服务器向另一台服务器发送一个大文件时，传输速率达到了 130M/s。
但是，问题是，当我发送包含大量小文件的目录时，传输速度最多为 1M/s。
我已经检查了两个 CPU 负载（8cpu i7），它们的最大负载为 10%。
我知道导致所有传输速度变慢的原因是文件的打开/关闭，而这“理论上”是由 CPU 引起的，我知道这可以很容易地进行调整。但我不知道如何进行调整。
关于如何让 rsync 使用所有 CPU 有什么提示吗？
答案1
您的问题几乎与 CPU 没有任何关系。
传输大文件通常很快，因为它可以通过顺序 I/O 来完成。
传输大量小文件需要存储方面的大量马力，因为它需要随机 I/O。低寻道时间、快速硬盘、大量缓存和为大量文件设计的文件系统是必须的。CPU 在这方面没有帮助，至少没有多大帮助，就像你观察到的那样。CPU 和操作系统只是在等待磁盘 I/O 完成。
更快的 CPU/更多内核可以做到这一切，它们最终可以更快地等待 I/O。:-)
答案2
许多小的随机 IO 操作的延迟加起来为：
- 文件系统和硬盘的访问和寻道时间
- rsync 的比较时间
根据我的经验，rsync 是一款非常好的工具，可以保持同步，但并不是一款非常好的工具，无法尽快提交所有数据。当带宽或存储容量没有其他选择时，请使用它。如果您有能力将所有文件打包并传输到一个 blob 中，那么如果文件足够多，您可以期待更高的性能（完成操作所用的总挂钟时间）。
答案3
使用 rsync 处理大量小文件时会产生大量网络/磁盘开销。如果文件足够小，则加速系数可能小于 1。
注意使用 -v 的加速因子。如果您的加速因子低于 1，即使您知道您已经同步，那么您将遇到相当多的开销。CPU 不是瓶颈。
答案4
Janne 说过：您是受 IO 限制，而不是受 CPU 限制。启动 top（或者更好的是 atop/htop），注意传输小文件时实际使用的 CPU 很少。还请注意，您的进程处于“D”状态，等待数据可用。
此外，我不相信 rsync 针对多核进行了优化；它所做的大部分工作都是连续的，在这方面需要非常巧妙的工作才能使其运行得更快。
但是，如果您使用 ssh 作为传输，它可能会利用最多 2 个核心。它将作为一个单独的进程生成，并将在与主 rsync 进程不同的线程中执行所有加密和可能的压缩工作。该进程有一些 CPU 密集型任务：CRC 计算和 MD5 哈希（我相信这就是它使用的）。