[Feature] 增强传输监控与基于空间的并发控制策略 #1893
Description
请确认以下事项
-
我已确认阅读并同意 AGPL-3.0 第15条 。
本程序不提供任何明示或暗示的担保，使用风险由您自行承担。 -
我已确认阅读并同意 AGPL-3.0 第16条 。
无论何种情况，版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。 -
我确认我的描述清晰，语法礼貌，能帮助开发者快速定位问题，并符合社区规则。
-
我已确认阅读了OpenList文档。
-
我已确认没有重复的问题或讨论。
-
我认为此问题必须由
OpenList处理，而非第三方。 -
我已确认此功能尚未被实现。
-
我已确认此功能是合理的，且有普遍需求，并非我个人需要。
需求描述
Feature Request: 增强传输任务的全局监控与基于缓存空间占用的并发控制策略
1. 需求背景 (Background)
目前在进行跨盘搬迁或大规模上传任务时，存在以下痛点：
- 监控不准： 依赖系统或任务栏插件的网速统计，在开启代理时常出现双倍统计，且无法准确区分“本地写入缓存速度”与“网络实际外发速度”。在某些特殊环境（如运营商云手机）下，系统层 API 无法统计网速。
- 磁盘风险： 现有的任务并发限制仅基于“线程数”。若同时处理多个超大文件，本地磁盘缓存会瞬间溢出，导致任务失败甚至系统卡死。
2. 功能描述 (Description)
A. 应用内全局网速监控看板
- 实现思路： * 在应用界面（或任务管理页）新增一个实时流量统计模块。
- 数据来源： 直接从应用层（Application Layer）的 Socket 流中读取 Read/Write 计数，而非调用系统接口。
- 显示指标： 实时上传速度 (Up)、实时下载速度 (Down)、当前活动连接数。
- 优势： 彻底解决代理软件导致的流量双倍统计问题，且能在系统网速监控失效的环境下正常工作。
B. 基于“文件累计大小”的并发控制逻辑 (Backpressure Mechanism)
- 实现思路：
- 在现有的“最大并发线程数”基础上，增加一个配置项：
Max Total File Size in Queue (GB)（当前排队文件累计最大体积）。 - 优先级策略： 该限制的优先级高于线程限制。
- 逻辑判断： ```text
If (当前正在处理的文件总大小 + 下一个待处理文件大小) > 设定阈值:
保持当前线程，暂停读取新任务进入缓存；
Else:
根据线程数限制继续开启新任务。 - 优势： 有效防止在文件大小分布不均时，因多个大文件同时写入缓存而导致的磁盘空间耗尽（Disk Full）。
- 在现有的“最大并发线程数”基础上，增加一个配置项：
3. 实现建议 (Implementation Suggestions)
- 监控： 可以参考
rclone或aria2的内部流量统计实现方式。 - 并发控制： 在 Task Manager 的 Dispatcher 阶段增加一个信号量或计数器，实时计算当前正在
Copying/Uploading状态的文件 Buffer 总量。
哦对 还有一个问题就是：正在执行的任务不会置顶显示在第一页，很不方便找
感谢开发者对项目的维护，希望这些建议能帮助 openlist 在处理重型搬迁任务时更加稳健。
实现思路
No response
附加信息
No response