我们在一个大文件夹上运行rsync。它内部有近百万个文件，包括html，jsp，gif / jpg等。我们当然只需要逐步更新文件。这个文件夹中只更新了一些JSP和HTML文件，我们需要这个服务器rsync到另一个服务器，同一个文件夹。
有时rsync运行速度很慢，因此我们的一个IT团队成员创建了这个命令：
find /usr/home/foldername \
-type f -name *.jsp -exec \
grep -l <ssi:include src=[^$]*${ {} ;`
这仅查找具有JSP扩展名且包含某些类型文本的特定文件，因为这些文件是我们rsync所需的文件。但是这个命令占用了大量内存。我认为这是一种愚蠢的rsync方式，但我被告知这是事情的运作方式。
一些谷歌搜索表明这也适用于此文件夹：
rsync -a --update --progress --rsh --partial /usr/home/foldername /destination/server
我担心这会每天都太慢，但我无法想象为什么这会比我们的IT人员推荐的那种愚蠢的查找选项慢。关于现实世界中大型目录rsyncs的任何想法？
答案 0 :(得分：1)
find命令不比rsync扫描更快，grep命令必须慢于rsync，因为它需要从所有.jsp文件中读取所有文本。
find-and-grep可以更快的唯一方法是
文件的时间戳不匹配，因此rsync必须校验内容（双方都有！）
这似乎不太可能，因为您正在使用-a来正确同步时间戳（因为-a暗示-t）。但是，如果不同机器上的文件系统允许不同的时间戳精度（例如Linux与Windows），则会发生这种情况，在这种情况下，--modify-window选项就是您所需要的。
更改的文件比您关注的文件多得多，rsync也正在转移这些文件。
如果是这种情况，那么您可以将传输限制为.jsp这样的文件：
--include '*.jsp' --include '*/' --exclude '*'
（包括所有.jsp个文件和所有目录，但排除其他所有目录。）
rsync预先进行扫描，然后进行比较（可能使用大量RAM），然后进行传输，其中find / grep / copy执行 now
这曾经是一个问题，但只要本地版本和远程版本都是3.0.0或更高版本，rsync就应该进行增量递归扫描，并且您不使用任何花哨的删除或延迟强制进行前期扫描的选项（请参阅文档中的--recursive）。