[Performance] Web UI: an active session tab keeps burning 1+ CPU core and its memory grows unbounded

[lumanlight]

TL;DR (English)

On DSH 0.2.1-alpha.2 (Chrome 155, Ubuntu 24.04, i7-8650U 4C/8T), a Web UI tab that has an
agent turn in flight keeps a Chrome renderer at 82–165% CPU (≈1–1.6 cores), while the very
same page freshly loaded and idle costs only 4.9%. Renderer RSS grows unbounded:
675MB → 970MB within ~4 minutes on a new tab, and 908MB on a 24h-old tab
(176 min CPU accumulated). The cost is paid even when the tab is not being viewed
(Chrome only stops painting and throttles timers for hidden tabs; DSH is WebSocket-driven,
so every message still triggers parse + re-render). session/list returns
949 sessions / 1,326,496 bytes in one response, so every page load/refresh re-fetches and
rebuilds the whole list. With 6 sessions running concurrently the machine saturates and the UI
(including the "thinking" spinner) visibly janks. Raw measurements and repro commands are in
Appendix A below.

---

1. 摘要

在同一台机器、同一个 DSH 服务上做 A/B 对比：

场景	渲染进程 CPU	渲染进程 RSS
全新打开 DSH 页面，静置 15s（无回合在跑）	4.9%（同实例其余渲染进程 ≤0.4%）	269MB
已有回合进行中，工具执行阶段（页面没有新 token 流入）	82.4%（15s 平均）	675MB
同一页面，流式输出阶段	102% ~ 165%（瞬时/采样峰值）	675MB → 970MB（约 4 分钟）
同一标签页挂机 24 小时（前一个实例）	累计 176 分钟 CPU	908MB

即：一个正在跑任务的会话页面 ≈ 1~1.6 个 CPU 核，而同一页面空闲时只要 5%。在 4 核 8 线程笔记本上同时开多个会话时，机器被订满，UI（包括"思考中"的进度圈）明显掉帧。

另有两个独立现象：

• 渲染开销与"是否在看这个页面"无关：实测在页面非前台（当时用户正在操作另一个窗口）时仍持续 82%~165%。Chrome 对隐藏标签页只停止绘制并节流定时器，不会停事件驱动的 JS；DSH 靠 WebSocket 推流，每条消息都会触发解析 + 重渲染。
• 会话列表全量返回：session/list 一次返回 949 个会话 / 1,326,496 字节，每次打开或刷新页面都要重新拉取并重建列表，刷新耗时明显（且刷新并不能降低负载）。

---

2. 环境

项	值
DSH	0.2.1-alpha.2（@deepseek-ai/dsh、dsh-web、dsh-web-frontend、dsh-client-ui-conversation、dsh-agent-loop 同版本）
运行方式	systemctl --user 常驻服务，dsh web 监听 127.0.0.1:3080
Node	v22.23.3
浏览器	Chrome 155.0.8059.79（Wayland/ozone）；对照测试用 headless Chrome 153.0.8010.36
OS	Ubuntu 24.04.5 LTS，kernel 6.8.0-136-generic，KDE/KWin Wayland
硬件	Intel i7-8650U（4C8T）/ 16GB / NVMe
并发情况	测量时 6 个会话同时 running（1 个主会话 + 3 个 teammate 的 Agent Teams 项目 + 2 个独立会话），但只有 1 个前端连接

---

3. 关键观察

1. 成本不只是"流式渲染"：在工具执行阶段（页面没有新 token 流入）仍持续 82% CPU。
2. 内存单调增长、没有上界：新开页面 4 分钟 675MB→970MB；挂 24 小时的页面 908MB。
3. 前端 bundle 中不存在 setInterval：dsh-client-ui-conversation/lib/client.js 里 setInterval 出现 0 次，requestAnimationFrame 出现 7 次。
4. 隐藏标签页不等于停工：见第 1 节。
5. 多会话并发时前端成本叠加：实测 6 个会话在跑、只有 1 个页面被观看，其余 5 个会话照样在后端推进；被观看的那个页面持续吃 1 个多核。
6. 会话列表与刷新：session/list 返回 949 项 / 1.3MB；页面打开/刷新要全量拉取。

---

附录 A：复现与测量方法

A.1 找出 DSH 页面的渲染进程并测 CPU（无需 root）

# 1) Chrome 多进程：--type=renderer 才是"某个页面"
ps -eo pid,pcpu,rss,etime,args --sort=-pcpu | grep -- '--type=renderer' | grep -v grep

