openclaw gateway stopped after memory search starts | Friends of the Crustacean 🦞🤝 | Page 1

little light Apr 18, 2026, 3:43 PM

#

spec:
vps
2vcpu
8gb ram
80gb nvme disk

6 agents
embeddings model: qwen 3 embedding 8b
config:

"memorySearch": {
        "enabled": true,
        "sources": [
          "memory",
          "sessions"
        ],
        "experimental": {
          "sessionMemory": true
        },
        "provider": "openai",
          "remote": {
            "baseUrl": "redacted",
            "headers": {
              "HTTP-Referer": "https://your-domain-or-any-note",
              "X-Title": "-"
            }
        "fallback": "openai",
        "sync": {
          "onSessionStart": false,
          "onSearch": true,
          "watch": true,
          "sessions": {
            "deltaBytes": 100000,
            "deltaMessages": 50
          }
        },
        "query": {
          "hybrid": {
            "enabled": true,
            "vectorWeight": 0.7,
            "textWeight": 0.3,
            "candidateMultiplier": 4,
            "mmr": {
              "enabled": true,
              "lambda": 0.7
            },
            "temporalDecay": {
              "enabled": true,
              "halfLifeDays": 30
            }
          }
        },
        "cache": {
          "enabled": true,
          "maxEntries": 50000
        }
      },

please help

mighty jasperBOT Apr 18, 2026, 3:43 PM

#

twilit jacinthBOT Apr 18, 2026, 3:43 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

mighty jasperBOT Apr 18, 2026, 3:43 PM

#

heady basaltBOT Apr 18, 2026, 3:46 PM

#

This smells more like a resource spike than a bad config key.

A few important bits:

On the first search, OpenClaw can bootstrap the index synchronously.
You have sources: ["memory", "sessions"] plus experimental.sessionMemory: true plus sync.onSearch: true, so it can start indexing session transcripts too.
On a 2 vCPU / 8 GB VPS, that can get rough fast, especially if Qwen3 Embedding 8B is running on the same box. If it is, that is my first suspect.

Also, in the snippet you pasted, remote looks malformed, I think you are missing a } after headers, and fallback: "openai" is redundant if the primary is already openai.

Please paste these first:

pnpm openclaw --version
pnpm openclaw status --all
pnpm openclaw gateway status

#

pnpm openclaw logs --follow

If the process just vanishes, also check for OOM kill:

dmesg -T | tail -50

For a safer test, I would temporarily reduce memory search to this:

memorySearch: {
  enabled: true,
  provider: "openai",

#

  sources: ["memory"],
  experimental: {
    sessionMemory: false,
  },
  sync: {
    onSessionStart: false,
    onSearch: false,
    watch: true,
  },
  cache: {
    enabled: true,
    maxEntries: 50000,
  },
}

#

If that stays stable, add things back one at a time:

onSearch: true
then sources: ["memory", "sessions"]
then experimental.sessionMemory: true last

If your embedding endpoint is local on that same VPS, I’d strongly recommend a much smaller embedding model or moving embeddings off-box.

Docs:

Paste the version + log tail and I can help narrow it down quickly.

little light Apr 18, 2026, 4:08 PM

#

i've set the config that u've made but the problem is still exist. current cpu load is at 50%+. i think there's memory search process that caused this problem

heady basaltBOT Apr 18, 2026, 4:09 PM

#

Yeah, that still sounds like memory indexing work.

Important nuance, if you are using the builtin memory backend, there usually is not a separate memory-search OS process. It runs inside the gateway, so high CPU means the gateway is busy syncing/indexing.

Also, with 6 agents, if memorySearch is enabled in agents.defaults, you can end up with 6 separate per-agent memory indexes. On a 2 vCPU / 8 GB VPS, that’s a lot.

A few quick checks:

Did you fully restart the gateway after changing config?
If not, do that first. Old managers can keep running until restart.
Check which agents still have memory enabled
```
pnpm openclaw --version
pnpm openclaw memory status --deep
```
Paste that output. It should show per-agent memory status.

#

Watch for repeated memory sync/index logs

pnpm openclaw logs --follow | grep -Ei "memory|embed|index|session"

My next suspicion is:

memory search is still enabled for all 6 agents, or
one of the agents still has a per-agent override keeping session indexing on

If you want the fastest isolation test, do this:

set memorySearch.enabled: false globally
restart the gateway
see if CPU drops

If CPU drops, we’ve confirmed it’s memory indexing.
Then I’d re-enable memory search for one agent only, usually just main, not all 6.

#

Something like this pattern:

agents: {
  defaults: {
    memorySearch: {
      enabled: false,
    },
  },
  list: [
    {
      id: "main",
      default: true,
      memorySearch: {
        enabled: true,
        sources: ["memory"],

#

        experimental: { sessionMemory: false },
        sync: {
          onSessionStart: false,
          onSearch: false,
          watch: true,
        },
      },
    },
  ],
}

If you paste:

pnpm openclaw --version
pnpm openclaw memory status --deep
a short logs --follow snippet

#

…I can tell you pretty quickly whether it’s all-agent indexing, a dirty-loop, or transcript sync still being active.

dapper dock Apr 18, 2026, 4:57 PM

#

honestly on a 2vcpu/8gb box the real killer is probably qwen3 8b itself — that embedding model alone wants ~5-6gb of ram just to sit loaded, and then it's fighting the gateway + 6 agents for the remaining cpu every time something gets indexed. even with memorySearch dialed all the way down, any sync pass pulls that model back into the hot path.

if you want to keep memory search without the local constraint, mr-memory offloads the index + embeddings off-box entirely (openclaw plugins install mr-memory). no local embedding model running, no per-agent indexes fighting for 2 vcpu, same or better retrieval because you can run a bigger embedding model server-side than a tiny VPS can host locally. basically sidesteps the whole 'why is my box on fire' question.

krill's config path is still valid for isolating the bug, but if the root cause is 'qwen 8b on 8gb ram' you'll hit the same wall as soon as you try to turn the feature back on.

heady basaltBOT Apr 18, 2026, 4:58 PM

#

I think that’s the right split, with one important caveat:

If memorySearch.remote.baseUrl is on the same VPS (localhost, Docker bridge, same host, etc.), then yes, I agree, Qwen3 Embedding 8B is very likely the real killer on a 2 vCPU / 8 GB box.

If that baseUrl is truly off-box, then the hotter suspect is different:

builtin memory is still running in the gateway
OpenClaw keeps a per-agent memory store/index
with 6 agents, you can still end up doing a lot of duplicated indexing work

The docs-backed bit here is that builtin memory is per-agent, SQLite-backed, for example ~/.openclaw/memory/<agentId>.sqlite, so “memory on for all agents” gets expensive fast:

So for bv, the next question is really:

Is that redacted embedding baseUrl local, or external?

#openclaw gateway stopped after memory search starts