У вас уже работают OpenClaw Gateway и stdio MCP, но в продакшене видно медленный рост числа дочерних процессов, рост RSS или редкие OOM, и непонятно — править конфигурацию или менять архитектуру. Статья дополняет разбор handshake MCP stdio/HTTP и зависаний и наблюдаемость Gateway в продакшене: сначала семь правил границ, затем таблица stdio и HTTP, шестишаговый runbook reclaim и ограничения нагрузки, заметки про systemd/Docker; в конце — ссылки на раздел OpenClaw и сценарии вычислений.
Для stdio MCP рукопожатие, зависания, отказ в доступе — сначала статья про handshake; белые списки и политика инструментов — белые списки MCP; проверки здоровья, логи, откат — наблюдаемость. Здесь только: Gateway уже стабильно принимает сессии, но дочерние процессы и кривые памяти неприемлемы — как управлять по слоям.
Первое рукопожатие не удалось: транспорт MCP и пути к исполняемым файлам ниже по цепочке; здесь не раскрывается.
Токен / scope и gateway closed (1000): отдельная статья про closed(1000), а не правки скриптов reclaim.
Чисто политика безопасности: изменения dmPolicy / networkPolicy — в статью про усиление.
Gateway не поднимается / not ready: порты, память, порядок compose — статья про not ready.
Таймауты бэкенда модели на уровне приложения: можно параллелить с MCP, но причина может быть в маршрутизации.
Разовые утечки из багов стороннего MCP: нужен фикс upstream или фиксация версии; reclaim лишь смягчает.
«Очистка» как панацея: жёсткие kill без уровней воды и журнала версий скрывают настоящие утечки.
В обсуждениях open source stdio MCP как дочерние процессы Gateway при долгих сессиях могут раздувать пул вместе с сессиями; поведение меняется между релизами. В эксплуатации стоит закрепить «допустимый потолок процессов + политику reclaim» в runbook, а не надеяться на умолчания. Сначала модель изоляция сессий → ожидаемое накопление, затем таблица.
Пересечение со статьёй про handshake: при сбоях в логах ошибки соединения/handshake; типичные сигналы здесь — монотонный рост числа процессов, ступенчатый рост памяти, OOM по фиксированному ритму. При разборе проверьте родство Gateway и MCP (ps / pstree в контейнере), чтобы не считать бэкенды моделей или каналы за MCP.
Если крутится несколько цепочек инструментов (локальные скрипты и постоянные агенты на удалённом Mac), нарисуйте топологию: где Gateway, где тяжёлый MCP. Запас памяти на узле Gateway ограничивает параллельные stdio-сессии. Ёмкость и доступ: тарифы аренды и требования сети из справочного центра.
Для наблюдаемости соберите минимум три ряда: число процессов, RSS Gateway и MCP, QPS вызовов инструментов и число сессий. Без измерения по сессиям не отличить пик нагрузки от отсутствия reclaim. Согласуйте поля логов с наблюдаемостью, иначе дежурство сводится к перезапуску наугад.
Частая ошибка: «много детей = нужен HTTP». Если инструменты очень лёгкие и параллелизм низкий, чаще виноваты не закрытые сессии или блокирующий исполняемый файл ниже по цепочке; сначала сжать жизненный цикл на клиенте, потом оценивать миграцию транспорта.
stdio запускает MCP-сервер как дочерний процесс, тесно связанный с жизненным циклом Gateway; HTTP ближе к отдельной конечной точке, с иными путями масштабирования и проверок. Таблица помогает выбрать «дальше крутить stdio» или «перейти на HTTP».
| Измерение | stdio MCP | HTTP MCP |
|---|---|---|
| Связь процессов | Дети следуют модели Gateway/сессий; накопление заметно | Часто отдельный процесс, Gateway — клиент |
| Горизонтальное масштабирование | Часто нужно масштабировать Gateway или ограничивать сессии | Можно реплицировать только сервис MCP |
| Проверки здоровья | Логи Gateway и таблица процессов | HTTP-пробы и отдельный SLO |
| Радиус поражения | Проблемы детей тормозят Gateway на том же хосте | Лучше изоляция, но лишний сетевой hop |
| Когда уместно | Лёгкие инструменты, низкая параллельность, доверенный хост | Тяжёлые инструменты, высокая нагрузка, свой релизный цикл |
«Управление» — не бесконечное железо, а договор по кривым процессов и памяти: сверх договора — ограничение, reclaim или смена транспорта.
Если в stdio/HTTP handshake конфигурация уже проверена, а красная линия по памяти не уходит, включайте «переход на HTTP» в архитектурный обзор, а не бесконечно увеличивайте хост.
Порядок: «сначала доказательства, потом ограничение, в конце архитектура». Поля логов как в наблюдаемости, без слепых kill.
Базовая линия: при стабильной нагрузке записать число процессов, RSS, версию Gateway и пакетов MCP в журнал изменений.
Пики и утечки: пики обычно связаны с параллельными сессиями; монотонный рост похож на отсутствие reclaim или зависший downstream — снимайте стеки.
Сжать параллелизм и таймауты: в пределах конфигурации снизить параллельные вызовы инструментов и укоротить простой; смотреть на кривые.
Плановый reclaim: в окне обслуживания — rolling-рестарт Gateway или изоляция узла, сначала drain сессий.
Контейнеры и systemd: убедиться, что переменные окружения попадают в реальную среду (частая ловушка: daemon и интерактивная оболочка).
Оценка миграции на 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), затем rolling-рестарт, чтобы не получить «конфиг как будто применён, процессы на старых значениях».
В публичных issue сообщали, что дочерние stdio MCP не возвращаются при смене сессии; в эксплуатации периодический reclaim + учёт версий — временная мера, пока не будет фикса upstream. Не полагайтесь долго на недокументированный ручной kill.
При внешней оркестрации (systemd timer, k8s CronJob) для sidecar reclaim выровняйте пользователя Gateway, окружение и лимиты памяти cgroup — иначе дерево процессов в скрипте разойдётся с продакшеном. На маленьком одиночном узле сначала ужмите параллелизм и таймауты в рамках договора.
Каждое изменение reclaim или ограничения связывайте с номером релиза; поведение stdio может меняться между минорными версиями Gateway.
Службы systemd не наследуют интерактивный ~/.zshrc. В Docker Compose пути к MCP и монтирование только для чтения могут гонять детей в цикл перезапусков. Вместе с Docker в продакшене проверьте Environment=, WorkingDirectory=, именованные тома и digest образа.
Внимание: частый docker compose restart без кода выхода предыдущего запуска путает ошибку конфигурации с утечкой памяти.
Вместе со статьёй not ready: при нехватке памяти Gateway может не дойти до стабильной фазы MCP — сначала ресурсы и порядок запуска.
Ниже — типичные отправные точки; подгоняйте под свою нагрузку.
Сваливать Agent и Gateway на нестабильный узел с малым объёмом памяти — получить «двойную дрожь» цепочки инструментов и модели; наращивать железо без смены модели сессий — линейно раздувать стоимость. Для долгой онлайн-работы с предсказуемой вычислительной мощностью на macOS и запаса под экосистему OpenClaw облачная аренда Mac Mini от NodeMini с фиксированным SSH и ясными характеристиками часто выгоднее кустарных ноутбуков или перегруженных shared-хостов: тарифы и справочный центр по сети и доступу.
Зафиксируйте на одной странице договора «потолок stdio-сессий + политика reclaim + триггеры миграции на HTTP», чтобы разработка и SRE смотрели на одни метрики.
Для внешних разборов прикладывайте снимки процессов и выдержки из логов, чтобы отделить ошибку конфигурации от дефекта upstream.
Не обязательно. Отделите ожидаемый рост из-за изоляции сессий от накопления вроде утечки, сверьте RSS и версию Gateway; при необходимости обновитесь до исправленного релиза, а не только добавляйте cron.
Когда жизненный цикл дочерних процессов долго плохо согласуется с моделью сессий или запас памяти на узле остаётся недостаточным без масштабирования, HTTP MCP часто проще масштабировать и проверять независимо. Контекст — в разделе OpenClaw.
Сначала тарифы аренды для сравнения уровней, затем справочный центр по сети и доступу для таблицы ёмкости.