Version: memtrace 0.7.25 (npm latest)
While reducing steady-state memory on a large monorepo, I found two environment variables referenced inside the memcore-server binary that I can't find documented anywhere:
MEMTRACE_RAM_TIERMEMTRACE_HOT_HORIZON_DAYS
Via strings they appear adjacent to a horizon_episode_id concept and the HNSW/structural rebuild env vars, with a nearby path crates/memcore-grpc/src/real_engine/mod.rs. That suggests HOT_HORIZON_DAYS bounds how much recent history is kept "hot," and RAM_TIER selects a memory profile — but neither is in memtrace --help, the bundled README.md, or memtrace.io.
Context / goal: a ~50k-node repo indexed on one machine, with multiple git worktrees sharing one MemDB (shared data-dir + per-worktree watches). I'd like to (a) lower resident engine memory and (b) bound how much commit history is loaded/kept hot, ideally without a destructive wipe + full replay.
Could you document, for both vars:
- Valid values + default (is
RAM_TIER an enum like low/balanced/high, or a number? is HOT_HORIZON_DAYS an integer day count?).
- Units and exact effect.
- Side effects — does a smaller
HOT_HORIZON_DAYS only evict episodes from RAM, or drop them from the on-disk graph? Does changing either require a reindex/re-embed?
- Interaction with the
>=512MB startup auto-index skip and the background HNSW/structural rebuild.
Happy to test values if you can point me at safe ranges. Thanks — memtrace has been great for this project.
Version: memtrace 0.7.25 (npm
latest)While reducing steady-state memory on a large monorepo, I found two environment variables referenced inside the
memcore-serverbinary that I can't find documented anywhere:MEMTRACE_RAM_TIERMEMTRACE_HOT_HORIZON_DAYSVia
stringsthey appear adjacent to ahorizon_episode_idconcept and the HNSW/structural rebuild env vars, with a nearby pathcrates/memcore-grpc/src/real_engine/mod.rs. That suggestsHOT_HORIZON_DAYSbounds how much recent history is kept "hot," andRAM_TIERselects a memory profile — but neither is inmemtrace --help, the bundledREADME.md, or memtrace.io.Context / goal: a ~50k-node repo indexed on one machine, with multiple git worktrees sharing one MemDB (shared data-dir + per-worktree watches). I'd like to (a) lower resident engine memory and (b) bound how much commit history is loaded/kept hot, ideally without a destructive wipe + full replay.
Could you document, for both vars:
RAM_TIERan enum like low/balanced/high, or a number? isHOT_HORIZON_DAYSan integer day count?).HOT_HORIZON_DAYSonly evict episodes from RAM, or drop them from the on-disk graph? Does changing either require a reindex/re-embed?>=512MBstartup auto-index skip and the background HNSW/structural rebuild.Happy to test values if you can point me at safe ranges. Thanks — memtrace has been great for this project.