Local iii engine grows to ~3.7GB RSS with file_based storage and contributes to desktop OOMs

[vittoroliveira-dev]

Summary

I’ve hit 4 OOM situations on my Ubuntu desktop while using AgentMemory.

The last one was bad enough that the machine powered off, so I lost the chance to capture the exact systemd-oomd / cgroup details for that event. After rebooting, I ran a few controlled tests and could not reproduce another full OOM yet, but the memory pattern is very reproducible:

• start AgentMemory;
• local iii quickly grows to multiple GB of RSS;
• available memory drops a lot;
• stop AgentMemory;
• the machine becomes stable again under the same or heavier workload.

Environment

OS: Ubuntu Desktop
RAM: 32 GB
Swap: 8 GB
@agentmemory/agentmemory: 0.9.27
iii: 0.11.2
Runtime: local process, not Docker
Storage: file_based
Data dir: ~/.agentmemory/data
Data files: ~584

The data dir includes files like:

mem:obs
mem:index:bm25
mem:graph:*

What happens

When AgentMemory is started, the local iii process climbs fast:

~1.8 GB RSS shortly after start
~2.7 GB RSS a few minutes later
~3.6–3.7 GB RSS after settling

The memory is mostly anonymous RSS:

RssAnon: ~3.5 GB
RssFile: ~17 MB
VmSwap: 0
oom_score: ~860

So this is not Linux page cache. It is real process memory.

On my desktop this matters a lot, because I also usually have Chrome, browser MCPs, Playwright MCP, Open Design MCP, and other dev tools running. With iii sitting around 3.5–3.7 GB RSS, the system has much less room before systemd-oomd starts killing scopes or the desktop becomes unstable.

A/B test

I stopped AgentMemory with:

npx @agentmemory/agentmemory stop

After stopping it:

• iii disappeared;
• available memory jumped back up;
• I opened more Chrome tabs and pushed the workload harder than before;
• no new OOM happened;
• no new systemd-oomd event appeared;
• memory PSI stayed at 0.00.

Then I started AgentMemory again.

After restart:

• iii came back as the biggest individual process;
• RSS went back into multi-GB territory;
• available memory dropped again;
• the system returned to the same high-risk state.

The last full OOM powered off the machine, so I don’t have the perfect final log line for that one. But from the tests after reboot, iii is the one component I can toggle that consistently changes the machine from stable to memory-constrained.

Why this looks related to existing issues

This looks very close to the class of problem described in:

• Feature Request: Add eviction timer + env toggle for mem::evict (parity with mem::auto-forget) #480 — mem::evict exists but is not called automatically, observations keep growing, BM25 + graph are loaded into RAM.
• Architecture: Migrate BM25 & Graph Search from In-Memory to SQLite #309 — BM25 and Graph Search are in-memory and can cause RAM exhaustion.
• session-start / subagent-start hooks block agent startup for up to 5s on slow/unreachable REST #221 — hook/subprocess activity can amplify load and previously led to high RSS / OOM behavior.

My case is slightly different because it is local desktop usage on the latest AgentMemory version I’m using, with file_based storage.

Expected behavior

For desktop usage, I would not expect the local iii engine to sit around 3.5–3.7 GB RSS with a relatively small local data directory.

What would help

A few practical things would make this much easier to run safely on a workstation:

• a supported maintenance / eviction command;
• automatic eviction for observations;
• a memory or cache cap for local desktop usage;
• a way to limit BM25 / graph index memory;
• startup logs showing how many observations, graph nodes, graph edges, and BM25 entries were loaded;

Right now the workaround is basically to stop AgentMemory when the desktop starts getting unstable. That works, but it defeats the point of having it running during normal development.