-
-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[百度网盘]使用大分片时,偶发 Client.Timeout exceeded while awaiting headers #7961
Comments
补充说明:我确定这不是网络问题,在抓包过程中能看到有来自服务器的包到Alist(所在主机)之后被回复RST,应该就是超时时间后上游回包了 |
百度那边是30秒没传完分片就直接超时 |
请求来源 |
你自己翻issuse 或者直接问百度 |
你的日志是webdav本身的超时吧 |
翻到了,迟点复现一下估计 |
webdav超时我给了一天,图片右边的是alist容器stdout |
你的文件有点大,试试直接给 0 |
就剩这一个文件,2h也传的完了。只是四线程+SVIP分片的情况下,右边一直看着有重试。 我家上传运营商写的是40Mbps,实际峰值 4~5 MB/s |
另外根据实测,分片数量限制也不是 1024 了现在。昨晚用4M的分片传了一个 7.41 G 的文件 |
你现在分片是多少? |
现在是就这一个文件,分片设置 0(自动(SVIP 32M)),线程设置是4。 |
那你改成4194304 |
昨晚试过了,4M传不了22G,会出 31299。 |
线程改1 |
大文件手动监护的情况下是考虑这么干了。回头看看代码上能不能优化一下吧,毕竟常见场景是配合rclone做自动备份 |
有个问题,中间有一个分片传输失败了,也是要所有分片上传完才丢出报错啊 |
准确测试了,最大是2000个分块 |
Please make sure of the following things
I have read the documentation.
我已经阅读了文档。
I'm sure there are no duplicate issues or discussions.
我确定没有重复的issue或讨论。
I'm sure it's due to
AList
and not something else(such as Network ,Dependencies
orOperational
).我确定是
AList
的问题,而不是其他原因(例如网络,依赖
或操作
)。I'm sure this issue is not fixed in the latest version.
我确定这个问题在最新版本中没有被修复。
AList Version / AList 版本
v3.41.0(cf58ab3)
Driver used / 使用的存储驱动
baidu_netdisk
Describe the bug / 问题描述
如题,在 会员/超级会员 的情况下,上传过程中一直会有超时重试的信息在stdout中输出,并且有概率恶化导致文件传输失败。
做了一些简单的测试,此问题在指定分片为4M的情况下可以明显缓解,不确定是大分片导致网络层面的问题(传输时间增加、重传)还是服务端层面的问题(计算md5耗时增加),或者兼而有之。
可能的修复方式:
其他关联:#5392
Reproduction / 复现链接
我无法给出复现链接因为这在我的内网,但我可以积极配合测试。
Config / 配置
Logs / 日志
The text was updated successfully, but these errors were encountered: