使用LFTP持续部署时，每传输约10个文件会暂时卡住

嘿，我遇到过类似的LFTP批量小文件传输冻结的问题，结合你用GitLab Runner+OVH服务器的场景，给你几个实战性的优化方案，应该能解决超时崩溃的问题：

LFTP默认的参数对批量小文件不太友好，容易触发连接阻塞，你可以在传输命令里加上这些配置：

• 缩短超时时间，避免死等无效连接：set net:timeout 10（把超时设为10秒，默认时长更长）
• 减少重试次数，防止重试堆积：set net:max-retries 3
• 限制并发连接数，小文件没必要高并发：用mirror命令时加--parallel=2，把并行传输数降到2
• 试试关闭被动模式：set ftp:passive-mode no，同机房的OVH服务器用主动模式可能更直接，避免被动模式的路由绕路

举个完整的命令例子：

lftp ftp://username:password@your-target-server -e "set net:timeout 10; set net:max-retries 3; mirror --parallel=2 --only-newer /path/to/local/json /path/to/remote/json; quit"

有时候问题出在Runner这边：

• 确认Runner所在机器和目标OVH服务器在同一个机房，OVH不同区域的内网传输比跨区域稳定太多，要是跨机房了赶紧调整Runner的部署位置
• 在CI脚本里加个前置的网络检测：ping -c 3 your-target-server，如果丢包率高，说明OVH内部网络有波动，可以加个简单的重试逻辑（比如用until循环直到ping通再执行传输）
• 别让Runner同时跑多个传输任务，资源竞争也会导致传输卡顿

FTP本身就不如SFTP稳定，尤其是批量小文件场景，LFTP完美支持SFTP，而且OVH服务器默认开启SSH，不需要额外配置FTP服务：
把命令改成SFTP协议就行，比如：

lftp sftp://username:password@your-target-server -e "mirror --delete --only-newer /path/to/local/json /path/to/remote/json; quit"

SFTP基于SSH连接，可靠性更高，不会出现FTP那种连接挂起的情况，安全性也更好。

如果上面的方法都没解决，就开启debug日志看看冻结时到底在干嘛：
在命令前加-d参数，比如：

lftp -d ftp://username:password@your-target-server -e "mirror ...; quit"

日志会输出到GitLab CI的控制台里，你能看到是连接超时、等待服务器响应还是其他问题，要是发现是服务器端的响应慢，直接联系OVH支持排查FTP服务状态就行。

内容的提问来源于stack exchange，提问作者Dennis van der Veeke