Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
The Linux OOM killer occasionally terminates my Gateway during two to four simultaneous conversations. The machine has 16 GB of RAM, and memory looks available after the crash. I already limited concurrent agent runs, so what else can create the peak?
A run-count limit is not a memory limit. Each active run can hold context, tool output, images, and response buffers. Browser processes, media tools, MCP servers, and local models also use memory outside the Gateway’s Node heap.
The post-crash reading can be misleading because the allocation spike disappears when the kernel kills a process. A systemd or container cgroup may also have a lower limit than the host.
Inspect the kernel event and the service limit around the failure:
journalctl -k --since "10 minutes ago" --no-pager | grep -Ei 'oom|out of memory|killed process|memory cgroup'
free -h
swapon --show
systemctl show openclaw-gateway.service -p MemoryCurrent -p MemoryPeak -p MemoryMax -p MemoryHigh
ps -eo pid,ppid,rss,%mem,cmd --sort=-rss | head -20
Temporarily reducing concurrency can confirm a peak-load problem. Also inspect large context and tool results, reduce oversized media, and avoid running a large local model on the same host while testing. If the kernel names a memory cgroup, the cgroup limit matters more than free -h.