为什么scp这么慢，如何使它更快？

59

我正在尝试复制一批文件，scp但是速度很慢。这是一个包含10个文件的示例：

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

奇怪的是，传输速率约为413KB / s，文件大小约为413KB，因此它确实应该每秒传输一个文件，但是每个文件大约需要4.3秒。

是否知道这种开销来自何处，并且有什么方法可以使其更快？

scp time batch-jobs

— 劳伦特
source

3

您期望什么速度（即，是否有另一种协议可以显示相同两台计算机之间更高的传输速度）？scp更大的文件（也许是所有413KB文件的串联）会发生什么？

— dhag 2015年

6

看起来远程系统可能正在尝试将客户端IP地址解析为名称，并且您必须等待超时才能继续会话。您可以研究解决此问题的方法（例如，将IP地址添加到目标的/ etc / hosts文件中）。

— wurtel

4

值得一提的是，-C标志可在传输期间启用压缩。尽管您的问题似乎是开始传输的开销，但压缩基本上是“免费的”，几乎总是有帮助的。

— 山姆

@wurtel：我看不到您所看到的，我所看到的只是时间。无论如何，应该只需要一个反向DNS调用。

— James K Polk 2015年

您是依靠SCP来确保安全性还是仅用于远程复制？

— Freiheit 2015年

17

@wurtel的评论可能是正确的：建立每个连接都有很多开销。如果可以解决，可以更快地进行转移（如果不能解决，请使用@roaima的rsync解决方法）。我做了一个实验，将大小相似的文件（head -c 417K /dev/urandom > foo.1并制作了该文件的一些副本）传输到需要一段时间才能连接的主机（HOST4）和响应速度很快的主机（HOST1）：

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$

— 德鲁本
source

1

谢谢，这很有趣。即使同一主机之间的时间完全不同，即使显示同一时间，scp输出也可能会中断。它们可能应该在总时间中包括连接时间。

— 劳伦特

1

因此，您的假设是每个文件都会建立一次新连接？

— rogerdpack

59

您可以使用rsync（over ssh），它使用单个连接来传输所有源文件。

rsync -avP cap_* user@host:dir

如果你没有rsync（为什么不！？），你可以使用tar带有ssh这样的，它避免了创建一个临时文件：

tar czf - cap_* | ssh user@host tar xvzfC - dir

在rsync所有其他条件相同的情况下，最好使用，因为它在发生中断时可以重新启动。

— 罗伊马
source

6

您是说一次scp调用不会使用单个连接来传输所有文件吗？

— 2015年

1

在tarpipe情况下，由于在默认情况下f -tar输出到stdout / stdin或从stdout / stdin读取，因此不需要在每一侧都使用。这样tar cz cap_* | ssh user@host tar xvzC dir就可以了。

— tremby

1

@tremby不一定。tar可以使用不同的默认值进行编译（请查看tar --show-defaults您是否在使用GNU tar，/etc/default/tar否则，请不要忘记TAPE环境变量）

— roaima 2015年

1

@MichaelKjörling最初我以为scp可以为每个文件创建一个新的连接，但是在回忆时-仔细检查后tshark-我意识到我不正确。在这一点上，我不再确定为什么OP scp会占用每个文件那么长的时间。

— roaima

@roaima，有趣，谢谢。到目前为止，我从未注意到stdin / stdout没有被默认。我的Mac上工作的BSD tar在其手册页中没有提到TAPE env var，尽管Linux机器上的GNU tar确实如此。

— tremby

15

协商转让需要时间。通常，对n个b字节文件的操作要花费很多，比对n * b字节单个文件的操作要长得多。这也适用于磁盘I / O。

如果仔细看，您会发现在这种情况下的传输速率为size_of_the_file / secs。

要更有效地传输文件，请将它们与捆绑在一起tar，然后传输tarball：

tar cvf myarchive.tar cap_20151023T*.png

或者，如果您还想压缩档案，

tar cvzf myarchive.tar.gz myfile*

是否压缩取决于文件内容，例如。如果它们是JPEG或PNG，则压缩不会有任何效果。

— 博士01
source

PNG使用deflate，gzip压缩它们也没有意义。

— Arthur2e5

我要说的是，当无法进一步压缩文件时，压缩tar不会产生负面影响，因此建议您放好-z

— Centimane 2015年

1

@Dave如果无法压缩它们，或者网络速度很快，它将使速度变慢。

— Davidmh

@Davidmh虽然会很大吗？我认为压缩已经压缩的文件会相当快，因为它实际上只是查看它可以压缩的内容而发现没有任何内容。取决于我猜是否tar正常进行第二遍压缩或是否同时进行压缩和存档

— Centimane 2015年

3

在我的情况下，@ Dave（现代7000 rpm HD上的数据，高端CPU，非常快的网络，一点也不吹牛），没有压缩的tar纯粹是IO绑定的，但是有-zCPU绑定的，并且慢得多。gzip总是会尝试压缩，因此速度变慢；毕竟，在尝试压缩字节串之前，您无法确定它是否可压缩。在我的设置中，即使传输纯文本文件，与最轻的压缩相比，不压缩的rsync最快也要快2-3倍。当然是YMMV。

— Davidmh，2015年

6

scp慢于其应有的速度（特别是在高带宽网络上）的另一个原因是，它具有静态定义的内部流控制缓冲区，最终成为网络性能的瓶颈。

HPN-SSH是OpenSSH的修补版本，可增加这些缓冲区的大小。这对scp传输速度有很大的影响（请参阅网站上的图表，但我也从个人经验中得出了结论）。当然，要获得好处，您需要在所有主机上安装HPN-SSH，但是如果您经常需要传输大文件，则值得这样做。

— Menno Smits
source

5

我使用了此处描述的技术，该技术使用并行gzip和netcat快速压缩和复制数据。

归结为：

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

这使用tar收集一个或多个文件。然后使用Pigz获取许多cpu线程来压缩并发送文件，网络传输使用的是netcat。在接收方，netcat侦听然后解压缩（并行）并解压缩。

— 弗赖海特
source

3

nc未加密。加上ssh -D魔法吧？

— Arthur2e5

这实际上非常出色

— Jabran Saeed

5

刚遇到此问题，通过进行了大mp4文件的站点到站点传输scp。正在获得〜250KB / s。在目标防火墙上禁用UDP泛洪保护（FP）后，传输速率提高到6.5MB / s。重新打开FP时，速率下降到〜250KB / s。

发件人：cygwin，收件人：Fedora 20，防火墙Sophos UTM。

SSH使用UDP做什么？@ superuser.com - 它不直接从我读。

在查看防火墙日志时，在源IP端口和目标端口4500上都通过公用IP地址（而不是专用站点到站点内部VPN地址）进行了泛洪检测。因此，似乎我的问题很可能是NAT遍历情况，其中scpTCP数据最终被加密并封装在ESP和UDP数据包中，因此受到FP的约束。为了scp从方程式中删除，我在VPN上运行了Windows文件复制操作，并注意到与scp启用和未启用FP 相似的性能。还iperf通过TCP 进行了测试，发现使用FP时为2Mbits / sec，不使用时为55Mbits / sec。

NAT-T如何与IPSec配合使用？@ cisco.com

— 宝洁
source