Web 端闲置 Session 恢复卡住：模型目录正常，但 session/list 与 follow 超时

[ManfredCh]

环境与当前配置

• 官方仓库：deepseek-ai/deepseek-harness；本机源码分支 master，HEAD 为 46a7f68b09（2026-09-23）。
• 运行方式：本机 Web Host 监听 127.0.0.1:4280，由 dsh web --no-open --port 4280 启动；Remote Web UI、自动隧道和 relay 已启用，局域网访问要求配对。
• 默认模型：deepseek-official/deepseek-flash，reasoning effort 为 max。
• 模型 Provider：xiaomi（4 个 MiMo 模型：MiMo-V2.5、MiMo-V2.5-Pro、MiMo-V2.5-Pro-UltraSpeed、MiMo-V2.6-Pro；配置的 context window 为 1,048,576，max tokens 为 131,072）；newapi（1 个模型 gpt-6-astra，context window 为 1,000,000，max tokens 为 32,000）；deepseek-official（现场模型目录探针返回 2 个模型）。凭证和 Provider 地址未包含在本帖。
• 并发配置：maxParallelToolCalls: 90，maxActiveSubagents: 64。
• systemd 未配置 MemoryMax、MemoryHigh 或 CPUQuota；TasksMax 为 230,950。

问题现象

只有已经活跃的 session 能正常交流。闲置一段时间后，其他 session 周期性刷新但无法恢复，模型选择列表也出不来，无法重新加入交流。

只读探针结果（2026-09-27）

• settings/describe：正常，约 1.1 秒。
• session/modelCatalog：HTTP 200，约 0.7 秒；3 个 Provider 共 7 个模型，未报告 Provider 失败。
• session/list：等待 15 秒后超时。
• 对两条普通持久化 session 打开 /api/remote.mux 并请求 session/follow：WebSocket 握手成功，但 7 秒内均未收到首帧。
• 本机约有 2,531 条持久化 session 记录，合计约 0.87 GiB，最大单条约 40.5 MiB。未在帖子中包含 session ID、名称、对话内容或令牌。
• 主机有 24 个 CPU 线程、188 GiB RAM；采样时约 131 GiB 可用，2 GiB swap 中约 1.9 GiB 已用。系统负载约 37。没有证据表明 DSH 的 systemd CPU/内存硬限制已触顶。

当前判断与问题

模型目录接口本身能够快速返回，但持久化 session 列表和普通 session 的跟随流均超时。因此目前更怀疑闲置 session 的持久化枚举、冷恢复或 session 流初始化路径；根因尚未确认。主机同时有较高的整体负载，可能加重延迟。

请问在这种“活跃 session 正常、闲置 session 的列表/跟随流不返回，但全局 session/modelCatalog 正常”的情况下，维护者建议优先检查哪些 Host 日志或诊断入口？当前持久化 session 数量是否足以触发已知的 session/list 或冷恢复性能问题？

本帖只报告运行配置和脱敏后的接口探针，没有附带任何 API key、令牌、公开隧道 URL、session 标识或用户对话。