docs: add a section on measuring memory at runtime - #98291
Open
xabierlameiro wants to merge 3 commits into
Open
Conversation
The memory guide covers next dev and next build only. This adds the four rules that make a runtime measurement reliable (warm process, forced GC before each sample, rss and arrayBuffers, one route per process) and points to memlab and next-leak, external tools of the same kind as the Chrome DevTools link already in the guide.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Improving Documentation
prettierwith the repo config on the changed file; no changes.What this adds
The memory guide covers
next devandnext build: dependency count, Webpackoptions,
--experimental-debug-memory-usage, heap profiles and snapshots. Itsays nothing about measuring a production server that grows over hours, which
is the case most memory issues in the tracker describe.
This adds a short section, "Measure memory at runtime", after "Analyze a
snapshot of the heap". It lists the four things that make a runtime measurement
reliable (sample from a warm process, force a GC before every sample, watch
rssandarrayBuffersas well asheapUsed, measure one route per freshprocess) and explains what a snapshot diff between an early and a late sample
gives you.
Why the method matters
Forcing a GC before each sample is what separates retention from garbage that
hasn't been collected yet, and it's also what makes some real leaks look fine
if you only watch
heapUsed: part of the retention lives outside the V8 heap.Without warm-up, the first requests to a route (compilation, caches) read as
growth. Without one route per process, growth can't be attributed. These are
the mistakes I made before I got a reliable measurement, and none of them are
written down in the guide today.
External tools
The last paragraph names memlab and next-leak as tools that automate this
loop. They're external, the same way the Chrome DevTools link already in this
guide is. I wrote next-leak; if naming it is a problem, I'm happy to drop that
paragraph, the method stands on its own.