[Bug] 电脑本地上传附件到nas服务器端会卡到一半不动
Closed this issue · 13 comments
提问前查询
- 我已经在 issues 列表 里查询过，并且没找到类似的问题。
组件
服务端 (server)
运行环境
Git Branch HEAD Git Commit f340701 Commit Time 2024-11-24
Build Version 0.20.6 Build Name server Build Time 2024-11-24
OS Name Linux OS Version 4.4.302+ OS Arch aarch64
| Java Version | 17.0.12 | Vendor Name | Eclipse Adoptium | Vendor Version | Temurin-17.0.12+7 |
|---|---|---|---|---|---|
| Runtime Name | OpenJDK Runtime Environment | Runtime Version | 17.0.12+7 | ||
| JVM Name | OpenJDK 64-Bit Server VM | JVM Vendor | Eclipse Adoptium | JVM Version | 17.0.12+7 |
POSTGRESQL 13.2-3
报错相关的日志
A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received发生了什么
上传附件卡住
预期是怎样
上传附件成功
如何复现
正常操作上传附件
其它补充内容
No response
请问是每次上传都会卡住嘛？
请问是每次上传都会卡住嘛？
是的，同一个文件A，200m必然卡住，有可能30%，也有可能60%；（PC浏览器->ikaros NAS服务器端）
另一个文件B，1.2m,可以正常传输，就是1%-100%很快，100%到“绿色传送完成”时间有点长；（PC浏览器->ikaros NAS服务器端）
之前那个文件A，200m，在PC浏览器->ikaros PC服务器端上传很快(电脑本地另外建的ikaros服务器)没有问题。甚至几G的也没问题。
100%到“绿色传送完成”时间有点长
这时服务端在后台合并分片中
你的NAS什么配置？
低端配置。
我的想法是对于这种低端服务器用群晖上传工具把数据放进links文件夹（更有鲁棒性），然后让plugin-local-files-import把数据吞进去作为普通上传的替代。
CPU Realtek RTD1296 四核心 1.4GHz
硬體加密引擎 有
硬體轉碼引擎
• 支援轉碼器：MPEG-4 Part 2 (XVID, DIVX5)、MPEG-2、VC-1、10-bit H.265 (HEVC)
• 最高解析度：4K (4096 x 2160)
• 每秒最大幀率 (FPS)：60
記憶體 1 GB DDR4
相容硬碟類型 2 x 3.5 吋或 2.5 吋 S
低端配置。
我的想法是对于这种低端服务器用群晖上传工具把数据放进links文件夹（更有鲁棒性），然后让plugin-local-files-import把数据吞进去作为普通上传的替代。
CPU Realtek RTD1296 四核心 1.4GHz 硬體加密引擎 有 硬體轉碼引擎 • 支援轉碼器：MPEG-4 Part 2 (XVID, DIVX5)、MPEG-2、VC-1、10-bit H.265 (HEVC) • 最高解析度：4K (4096 x 2160) • 每秒最大幀率 (FPS)：60 記憶體 1 GB DDR4 相容硬碟類型 2 x 3.5 吋或 2.5 吋 S
才1GB的内存嘛？我怀疑是内存太少了，你肯定还有其它软件，安装完ikaros后，剩余内存还剩多少？
硬盘空间多大？
还有上传文件时，服务端日志有报错嘛？
低端配置。
我的想法是对于这种低端服务器用群晖上传工具把数据放进links文件夹（更有鲁棒性），然后让plugin-local-files-import把数据吞进去作为普通上传的替代。CPU Realtek RTD1296 四核心 1.4GHz 硬體加密引擎 有 硬體轉碼引擎 • 支援轉碼器：MPEG-4 Part 2 (XVID, DIVX5)、MPEG-2、VC-1、10-bit H.265 (HEVC) • 最高解析度：4K (4096 x 2160) • 每秒最大幀率 (FPS)：60 記憶體 1 GB DDR4 相容硬碟類型 2 x 3.5 吋或 2.5 吋 S才1GB的内存嘛？我怀疑是内存太少了，你肯定还有其它软件，安装完ikaros后，剩余内存还剩多少？ 硬盘空间多大？ 还有上传文件时，服务端日志有报错嘛？
没有任何errorlog（所有功能正常）
内存基本上都在50%左右，机械硬盘还有几十G
今天测试了800M文件C从NAS一块硬盘上传到NAS另一块硬盘，ikaros进度条卡在87%。
我再换下firefox试试，可能chrome浏览器扩展影响了传输性能。
你们是不是在上传分片过程中就把文件重命名了？（是不是用文件的哈希值命名的？）
从NAS一块硬盘上传到NAS另一块硬盘
这是啥情况？你用的nas的浏览器操作的？
应该和浏览器没关系
文件分片合并后文件名不变的
已经确认大概率是chrome 浏览器的性能bug或受其第三方扩展影响
参考Version 131.0.6778.87，或许建个新profile就行了。
抛弃了臃肿的chrome，用fresh new的firefox上传可靠性杠杠的
已经确认大概率是chrome 浏览器的性能bug或受其第三方扩展影响
参考Version 131.0.6778.87，或许建个新profile就行了。
抛弃了臃肿的chrome，用fresh new的firefox上传可靠性杠杠的
你本地部署的服务端用这个版本chrome 能正常上传吗？
我的chrome版本还是：Version 131.0.6778.86
可以试试升级chrome到最新版
已经确认大概率是chrome 浏览器的性能bug或受其第三方扩展影响
参考Version 131.0.6778.87，或许建个新profile就行了。
抛弃了臃肿的chrome，用fresh new的firefox上传可靠性杠杠的你本地部署的服务端用这个版本chrome 能正常上传吗？
可以，
可以试试升级chrome到最新版
我昨天用的还是和你现在一样的Version 131.0.6778.86，应该是刚刚顺手升级的；
几年前都是用的canary版本，后来实在崩溃地不行最后妥协到正式版本。
这个问题应该和版本无关，一个chrome profile在不同版本间切换时间长了就容易损坏，导致基本功能异常。