Bug: extremely high memory usage with `next dev`

budchirp commented 2 years ago

Verify canary release

[X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: android
  Arch: arm64
  Version: #2 SMP PREEMPT Fri Aug 5 15:52:33 AST 2022
Binaries:
  Node: 18.10.0
  npm: 8.19.2
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 13.0.3-canary.0
  eslint-config-next: 13.0.2
  react: 18.2.0
  react-dom: 18.2.0

What browser are you using? (if relevant)

Chrome Canary v109.0.5400.0 (Android)

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

The memory usage on the last next 13 (13.0.3-canary.0 and 13.0.2) releases are too high. next dev command uses about 1gb of ram. Next 12 is using about 300mb-500mb's of ram.

Screenshot_20221104-225938_Termux

Expected Behavior

next dev should use less ram.

Link to reproduction

.

To Reproduce

Create project with Next 13
Run next dev
Check the ram usage

remorses commented 2 years ago

Probably related to #42349, when I profiled memory half of the heap was strings and they were also increasing with each request

ariesclark commented 2 years ago

Issue still persists in 13.0.3-canary.1.

ariesclark commented 2 years ago

issue still persists in v13.0.3.

AlonHor commented 2 years ago

I also have this issue.

arthureberledev commented 2 years ago

Same for me. A couple of times a day i get this error. Restarting the dev server helps

budchirp commented 2 years ago

Same for me. A couple of times a day i get this error. Restarting the dev server helps

Restarting the server helps but it's annoying to restart the server everytime.

AlonHor commented 2 years ago

Yeah after the server crashes for JavaScript heap out of memory I just start up the server again, but it's inconvenient and annoying. Also it's taking a lot of memory usage while the app is running, so that's also very annoying since the app is functioning slower and compiling slower (by a lot).

arthureberledev commented 2 years ago

Same for me. A couple of times a day i get this error. Restarting the dev server helps

Don't misunderstand me, this was just meant as a temporarily fix. I also find it extremely annoying and i am worried that this might also happen in production...

AlonHor commented 2 years ago

Same for me. A couple of times a day i get this error. Restarting the dev server helps

Don't misunderstand me, this was just meant as a temporarily fix. I also find it extremely annoying and i am worried that this might also happen in production...

It'll probably not happen in production since its being compiled while building it and also it's a lot more optimized but yeah that's worrying.

remorses commented 2 years ago

For me it happens in production too, Next 12 was working well with 500 Mb of RAM, now it gets out of memory on the first page reload

adshodgson commented 2 years ago

Seems to constantly crash for me on Next13

Alexandredc commented 2 years ago

Same problem here ! If a page have lot of <Link>, Next prebuilt all of these pages resulting high memory consumption and slow down of the app.

AlonHor commented 2 years ago

Release 13.0.4 seemed to had fixed it for me. You can update by doing:

npm i next@13.0.4 # npm
# or
yarn add next@13.0.4 # yarn

on your current project. It shouldn't break stuff that's already working. Also try to eliminate some dependencies that you don't need or that have a lighter alternative.

Here's the release.

arthureberledev commented 2 years ago

I am on 13.0.4 and it still happened to me a couple of times today. This is the latest stack trace:

`<--- Last few GCs --->

[21540:000001D236F10AA0] 1498088 ms: Mark-sweep 4065.1 (4138.6) -> 4053.0 (4142.6) MB, 270.3 / 0.1 ms (average mu = 0.208, current mu = 0.056) allocation failure scavenge might not succeed
[21540:000001D236F10AA0] 1498502 ms: Mark-sweep 4069.0 (4142.6) -> 4056.9 (4146.6) MB, 396.8 / 0.1 ms (average mu = 0.115, current mu = 0.040) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 1: 00007FF62B780AAF v8::internal::CodeObjectRegistry::~CodeObjectRegistry+124015 2: 00007FF62B70C866 v8::internal::wasm::WasmCode::safepoint_table_offset+64182 3: 00007FF62B70D8E2 v8::internal::wasm::WasmCode::safepoint_table_offset+68402 4: 00007FF62C041CE4 v8::Isolate::ReportExternalAllocationLimitReached+116 5: 00007FF62C02C2AD v8::SharedArrayBuffer::Externalize+781 6: 00007FF62BECF88C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468 7: 00007FF62BECC9A4 v8::internal::Heap::CollectGarbage+4244 8: 00007FF62BECA320 v8::internal::Heap::AllocateExternalBackingStore+2000 9: 00007FF62BEE8030 v8::internal::FreeListManyCached::Reset+1408 10: 00007FF62BEE86E5 v8::internal::Factory::AllocateRaw+37 11: 00007FF62BEFA68E v8::internal::FactoryBase::AllocateRawArray+46 12: 00007FF62BEFD2CA v8::internal::FactoryBase::NewFixedArrayWithFiller+74 13: 00007FF62BEFD523 v8::internal::FactoryBase::NewFixedArrayWithMap+35 14: 00007FF62BD03B96 v8::internal::HashTable<v8::internal::NameDictionary,v8::internal::NameDictionaryShape>::EnsureCapacity+246 15: 00007FF62BD0193A v8::internal::Dictionary<v8::internal::NameDictionary,v8::internal::NameDictionaryShape>::Add+58 16: 00007FF62BD09B66 v8::internal::BaseNameDictionary<v8::internal::NameDictionary,v8::internal::NameDictionaryShape>::Add+118 17: 00007FF62BC16858 v8::internal::Runtime::GetObjectProperty+1720 18: 00007FF62C0CF9C1 v8::internal::SetupIsolateDelegate::SetupHeap+494417 19: 000001D23A365117 error Command failed with exit code 134.`

ariesclark commented 2 years ago

Release 13.0.4 seemed to had fixed it for me. You can update by doing:
npm i next@13.0.4 # npm
# or
yarn add next@13.0.4 # yarn
on your current project. It shouldn't break stuff that's already working. Also try to eliminate some dependencies that you don't need or that have a lighter alternative.

Here's the release.

13.0.4 does not resolve the memory issue for me, still have the random out of memory crashes in development, I haven't encountered any issues in production though.

AlonHor commented 2 years ago

Release 13.0.4 seemed to had fixed it for me. You can update by doing:
npm i next@13.0.4 # npm
# or
yarn add next@13.0.4 # yarn
on your current project. It shouldn't break stuff that's already working. Also try to eliminate some dependencies that you don't need or that have a lighter alternative. Here's the release.
13.0.4 does not resolve the memory issue for me, still have the random out of memory crashes in development, I haven't encountered any issues in production though.

I know that Material UI has some issues with NextJS 13, so if you're using that I'd suggest removing it and using a lighter solution. If you're not using it, try to remove dependencies that may cause an extremely high memory usage. Of course it's NextJS 13's fault, but removing dependencies might improve it.

LorenzoBloedow commented 2 years ago

This is still happening to me on next 13.0.4

andrewdoro commented 2 years ago

still happening to me

adshodgson commented 2 years ago

Still bugging for me also 13.0.4

Mistwell commented 2 years ago

Still happening 13.0.5-canary.4

pedronauck commented 2 years ago

Still happening for me on 13.0.4 also 😕

AlonHor commented 2 years ago

For me in 13.0.4 the memory is still high but improved since 13.0.3

budchirp commented 2 years ago

Still not fixed in 13.0.5

soylemezali42 commented 2 years ago

still happening 13.0.6-canary.2

OtisTemler commented 2 years ago

Same issue here with latest canary. Just after start 2,5GB of ram for a rather simple app, and after a bit of time = crash.

Nefcanto commented 1 year ago

This is an extremely annoying problem. We are a website design agency. We migrated one of our websites to Next.js 13 (13.0.5) and it's using more than 900MBs of RAM. The same site in ASP.NET Core Pages used less than 100 MBs.

Vercel, at least give us hints on how to debug this issue on our side.

m1nsuplee commented 1 year ago

The same problem happened to me.

I am using version 13.0.5, and the same problems have occurred frequently in previous versions.

aaronkchsu commented 1 year ago

same problem here, using the with apollo example from here https://github.com/vercel/next.js/tree/canary/examples/with-apollo

feedthejim commented 1 year ago

Hey folks, next.js team member here. I'm investigating this issue. Would anyone care to share with me privately their projects so I can investigate properly? Or a public repro?

Nefcanto commented 1 year ago

@feedthejim sure, I can create a public repo that works with a public API. I need some time though to create it. Maybe a day.

soylemezali42 commented 1 year ago

Hey folks, next.js team member here. I'm investigating this issue. Would anyone care to share with me privately their projects so I can investigate properly? Or a public repro?

I am going to send invitation..you can see the problem on the development branch.

feedthejim commented 1 year ago

thanks @soylemezali42, got the invite! Can you reach out to me on Twitter at @feedthejim so we can discuss how to set it up? I can't run the project without the env setup.

soylemezali42 commented 1 year ago

@feedthejim . I couldn't react out to you on Twitter. I have sent an email to hello@jimmyl.ai.

Nefcanto commented 1 year ago

@feedthejim I created a repo. It connects to our live API. I sent an invitation.

soylemezali42 commented 1 year ago

@Nefcanto. This commit probably is going to resolve the issue. pretech development commit

Nefcanto commented 1 year ago

@soylemezali42 thanks for notifying me, but no it does not. We did not complain about RAM usage during the development. I have 32 GB of RAM on my machine and I don't mind using even 5 GB for developing a Next.js website.

We complained about high RAM usage in the production environment. That commit only disables prefetch for development.

adshodgson commented 1 year ago

@Nefcanto. This commit probably is going to resolve the issue. pretech development commit

This may solve the memory issue for development though, which is causing the terminal to crash every 20-30 seconds, fingers crossed....

soylemezali42 commented 1 year ago

@Nefcanto. This commit probably is going to resolve the issue. pretech development commit

It didn't solve the problem. The issue is going on 13.0.7-canary.3 @feedthejim

adshodgson commented 1 year ago

@Nefcanto. This commit probably is going to resolve the issue. pretech development commit

It didn't solve the problem. The issue is going on 13.0.7-canary.3 @feedthejim

Me also, unfortunately ;(

feedthejim commented 1 year ago

hey, sorry I was busy investigating the issue!

Small update: I managed to identify the 3 main sources of memory leaks that I think are causing the crashes in dev so I'll work on fixing those quickly. This should help a lot hopefully.

Thanks @soylemezali42 for the test app, it was very very helpful 🙏.

feedthejim commented 1 year ago

Another update:

good news: I merged two fixes, so hopefully the next canary will help.
bad news: there's another memory leak that comes from Node itself which means that it's gonna be very hard to fix. I'm currently exploring how we could work around the issue.
bad news 2: i think I saw another memory leak linked to the edge runtime, so I'll have to investigate that too.

soylemezali42 commented 1 year ago

Another update:

good news: I merged two fixes, so hopefully the next canary will help.

bad news: there's another memory leak that comes from Node itself which means that it's gonna be very hard to fix. I'm currently exploring how we could work around the issue.

bad news 2: i think I saw another memory leak linked to the edge runtime, so I'll have to investigate that too.

I have tested the app with canary.4. Sure, there is some improvement on the development server. But, the app is still being crashed after some navigation on the pages. By the way, Thanks to the vercel team for the quick improvements and replies.

jesstelford commented 1 year ago

Adding our experience: We are seeing high memory usage in Production when run via node (next start), not the edge runtime.

This is still the case for 13.0.6, but we have not tested the canaries.

feedthejim commented 1 year ago

@soylemezali42 can you share a bit more details on the steps to repro with your repo? I was mainly testing it on the main page and doing some code modifications but what is exactly your workflow there? Things that would be useful:

how many navigations?
how long was your coding session?

@jesstelford thanks for the feedback, I will also investigate! Can you share more details as well? Do you see high but stable memory usage or does it leak and leads to crashes as well?

soylemezali42 commented 1 year ago

Hi @feedthejim. I have sent the credetentials to you for our project before. If you login with the user(you can use /api/register endpoint for authorization) , you will see navigations on the sidebar. Before you hadn't made impromevents the previous relaease for memory leaks, just one or two click was enough for the server crashing on this navigation links. We are currently implement post create feature to our system. What we do now(please see below for images), click create post button and then return drafts page(mywritings link) and navigate between pages(clicking feed, open publications or archives page etc.). If those are not sufficient for you, I can record the steps.

how many navigations? : I am not sure.Maybe it is more than 10.
how long was your coding session?: Under one minute

Create Post

Observe Crated Post On Drafts

feedthejim commented 1 year ago

So I just added something to relaunch the dev server whenever the memory gets too high... not a great fix but should help whilst I investigate.

There's also one thing I forgot to mention to you folks: one thing that might unblock you is also to increase the max heap usable with NODE_OPTIONS=--max-old-space-size=6144. If you have more than enough ram available like me, that should also help (temporarily)

feedthejim commented 1 year ago

The fix has landed on canary, please try it out and let me know if it makes your experience better.

We're still blocked on the Node.js bug and we're investigating how we can solve this but I don't expect that it'll be fixed fast :/ .

adshodgson commented 1 year ago

@feedthejim Thanks, it seems a combination of solutions you've implemented has eased the amount of crashing that occurs in the latest Canary release.

One thing that i find really strange is how slow my app takes to compile when switching pages during development mode,

Could this be some cause of the prefetching of links you described earlier? I can sometimes wait in excess of 8-10 seconds for a page change. (Turbo unfortunately doesn't work for me)

In Production, this is a non-existent issue - lightning fast, but developing is really tedious at the moment.

soylemezali42 commented 1 year ago

I have tested the app with last canary release. We aren't writing "yarn dev" any more .(heyy). We have lost our productivity on the server after migrating 13. We were expecting to see magics that announced on everywhere. Working on this server now is just so frustrating.

feedthejim commented 1 year ago

Thanks for the feedback @adshodgson @soylemezali42!

@adshodgson I will surface that to the team... that's definitely something on my mind as well.

@soylemezali42 can you expand more on not using yarn dev anymore? Also, is your other feedback related to page slowness?

vercel / next.js