Skip to content

Update getting-started.md#7

Open
mrsharpoblunto wants to merge 1 commit into
mainfrom
mrsharpoblunto-patch-1
Open

Update getting-started.md#7
mrsharpoblunto wants to merge 1 commit into
mainfrom
mrsharpoblunto-patch-1

Conversation

@mrsharpoblunto

Copy link
Copy Markdown
Contributor

Wording/spelling

Wording/spelling
@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 8, 2022
@facebook-github-bot

Copy link
Copy Markdown
Contributor

@mrsharpoblunto has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

meta-codesync Bot pushed a commit that referenced this pull request Jul 8, 2026
…ed load-ceiling hints

Summary:
A full server-snapshot sweep (feedback below) confirmed that the auto-scaled load ceiling shipped earlier helped but did not remove the dominant friction: finding a capture that actually loads. The table snapshots the heaviest apps, which are exactly the densest heaps, so every top-per-app capture in the 550–2100 MB band was refused for exceeding the node/edge ceiling — and finding a loadable one meant a manual "attempt load → read the refused counts → hand-compute density → re-query for a smaller file → retry" loop. This addresses that directly and closes the feedback loop the sweep is supposed to drive.

- New `memlab_snapshot_header` tool — peek a `.heapsnapshot`'s header (node/edge counts, capture time, file size) WITHOUT loading it. It skips the dominator-tree pass entirely, so unlike a full `memlab_load_snapshot` it can never wedge or OOM the server. It reports whether the capture fits under the current auto-scaled ceiling, the app's node/edge density, and — when it doesn't fit — the estimated largest same-app capture that WOULD fit. So instead of attempting an oversized load and retrying, you peek a candidate and pick a loadable snapshot in one step. It reuses the same `file_path` resolution as the loader (local path / `manifold://` / bare filename) and the Manifold download is cached, so a follow-up real load doesn't re-fetch.

- Density hint on the load-ceiling refusal — when `memlab_load_snapshot` refuses a capture for exceeding the count ceiling, it now derives this capture's nodes-per-MB and edges-per-MB and states the file size the ceiling corresponds to for this app ("roughly a ≤N MB capture — pick a smaller snapshot"), turning the hand-computed density math into one number in the error itself, and points at `memlab_snapshot_header` for checking candidates. The estimate (`estimateMaxLoadableMB`) takes the min of the node-bound and edge-bound sizes, so edge-dense heaps — where the edge ceiling binds first — are estimated correctly.

- Sweep skill now files tool feedback (closing the loop). The `nest-server-memlab-sweep` skill/command had no step telling the agent to capture memlab tool friction and report it, so the sweep→feedback→improvement loop only ever closed when a human asked. Added a human-gated Step 7: track friction during the run and, at the end, summarize it for the user; draft an improvement diff only on explicit request. It explicitly does NOT let the sweep autonomously modify the memlab plugin/MCP server — that would be a banned self-modifying pattern (claude-templates security Hard Rule #7); this step is reporting, and any change is a normal human-reviewed diff.

- Docs: README and MCP_SKILL document `memlab_snapshot_header` (peek-before-load triage).

Not done this round: the dominator-tree-free interning screen mode (still needs validation against real multi-GB snapshots that can't be built offline) remains deferred. And `memlab_snapshot_header` still downloads the full file before reading the header; a Manifold range-GET of just the header prefix would make batch candidate triage cheap, but `manifold get` range support is unverified, so that optimization is deferred.

Differential Revision: D110955369

fbshipit-source-id: 6ffd35769d7c4d71a4b187cbbfbc7e5fd0fd8d04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants