DSH 在低配机器上的内存与磁盘要求

DSH 只做编排，推理走远程 API，进程本身很轻。但“轻”到什么程度、什么配置能装、什么情况下会卡死，要分开看内存和磁盘。

什么情况下会撞上这个问题

在 2 核 2 GB 云主机或低配 NAS 上全局安装，npm install 跑到一半机器失去响应；或装完后担心常驻进程吃内存，不敢同时跑多个任务。

结论：不跑本地模型时，空闲内存 1 GB 能跑，2 GB 推荐，4 GB 更宽裕。安装阶段的问题通常不是内存不够，而是磁盘 I/O 和换页。

为什么会这样

实测：16 GB 内存的 NAS 上，dsh web 进程 RSS 约 407 MB（Node v24.15.0）；dsh --version 冷启动峰值约 67 MB。Harness 主进程是几百 MB 量级，不是几个 GB。

真正吃资源的是两类场景：工具返回大量输出（读大文件、跑构建、执行长命令）；同时开多个 subagent、workflow 或后台 job，每个都是独立进程，内存按份叠加。

安装阶段则不同：在 954 MB 内存的 Ubuntu 24.04 云主机（2 核）上全局安装，npm 安装体积约 900 MB、195 个依赖包。安装本身几乎不占内存，但内存不足导致频繁换页，磁盘读写被打满，表现就是整机卡顿。看到“安装卡住”，先查 free -h 和 vmstat 1 的 si/so 列。

怎么做

第一步，确认内存与 swap：

free -h
swapon --show

若 Swap 为 0 且可用内存低于 1 GB，先加 swap。2 核 2 GB 建议加 2 GB：

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

再把 /swapfile none swap sw 0 0 写进 /etc/fstab。swap 让安装期间的换页有落点，避免进程被 OOM killer 杀掉。

第二步，确认磁盘余量。安装约 0.9 GB，npm 或 pnpm 缓存还会再占几 GB，会话记录和产物也在同一卷。会话记录位于 /sessions/ 下的 session.v4.jsonl.zstd，插件配置在 /integrations/dsh-im/。df -h 至少留 5 GB。

第三步，安装后验证：

dsh --version
ps -o rss= -p $(pgrep -f "dsh web")

RSS 在几百 MB 属正常。偏高则检查是否有多个后台 job 同时在跑。

怎么确认成了

• swapon --show 能列出 /swapfile。
• 安装不再整机无响应，vmstat 1 的 si/so 不再持续为高值。
• dsh --version 正常输出，dsh web 的 RSS 稳定在数百 MB。
• 需要本地投递验证时，向 POST http://127.0.0.1:3080/api/dsh-im/delivery/messages 发请求，字段为 botId、targetId、text、format（只接受 plain 或 markdown），返回 {"sent": true} 表示受理。该接口只监听回环地址，无需鉴权。投递目标写在 /integrations/dsh-<渠道>/workspaces.json 的 deliveryTargets 里。

失败时看对应信号：swap 没生效看 swapon --show；安装被杀看 dmesg | grep -i oom；进程起不来先看 dsh --version。

边界

上述数字对应 Node v24.15.0 与当时的依赖树。1 GB 内存能跑指空闲状态，并发多个 subagent 或处理大文件输出仍可能触发换页。swap 只是缓冲，不是扩容，长期高负载应加内存。缓存目录可定期清理，但会话记录和产物属于数据，清理前确认是否保留。