# 2) 取一个渲染进程，10 秒差分测 CPU（%CPU 是线程和，>100% 正常）
P=<renderer_pid>
t=$(awk '{print $14+$15}' /proc/$P/stat); sleep 10
s=$(awk '{print $14+$15}' /proc/$P/stat)
awk -v d=$((s-t)) 'BEGIN{printf "%.1f%%\n", d/10}'
grep VmRSS /proc/$P/status

A.2 确认某个渲染进程承载的是哪个页面（内存指纹）

渲染进程命令行里没有 URL，可用内存指纹判定（实测：DSH 页面命中 127.0.0.1:3080 18 次、DeepSeek Harness 7 次；对照的普通网页标签命中其站点域名 24 次、3080 命中 0 次）：

# 用法: python3 procmem_scan.py <renderer_pid>
import sys
pid = sys.argv[1]
markers = [b'127.0.0.1:3080', b'DeepSeek Harness']
found = {m: 0 for m in markers}
regions = []
for l in open(f'/proc/{pid}/maps'):
    p = l.split()
    if 'r' not in p[1] or len(p) < 6:      # 只读 + 跳过 file-backed
        continue
    a, b = p[0].split('-'); regions.append((int(a, 16), int(b, 16)))
mem = open(f'/proc/{pid}/mem', 'rb', 0); total = 0
for a, b in regions:
    if b - a <= 0 or b - a > 256 * 1024 * 1024: continue
    try: mem.seek(a); data = mem.read(b - a)
    except Exception: continue
    total += len(data)
    for m in markers:
        if m in data: found[m] += 1
    if total > 700 * 1024 * 1024: break
print({k.decode(): v for k, v in found.items()})

A.3 干净页面对照实验（无头 Chrome，独立 profile）

TOK=$(journalctl --user -u dsh | grep -o 'token=[^ ]*' | tail -1 | cut -d= -f2)
/opt/google/chrome/chrome --headless=new --user-data-dir=/tmp/dshprobe --no-first-run \
  --disable-gpu --remote-debugging-port=9411 "http://127.0.0.1:3080/?token=$TOK" &
sleep 22
curl -s http://127.0.0.1:9411/json/list   # 确认 target 是 http://127.0.0.1:3080/ "DeepSeek Harness"
# 然后按 A.1 对该实例的渲染进程测 15 秒 CPU/RSS

A.4 会话列表规模与运行中会话数

TOK=$(journalctl --user -u dsh | grep -o 'token=[^ ]*' | tail -1 | cut -d= -f2)
curl -s -c /tmp/jar -o /dev/null "http://127.0.0.1:3080/?token=$TOK"
C=$(awk '/dsh-auth/ {print $6"="$7}' /tmp/jar)
curl -s -X POST http://127.0.0.1:3080/api/session/list \
  -H "content-type: application/json" -H "Cookie: $C" \
  -d '{"type":"client-request","rpcId":"11111111-1111-1111-1111-111111111114","method":"session/list","payload":{"args":{"_request":{}}}}' \
  > /tmp/sessions.json
stat -c '%s bytes' /tmp/sessions.json        # 实测 1326496
python3 -c "import json;d=json.load(open('/tmp/sessions.json'));i=d['result']['value']['items'];print('items',len(i),'running',sum(1 for x in i if x.get('running')))"

A.5 前端 bundle 里的定时器/动画统计

cd ~/.dsh/profiles/web/node_modules/@deepseek-ai
grep -o 'setInterval'    dsh-client-ui-conversation/lib/client.js | wc -l   # 0
grep -o 'requestAnimationFrame' dsh-client-ui-conversation/lib/client.js | wc -l  # 7

---

附录 B：实测时的其他负载

load average 4.23，8 线程：

项	数值
内存	15.9Gi 用 10Gi，swap 已用 2.7Gi（在换页）
并发 agent	6 个会话 running；近 3 分钟 22 个沙箱子进程
文件索引	tracker-miner-fs-3 已索引 377,787 文件 / 写盘 16.9GB / 2,434 条失败，平均 17% CPU（6.8 小时）
其他常驻应用	浏览器多进程（31+）、编辑器 ~1.3GB、IM 客户端 ~1.7GB、笔记应用 ~0.6GB、MCP 进程 ~0.5GB
显示	内核日志 i915 ... Atomic update failure on pipe A 反复出现（当日 5 次）
温度	78°C，风扇 6185 RPM