Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Gateway 100% CPU from startup, node.list 21-35s latency, 724MB memory (v2026.4.29, macOS ARM64) [4 comments, 5 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#75688•Fetched 2026-05-02 05:31:44
View on GitHub
Comments
4
Participants
5
Timeline
14
Reactions
6
Author
1yihui1yihui
Participants
1yihui1yihuiclawsweeper[bot]clawsweeper[bot]jarvis2k1jarvis2k1octalmageoctalmagesteipetesteipete
Timeline (top)
subscribed ×5commented ×4cross-referenced ×4closed ×1

The OpenClaw Gateway process consumes 100% CPU from the moment it starts and never drops. Memory usage is 724MB (peak 900MB). The node.list RPC call takes 21-35 seconds, and sessions.list takes 2-5 seconds. The Web UI (openclaw-control-ui) polls these endpoints every 2-3 seconds, causing request pileup and the Gateway being permanently stuck at 100% CPU.

Restarting the Gateway does not help — CPU hits 100% immediately after startup.

Root Cause

  1. node.list is the bottleneck — 21-35s per call, should be <100ms
  2. Not a state bloat issue — happens immediately after fresh restart
  3. Web UI is a victim, not the cause — requests pile up because each takes seconds
  4. Plugin initialization — feishu and llm-task each load 30 bundled runtime deps at startup
  5. Possibly related to MCP server startup — 7 MCP processes (3 Python + 4 Node) spawn during init

Code Example

OpenClaw: 2026.4.29 (a448042)
Node: v24.15.0
OS: macOS 26.4.1 (ARM64, Apple Silicon)
Gateway PID: 5276 → 9075 (after restart)
Plugins: feishu, llm-task, memclaw
MCP servers: mempalace (Python), context-mode (npx)

---

$ ps -p 9075 -o %cpu,comm
99.9%  node

---

22:16:25  node.list  21,005ms
22:16:49  node.list   4,228ms
22:17:51  node.list   5,281ms
22:18:21  node.list  14,074ms

---

22:15:41  sessions.list  3,183ms
22:16:09  sessions.list  4,840ms
22:16:12  sessions.list  2,990ms
22:16:24  sessions.list  3,011ms

---

Physical footprint: 724.0M
Physical footprint (peak): 900.8M

---

777 samples on main thread, all in:
  uv_run → uv__io_poll → uv__stream_io → OnUvRead → JS callback

---

183.240.229.82:443   — Feishu API (4 connections)
111.13.213.62:443    — XiaomiMimo API (2 connections)
localhost:18789      — WebSocket (Web UI)
6 unix sockets       — MCP server pipes

---

21:19:34  connected  b859...
21:25:56  disconnected  (6 minutes)
21:26:29  connected  48b3...  (33s later)
21:53:47  disconnected  (27 minutes)
21:53:48  connected  1329...  (1s later)
22:00:20  disconnected + immediate reconnect
RAW_BUFFERClick to expand / collapse

Summary

The OpenClaw Gateway process consumes 100% CPU from the moment it starts and never drops. Memory usage is 724MB (peak 900MB). The node.list RPC call takes 21-35 seconds, and sessions.list takes 2-5 seconds. The Web UI (openclaw-control-ui) polls these endpoints every 2-3 seconds, causing request pileup and the Gateway being permanently stuck at 100% CPU.

Restarting the Gateway does not help — CPU hits 100% immediately after startup.

Environment

OpenClaw: 2026.4.29 (a448042)
Node: v24.15.0
OS: macOS 26.4.1 (ARM64, Apple Silicon)
Gateway PID: 5276 → 9075 (after restart)
Plugins: feishu, llm-task, memclaw
MCP servers: mempalace (Python), context-mode (npx)

Evidence

CPU from startup

$ ps -p 9075 -o %cpu,comm
99.9%  node

node.list latency (right after restart)

22:16:25  node.list  21,005ms
22:16:49  node.list   4,228ms
22:17:51  node.list   5,281ms
22:18:21  node.list  14,074ms

sessions.list latency

22:15:41  sessions.list  3,183ms
22:16:09  sessions.list  4,840ms
22:16:12  sessions.list  2,990ms
22:16:24  sessions.list  3,011ms

Memory

Physical footprint: 724.0M
Physical footprint (peak): 900.8M

Gateway sample (CPU profile)

777 samples on main thread, all in:
  uv_run → uv__io_poll → uv__stream_io → OnUvRead → JS callback

Network connections

183.240.229.82:443   — Feishu API (4 connections)
111.13.213.62:443    — XiaomiMimo API (2 connections)
localhost:18789      — WebSocket (Web UI)
6 unix sockets       — MCP server pipes

Web UI reconnection pattern

21:19:34  connected  b859...
21:25:56  disconnected  (6 minutes)
21:26:29  connected  48b3...  (33s later)
21:53:47  disconnected  (27 minutes)
21:53:48  connected  1329...  (1s later)
22:00:20  disconnected + immediate reconnect

Analysis

  1. node.list is the bottleneck — 21-35s per call, should be <100ms
  2. Not a state bloat issue — happens immediately after fresh restart
  3. Web UI is a victim, not the cause — requests pile up because each takes seconds
  4. Plugin initialization — feishu and llm-task each load 30 bundled runtime deps at startup
  5. Possibly related to MCP server startup — 7 MCP processes (3 Python + 4 Node) spawn during init

Comparison with existing issues

  • #75289 / #75137: TUI processes at 100% CPU — different process (TUI vs Gateway)
  • #75621: Duplicate MCP children — we see 7 MCP processes but not confirmed duplicates
  • This issue: Gateway itself at 100% CPU from startup, with extreme node.list latency

Steps to reproduce

  1. Start Gateway: openclaw gateway start
  2. Open Web UI (openclaw-control-ui)
  3. Observe CPU immediately hits 100%
  4. Check gateway.log for node.list latency >20s

Expected behavior

Gateway should idle at <5% CPU when no active LLM requests are in flight.

extent analysis

TL;DR

The OpenClaw Gateway's high CPU usage can be mitigated by optimizing the node.list RPC call, potentially by improving plugin initialization or MCP server startup.

Guidance

  • Investigate the node.list RPC call to identify the cause of its high latency (21-35 seconds) and optimize it to reduce the response time.
  • Review plugin initialization, specifically the feishu and llm-task plugins, which load 30 bundled runtime dependencies at startup, to see if this contributes to the high CPU usage.
  • Examine the MCP server startup process, as the spawning of 7 MCP processes during initialization may be related to the issue.
  • Consider implementing a caching mechanism or optimizing the Web UI's polling frequency to reduce the load on the Gateway.

Example

No code snippet is provided as the issue does not specify a particular code block to modify.

Notes

The root cause of the issue is unclear, and further investigation is needed to determine the exact cause of the high CPU usage. The provided information suggests that the node.list RPC call and plugin initialization may be contributing factors.

Recommendation

Apply a workaround by optimizing the node.list RPC call and reviewing plugin initialization to reduce the load on the Gateway, as the root cause of the issue is not immediately clear.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Gateway should idle at <5% CPU when no active LLM requests are in flight.

#api#ssr#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Gateway 100% CPU from startup, node.list 21-35s latency, 724MB memory (v2026.4.29, macOS ARM64) [4 comments, 5 participants]