bash scp 在复制大文件时停止
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/20625000/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
scp stalled while copying large files
提问by flyhighzy
According to the needs of the experiment, I set the MTUto 8000. After doing this, when I use scpto copy large files, it stalled with 0.00%. I tried scp -lor scp -Cand turning tcp_sackon/off, but it still didn't work. And I can't change the MTU size for experiment result comparison. Is there any other way to help?
根据实验需要，我将MTU设置为8000。这样做之后，当我scp用来复制大文件时，它停止了0.00%. 我试过scp -l或scp -C打开tcp_sack/关闭，但它仍然不起作用。并且我无法更改用于实验结果比较的 MTU 大小。有没有其他方法可以提供帮助？
回答by BrechtDeMan
An attempt at a comprehensive solution, as there could be several problems and limitations depending on your situation.
尝试全面的解决方案，因为根据您的情况可能存在多个问题和限制。
rsync
同步
My preferred option: using rsyncdoesn't give this problemand is a bit more versatile in my opinion, e.g. it keeps track of which files are already there, so if the connection ever does break it can pick up from where it left off - try the --partialflag too- among other things.
我的首选选项：使用rsync不会出现这个问题，而且在我看来它的用途更广，例如，它跟踪哪些文件已经存在，因此如果连接确实中断，它可以从中断的地方恢复-也试试这个--partial标志——除其他外。
Instead of
代替
scp local/path/some_file [email protected]:"/some/path/"
you can just do
你可以做
rsync -avz --progress local/path/some_file [email protected]:"/some/path/"
I've tested this on several occasions when scpwould give me the same problem it gave you - and now I just use rsync by default.
我已经多次测试过它什么时候scp会给我带来同样的问题 - 现在我默认使用 rsync 。
Limit speed
限速
Not a solution for OP as the MTU is fixed in this situation (and probably not the issue here), but if the culprit is a slow/unreliable connection between the two drives, setting a speed limit reduces the delays which make the TCP connection stall - at the expense of a slower transfer of course. This is because scp grabs all the bandwidth it can get unless you specify the maximum data rate in kilobits, like so:
不是 OP 的解决方案，因为 MTU 在这种情况下是固定的（可能不是这里的问题），但如果罪魁祸首是两个驱动器之间的缓慢/不可靠的连接，设置速度限制会减少导致 TCP 连接停顿的延迟- 当然以传输速度较慢为代价。这是因为 scp 会获取它可以获得的所有带宽，除非您以千位为单位指定最大数据速率，如下所示：
scp -l 8192 local/path/some_file [email protected]:"/some/path/"
This doesn't always workthough.
但这并不总是有效。
Compression option
压缩选项
scp's -C option can speed upthe transfer, reducing the probability that the transfer stalls.
scp 的 -C 选项可以加快传输速度，减少传输停滞的可能性。
Disabling TCP SACK
禁用 TCP SACK
As mentioned by the OP, and here.
正如 OP 和此处所述。
sudo sysctl -w net.ipv4.tcp_sack=0
（或类似）
LAN card MTU
网卡 MTU
Again an MTU fix, not necessarily of the transfer specifically though:
同样是MTU 修复，但不一定是专门的传输：
ifconfig eth0 mtu 1492
or on newer (Linux) systems:
ip link set dev eth0 mtu 1492
Other
其他
If all else fails, thislists another handful of potential solutions not included here.
如果所有其他方法都失败了，这里列出了此处未包含的其他一些潜在解决方案。
The more exotic hpn bugmay be at fault too.
更奇特的hpn 错误也可能有问题。
回答by dotwaffle
Any chance you're behind a Cisco ASA firewall? If so, turn off "sequence number randomization" and that'll help a lot -- also disable TCP Offload (ethtool -K $INTERFACE tso off gso off gro off) if you're on a Cisco ASA with Broadcom NICs in your server.
您是否有可能在 Cisco ASA 防火墙后面？如果是这样，请关闭“序列号随机化”，这将有很大帮助 - 如果您使用的是服务器中带有 Broadcom NIC 的 Cisco ASA，也可以禁用 TCP 卸载（ethtool -K $INTERFACE tso off gso off gro off） .
