issue: Very high CPU 24×7 after upgrade v0.9 – v0.11 and few attempts to use subagents

快速结论：该报错通常发生在从 v0.9.6 升级到 v0.11.0 之后，系统空闲时 Open WebUI 进程持续占用高 CPU（80%-230%），且与 subagents 活动无明显关联。优先排查 v0.11.0 新增的 timer 轮询机制，可通过设置 TIMER_POLL_INTERVAL=60 环境变量并重启来验证。

适用环境：Open WebUI v0.11.0（Git Clone 方式安装）、Ubuntu 24、pipx；数据库为 PostgreSQL 17 + pgvector；未使用 Docker。

最快修复方案：设置环境变量 TIMER_POLL_INTERVAL=60 并重启 Open WebUI。Issue 评论中明确指出该轮询循环每秒钟在所有 v0.11 实例上运行，不受 subagents、automations 或 calendar 控制，且 v0.9.6 中不存在。该方案已获维护者验证建议。

注意事项：此方案仅解决空闲 CPU 占用问题。设置后定时任务最多延迟 1 分钟触发，不影响其他功能。subagents 挂起问题在本 Issue 中缺乏日志和 profile 证据，需在 staging 环境复现后单独提交 Issue，并附上 py-spy profile。

问题场景

用户从 v0.9.6 升级到 v0.11.0（数据库迁移约 1.5 小时），启用 subagents 并尝试少量测试后，发现子代理创建时长时间不调用模型、持续占用 CPU。即使禁用 subagents 并重启系统后，open-webui 进程仍持续 80%-130% CPU 占用（测试 subagents 时高达 230% 及高内存）。此时系统无用户登录、无模型流量、无 PostgreSQL 活动，仅 open-webui 进程自身高 CPU。用户回滚至 v0.9.6 后问题消失。

报错原文

issue: Very high CPU 24x7 after upgrade v0.9 - v0.11 and few attempts to use subagents
top - 10:03:46 up 67 days, 18:07,  1 user,  load average: 0.70, 0.77, 0.81
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 851776 root      20   0   26.6g   7.8g 667568 S  80.4  12.4 308:56.83 open-webui
Sometimes 80% sometimes 130%. Up to 230% and huge memory when we tested subagents.

原因分析

根据 Issue 维护者（tjbck）的分析，空闲高 CPU 的根本原因是 v0.11.0 引入的 timer 轮询循环（timer polling loop），它每秒执行一次，且不受 subagents、automations 或 calendar 功能开关控制。该循环在 v0.9.6 中不存在，与 subagents 的启用/禁用无关——即使禁用 subagents 并重启，轮询仍持续运行。

可能原因还包括：

1. v0.11.0 的 timer 轮询查询在 PostgreSQL 上产生额外开销，但用户报告未观察到 PostgreSQL 进程明显占用，因此更倾向于是 open-webui 进程内的轮询逻辑消耗 CPU。

2. subagents 挂起问题与空闲 CPU 问题可能是独立的两个缺陷，但高 CPU 掩盖了 subagents 的调试，导致难以区分。

环境排查

Open WebUI 版本：确认是否为 v0.11.0（用户已从 v0.9.6 升级）
操作系统：Ubuntu 24，使用 pipx 安装
数据库：PostgreSQL 17 + pgvector（用于 RAG，配置原数据在本地默认数据库）
环境变量：检查是否已设置 TIMER_POLL_INTERVAL（默认未设置，即每秒轮询）
Ollama 版本：Issue 中未提供，无需补写
模型：Qwen3.5-27b / Qwen3.6-27b（vLLM 部署），但空闲高 CPU 时无模型调用

解决步骤

确认 open-webui 进程在无任何活动时仍高 CPU（使用 top 或 htop 观察至少 5 分钟）。
设置环境变量 TIMER_POLL_INTERVAL=60（参考官方文档：env-configuration），然后重启 Open WebUI。
观察 CPU 是否回落到正常水平（接近 0%）。如果 CPU 下降，确认这是 #27622 的重复问题，等待上游 PR 修复。
如果 CPU 未下降，需要获取 py-spy profile 来定位具体原因（Issue 维护者明确指出“没有 profile 就没有可操作的信息”）。
针对 subagents 挂起问题：需在 staging 环境复现（建议在修复 timer 问题后），复现时收集 py-spy profile、模型和工具配置，提交单独 Issue。

验证方法

设置 TIMER_POLL_INTERVAL=60 并重启后，使用 top 观察 open-webui 进程 CPU 占用。如果长时间（至少 10 分钟）保持低 CPU（接近 0%），且无用户登录、无模型调用，说明 timer 轮询是高 CPU 的根因，问题已解决。注意：定时任务（automations/calendar）的触发延迟最多 1 分钟，属预期行为。