Skip to content

fix(#791): eliminate spTxIndex, drop singleton subpaths to slash startup memory#796

Closed
Kpa-clawbot wants to merge 3 commits intomasterfrom
fix/subpath-memory-791-v2
Closed

fix(#791): eliminate spTxIndex, drop singleton subpaths to slash startup memory#796
Kpa-clawbot wants to merge 3 commits intomasterfrom
fix/subpath-memory-791-v2

Conversation

@Kpa-clawbot
Copy link
Copy Markdown
Owner

Summary

Eliminate the two largest heap consumers in the subpath index to prevent OOM during startup on databases with many unique subpaths.

Changes

  1. Eliminate spTxIndex entirely — The map[string][]*StoreTx that stored per-subpath transmission pointer slices has been removed. The only read site (GetSubpathDetail) now scans packets on the fly, which is acceptable since it's only called on drill-down, not listing.

  2. Drop singleton subpath entries — After the initial index build, entries with count==1 are pruned. At scale, 60–70% of subpath keys are singletons that add no analytical value. Newly-seen singletons during incremental ingest remain until the next restart.

  3. Update memory-accounting — Remove perSubpathEntryBytes constant and O(path²) subpath cost calculations from estimateStoreTxBytes / estimateStoreTxBytesTypical. Update comments to reflect the changes.

  4. Add startup log line[store] Subpath index: kept N/M entries (dropped K singletons)

Estimated Memory Savings

Scale spTxIndex elimination Singleton drop Total saved
1.26M subpaths ~120 MB ~60 MB ~180 MB
3.4M subpaths ~280 MB ~150 MB ~430 MB

Tests

  • SQL fallback (GetSubpathDetail) returns correct match counts (existing + updated test)
  • Singleton drop preserves all count≥2 entries (TestSubpathSingletonDrop)
  • Empty DB loads successfully with no subpaths (TestSubpathEmptyDB)
  • Memory estimation tests updated for removed subpath costs

This replaces the approach in draft PR #716.

Closes #791

you added 3 commits April 19, 2026 00:03
Remove the spTxIndex map (map[string][]*StoreTx) that stored per-subpath
transmission pointer slices. This was the largest single heap consumer
during startup on databases with many unique subpaths.

Replace the only read site (GetSubpathDetail) with an O(packets) scan
that matches subpaths on the fly. This is acceptable because the
endpoint is only called on drill-down, not listing.

Remove all write sites (addTxToSubpathIndexFull, removeTxFromSubpathIndexFull)
and collapse them back into the simpler addTxToSubpathIndex/removeTxFromSubpathIndex
functions that only maintain counts.
After the initial subpath index build, iterate and delete all entries
where count==1. At scale, 60-70% of subpath keys are singletons that
appear only once — they add no analytical value and consume significant
memory (each entry is a string key + map bucket overhead).

Newly-seen singletons during incremental ingest will remain in the
index until the next restart. This is acceptable since singleton
subpaths are noise for ranking/display purposes.

Add a startup log line showing how many entries were kept vs dropped.
Remove perSubpathEntryBytes constant and all O(path²) subpath cost
calculations from estimateStoreTxBytes and estimateStoreTxBytesTypical.
Update comments to note that spTxIndex was eliminated in #791 and
singleton subpath entries are dropped from spIndex.
@Kpa-clawbot
Copy link
Copy Markdown
Owner Author

Closing in favor of #799, which targets the actual heap dominator.

Profiling staging revealed the OOM in #791 is driven by JSON-decoded ResolvedPath []*string slices held on every StoreTx/StoreObs (~33% of heap, ~1 GB extrapolated to the #791 user's database). The spTxIndex removal in this PR addresses ~1.5% of heap and would also regress the Subpath Detail analytics drill-down.

See #799 for the proposed refactor (membership index + on-demand API decode), test plan, and acceptance criteria.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Existing SQLite database prevents CoreScope from becoming reachable, empty DB starts immediately

1 participant