你已能跑通 OpenClaw Gateway 与 stdio MCP，却在生产里看到子进程数缓慢上涨、RSS 爬升或偶发 OOM，不确定该调配置还是改架构。本文与 MCP stdio/HTTP 握手与僵死排查、Gateway 生产观测 分工：先用七条清单划清边界，再用一张stdio vs HTTP 运维对照表收敛取舍，最后给出六步回收与限流 Runbook，并说明 systemd/Docker 下环境变量与重启策略；文末链到 OpenClaw 专栏 与算力场景。
stdio MCP 的连接握手、僵死、权限拒绝优先对照 握手与僵死篇；白名单与工具策略对照 MCP 工具链白名单篇；健康检查、日志与升级回滚对照 观测篇。本篇只回答：当 Gateway 已能稳定接受会话，但子进程与内存曲线仍不可接受时，如何分层治理。
首次握手失败：先看 MCP 传输与下游可执行路径，不在此篇展开。
Token / scope 与 gateway closed (1000)：对照 closed(1000) 专文，而非改回收脚本。
纯安全策略：dmPolicy / networkPolicy 变更走安全加固篇。
Gateway 起不来 / not ready：先看启动就绪排错篇的端口、内存与 compose 顺序。
业务层模型后端超时：与 MCP 子进程治理可并行，但根因可能在模型路由而非进程表。
一次性泄漏的第三方 MCP 实现 Bug：需要上游修复或版本钉死；回收只能缓解。
把「清理」当万能药：无水位与版本台账的强杀会掩盖真实泄漏点。
在开源社区讨论中，stdio MCP 作为 Gateway 子进程长期会话时，可能出现子进程池随会话增长而膨胀的现象；具体行为随版本而变，运维上应把「可接受的进程上限 + 回收策略」写进值班手册，而不是依赖默认。下面先建立会话隔离 → 堆积可预期的心智模型，再进入对照表。
与握手篇的交叉点在于：握手失败会在日志里表现为连接/握手错误；而本篇处理的典型信号是进程数单调增、内存曲线台阶式上升、在固定周期后被 OOM killer 命中。排障时先确认 Gateway 主进程与 MCP 子进程的父子关系（ps / 容器内 pstree），避免把模型后端或通道进程误算进 MCP。
若你同时运行多套工具链（本地脚本 + 远程 Mac 上的常驻 Agent），建议把「哪台机器跑 Gateway、哪台跑重 MCP」画成拓扑：Gateway 所在节点的内存余量直接决定你能承载多少并发 stdio 会话。更多算力与接入说明可结合 算力订购 与帮助中心网络要求。
从观测角度，建议至少采集三类序列：进程数、Gateway 与 MCP 的 RSS、工具调用 QPS 与会话数。没有会话维度，你很难判断「堆积」是业务高峰还是回收缺失。与 观测篇 中的日志字段对齐后，再在面板里做同比/环比，否则值班只能凭感觉重启。
另一个常见误区是把「子进程多」直接等同于「要换 HTTP」。若工具本身极轻、并发极低，问题更可能出在会话未关闭或下游可执行文件阻塞；此时应先收紧客户端侧会话生命周期，再评估传输层迁移成本。
stdio 传输把 MCP 服务器作为子进程紧耦合在 Gateway 生命周期内；HTTP 传输则更像独立服务端点，伸缩与健康检查路径不同。下面用一张表帮助评审「继续优化 stdio」还是「上 HTTP」。
| 维度 | stdio MCP | HTTP MCP |
|---|---|---|
| 进程耦合 | 子进程随 Gateway / 会话模型变化，易出现堆积感知 | 通常独立进程，Gateway 只做客户端 |
| 水平扩容 | 常需同步扩容 Gateway 或限流会话 | 可对 MCP 服务单独副本扩容 |
| 健康检查 | 依赖 Gateway 日志与进程表 | 可用 HTTP 探针与独立 SLO |
| 故障爆炸半径 | 子进程问题易拖慢同机 Gateway | 隔离更好，但多一跳网络 |
| 适用场景 | 工具轻量、并发低、同机可信 | 工具重、并发高、需独立发布节奏 |
「治理」不是无限堆机器，而是给进程与内存曲线设合同：超过合同就限流、回收或换传输方式。
若团队已在 stdio/HTTP 握手篇 验证过配置无误，但仍长期在内存红线附近徘徊，应把「HTTP 化」纳入架构评审，而不是无限调高主机规格掩盖问题。
下列步骤强调「先取证、再限流、最后才换架构」：与 观测篇 的日志字段对齐，避免无日志强杀。
建立基线：记录稳定负载下的进程数、RSS、Gateway 版本与 MCP 包版本，写入变更台账。
区分尖峰与泄漏：尖峰多与并发会话相关；单调增更像未回收或下游挂起，需抓线程/子进程栈信息。
收紧并发与超时：在配置允许范围内下调并行工具调用、缩短空闲超时，观察曲线是否随会话下降。
计划内回收：在维护窗滚动重启 Gateway 或隔离节点，先 drain 会话再操作。
容器与 systemd：核对环境变量是否注入到实际运行环境（daemon 与交互 shell 不一致是高频坑）。
评估 HTTP 迁移：对重型 MCP 或需独立扩缩的服务，落独立部署与健康检查，Gateway 侧改 HTTP 传输。
ps -axo pid,ppid,rss,comm | grep -E 'openclaw|mcp|node' | head -n 50 # 容器内可配合 pstree -p 1 观察父子关系
提示：修改 openclaw.json 后务必执行站内文档推荐的校验命令路径（如 config:validate / doctor），再滚动重启，避免「配置以为生效、进程仍用旧值」。
在 GitHub Issue 类公开讨论中，曾有「stdio MCP 子进程在会话轮换时未回收」的报告，运维上应把周期回收 + 版本跟踪当作临时缓解，同时跟进上游修复。不要长期依赖未文档化的手工 kill。
若你们使用外部编排（如 systemd timer 或 k8s CronJob）做旁路回收，务必保证与 Gateway 的启动用户、环境变量、cgroup 内存上限一致；否则会出现「回收脚本看到的进程树」与「真实服务进程树」不一致，排障时互相甩锅。对小型单节点部署，更推荐先通过配置把并发与超时压到合同内，再考虑旁路复杂度。
最后，把每次回收或限流变更关联到发布版本号：stdio 行为可能随 Gateway 小版本变化，缺少版本对齐的曲线对比没有统计意义。
systemd 服务不会继承交互式 shell 的 ~/.zshrc；Docker Compose 场景下 MCP 可执行文件路径与卷只读权限也会导致子进程反复拉起。请在对照 Docker 生产篇 的前提下检查：Environment=、WorkingDirectory=、命名卷与镜像 digest。
注意：频繁 docker compose restart 而不看前一次退出码，容易把「配置错误」误判成「内存泄漏」。
与 not ready 排错篇 联动：内存不足时 Gateway 可能尚未进入稳定 MCP 会话阶段，此时应先解决资源与启动顺序，再谈子进程治理。
下列数字为工程常用起点，以你们实际负载为准。
把 Agent 与 Gateway 全堆在不稳定的小内存节点上，会出现「工具链与模型双重抖动」；纯靠加机器而不改会话模型，成本会线性失控。对需要长期在线、可预期算力跑 macOS 侧构建或自动化、又要给 OpenClaw 周边工具链留足余量的团队，NodeMini 的 Mac Mini 云端租赁在固定 SSH 与清晰规格上通常优于拼凑笔记本或超卖共享机；可先查看 租赁价格说明，并在 帮助中心 核对网络与接入要求。
落地时建议把「stdio 会话上限 + 回收策略 + HTTP 迁移触发条件」写进同一页运维合同，研发与 SRE 用同一套指标评审。
若需对外复盘，可附上进程快照与日志片段，便于区分「配置误配」与「上游缺陷」。
不一定。先区分会话隔离带来的预期增长与泄漏式堆积，再结合 RSS 曲线与 Gateway 版本核对已知问题；必要时升级到修复版本而非只加 cron。
当子进程生命周期长期难以与会话模型对齐、或节点内存余量持续不足且无法水平扩容时，HTTP MCP 通常更易做独立伸缩与健康检查。更多工具链背景可见 OpenClaw 分类。