scp在复制大文件时停滞不前

fly*_*hzy 36 bash shell scp

根据实验的需要,我将MTU设置为8000.这样做之后,当我scp用来复制大文件时,它就会停滞不前0.00%.我试过scp -lscp -C打开tcp_sack/关闭,但它仍然无法正常工作.并且我无法更改实验结果比较的MTU大小.还有其他方法可以帮助吗?

Bre*_*Man 72

尝试全面解决方案,因为根据您的情况可能存在一些问题和限制.

rsync的

我的首选方案:使用rsync 不会出现这个问题,而且在我看来它更具通用性,例如它跟踪哪些文件已经存在,所以如果连接确实中断它可以从它停止的地方继续 - 尝试--partial国旗 - 除其他外.

代替

scp local/path/some_file usr@server.com:"/some/path/"
Run Code Online (Sandbox Code Playgroud)

你可以这样做

rsync -avz --progress local/path/some_file usr@server.com:"/some/path/"
Run Code Online (Sandbox Code Playgroud)

我曾经多次测试过它scp会给我带来同样的问题 - 现在我只是默认使用rsync.

限速

不是OP的解决方案,因为在这种情况下MTU是固定的(这里可能不是问题),但如果罪魁祸首是两个驱动器之间的连接缓慢/不可靠,设置速度限制会减少导致TCP连接停顿的延迟 - 以较慢的转移为代价.这是因为除非您以千位为单位指定最大数据速率,否则scp会抓取它可以获得的所有带宽,如下所示:

scp -l 8192 local/path/some_file usr@server.com:"/some/path/"
Run Code Online (Sandbox Code Playgroud)

但这并不总是有效.

压缩选项

scp的-C选项可以加快传输速度,降低传输停顿的可能性.

禁用TCP SACK

正如OP所提到的,在这里.

sudo sysctl -w net.ipv4.tcp_sack=0
Run Code Online (Sandbox Code Playgroud)

(或类似的)

局域网卡MTU

同样是一个MTU修复,不一定具体转移,但:

ifconfig eth0 mtu 1492
Run Code Online (Sandbox Code Playgroud)

或者在较新的(Linux)系统上:

ip link set dev eth0 mtu 1492
Run Code Online (Sandbox Code Playgroud)

其他

如果所有其他方法都失败了,将列出此处未包含的另一些潜在解决方案.

更奇特的hpn bug也可能是错误的.


小智 -1

您是否有可能位于 Cisco ASA 防火墙后面?如果是这样,请关闭“序列号随机化”,这将有很大帮助 - 如果您的服务器中使用的是带有 Broadcom NIC 的 Cisco ASA,还可以禁用 TCP 卸载(ethtool -K $INTERFACE tso off gso off gro off) 。