Skip to content

fix(nextjs): Fix memory leak #12335

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 4, 2024
Merged

fix(nextjs): Fix memory leak #12335

merged 1 commit into from
Jun 4, 2024

Conversation

lforst
Copy link
Contributor

@lforst lforst commented Jun 3, 2024

I honestly don't know why this fixes the memory leak.

I tried using

await new Promise(resolve => setTimeout(() => { resolve() }), 50))

and

await new Promise(resolve => { setTimeout(() => { resolve() }) }, 50))

but they both also leak.

Since this was just a nice to have, the best path moving forward is just to remove the artificial delay.

Probably fixes #12317

Copy link
Member

@AbhiPrasad AbhiPrasad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approve to unblock, but feels weird to me.

Could you share the memory profile? What was not getting GC'd? The request?

@@ -50,8 +50,6 @@ export function finishSpan(span: Span, res: ServerResponse): void {
export async function flushSafelyWithTimeout(): Promise<void> {
try {
DEBUG_BUILD && logger.log('Flushing events...');
// We give things that are currently stuck in event processors a tiny bit more time to finish before flushing. 50ms was chosen very unscientifically.
await new Promise(resolve => setTimeout(resolve, 50));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we instead call process.nextTick()? I guess that's not isomorphic though.

@lforst
Copy link
Contributor Author

lforst commented Jun 4, 2024

Could you share the memory profile? What was not getting GC'd? The request?

Sure thing!

I always profiled with 3 snapshots. (In the beginning, I used more to verify but got the same results):

  • Snapshot 1: Right after the next server starts listening
  • Snapshot 2: After bombarding a slow page with server components with ~7k requests
  • Snapshot 3: After bombarding the same page with another ~7k requests

This is what it looked like with the setTimeout call:

Screenshot 2024-06-04 at 09 37 05

This was after removing it:

Screenshot 2024-06-04 at 09 18 16

The important part is a) heap just growing b) Timeout constructor instances just increasing. I also manually GC'd after the 3rd snapshot and it didn't free the timeouts.

At first, I thought we were spreading globals into the timeout or promise but looking into the profile it seems like knownTimersById just keeps growing / isn't getting cleaned up? (https://github.com/nodejs/node/blob/d1f18b0bf16efbc1e54ba04a54735ce4683cb936/lib/timers.js#L87)

I can DM you the profile but I won't share it here cause I don't know what is contained in the profile since I have auth tokens hard-coded in the app.

@lforst lforst merged commit 58f75b6 into develop Jun 4, 2024
82 checks passed
@lforst lforst deleted the nextjs-fix-memory-leak branch June 4, 2024 07:39
billyvg pushed a commit that referenced this pull request Jun 10, 2024
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.

Memory leak in recent releases of Sentry (>= 8.6.0)
2 participants