Yago consumes much RAM

[anotherdoesnm]

not quite an issue and i can life with it but seems Yago consumes very much RAM compared to all other services on my host

Yago version: 0.0.32

[D4rk4]

Thank you for the report. I checked the screenshot and the v0.0.32 source. I also collected memory accounting from our own yagoseek.dev production node running v0.0.34. The production measurements below are not from the reporter host and do not establish the cause on that system.

Confirmed from this report:

• The screenshot shows approximately 185 MiB for yago-node and 38 MiB for yago-crawler.
• The report identifies the installed version as v0.0.32.
• The single snapshot provides no time series, available-memory value, cgroup pressure event, OOM event, or anonymous/file-backed split. It therefore does not by itself show a leak or even memory pressure.

Confirmed from the v0.0.32 source:

• The node opens sharded bbolt storage and initializes the RWI word filters by walking the posting keys at startup.
• bbolt uses memory-mapped files, so Linux can include resident index pages in process RSS.

Observed only on our v0.0.34 production node:

• Approximately 970 MiB was anonymous/private memory, while 17-28 GiB was file-backed resident/cache accounting, depending on the kernel counter.
• The host still had approximately 28 GiB available, swap was unused, and the service cgroup recorded no high, max, oom, or oom_kill events.

Those production observations demonstrate that mapped bbolt/Bleve pages and startup warm-up explain the large apparent RSS on our workload. They are only a plausible mechanism for the reported v0.0.32 instance; without accounting from that host, its 185 MiB cannot be attributed to the same cause. Linux accounting definitions are documented at https://www.kernel.org/doc/html/latest/filesystems/proc.html#proc-pid-status.

No Go heap leak is confirmed at this point. There is still useful follow-up work for Yago: bound or avoid the full RWI filter warm-up and expose anonymous versus file-backed memory in diagnostics. No memory-behavior correction has been released, so I am leaving this issue open.

If the affected host is actually losing available memory over time, the minimum useful evidence is:

1. memory.current, memory.events, and memory.stat from the service cgroup.
2. /proc/<pid>/smaps_rollup for yago-node.
3. The same counters at two times, together with the Yago data-directory size and the exact yago-node --version output.

That will distinguish reclaimable mapped index pages from private memory growth. Thank you for the actionable report.

[D4rk4]

v0.0.35 is now published and deployed on yagoseek.dev. The release adds process-memory attribution for diagnosis; it does not claim a memory-behavior correction or establish the cause on the reporter's host. This issue remains open.

The counters are in Admin → Overview → Memory diagnostics and refresh with the Overview snapshot every 15 seconds:

• Process resident set (RSS) — all pages currently resident for the yago-node process.
• Anonymous RSS — resident anonymous/private pages. This includes Go-managed memory, stacks, and other anonymous allocations, but is not a Go-heap-only value.
• File-backed RSS — resident file mappings and file-backed pages. Index and vault mappings can contribute here. The counter does not identify an individual file and a large value does not by itself establish unreclaimable memory pressure.
• Shared-memory RSS — resident shared-memory pages.
• Go heap objects — bytes occupied by allocated Go heap objects, including objects that are live or not yet reclaimed by the runtime.

On Linux, the first four readings follow RSS = anonymous + file-backed + shared-memory. Go heap objects is contained within process memory and must not be added to RSS. These are counters for yago-node only; they do not include yago-crawler, browser child processes, the host, or the complete service cgroup.

For a concrete scope check, at 2026-08-09 17:04 UTC our own v0.0.35 production node reported:

• RSS: 26,804,140 kB
• anonymous RSS: 499,680 kB
• file-backed RSS: 26,304,460 kB
• shared-memory RSS: 0 kB

The split matched RSS exactly. That host had 29,663,240 kB available and its node cgroup still recorded zero high, max, oom, and oom_kill events. These are measurements from our production workload, not from the reporter's system, and they do not attribute the reporter's original approximately 185 MiB observation to the same mechanism.

The report originally states v0.0.32; we do not know which version is running there now. If memory remains a concern after installing v0.0.35, please provide the exact current yago-node --version output and two or more Overview memory snapshots over time, together with the service cgroup's memory.current and memory.events. That is sufficient to distinguish anonymous growth from resident file mappings and actual memory pressure.

Thank you again for the actionable report.

[anotherdoesnm]

Just updated to 0.0.35 (container 359f2b525ea7), here is my values

docker stats shows now 172MB for node and 60M for crawler