search

vercel / next.js

The React Framework
https://nextjs.org
MIT License
121.81k stars 26.05k forks source link

appDir + RSC: "The server is running out of memory, restarting to free up memory" #46756

Closed timfee closed 9 months ago

timfee commented 1 year ago

Verify canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:37 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 19.7.0
      npm: 9.5.0
      Yarn: N/A
      pnpm: 7.28.0
    Relevant packages:
      next: 13.2.4-canary.1
      eslint-config-next: 13.2.3
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue

https://github.com/timfee/www/tree/meet2hire1

To Reproduce

Observe the video, where the node process gradually exceeds 4GB after about 4 minutes of using the app. During this time, I refreshed/reloaded several times (appDir/RSC pages), as well as triggered hot reloading in the browser.

This has been happing since 13.1.x and continues.

I couldn't find any obvious leaks in the sever-side code (you can see some CPU / memory heap dumps in the root directory of the repro repository), e.g.: https://github.com/timfee/www/blob/4a813e95eb866e0fee39795f38e461427bee9795/vscode-profile-2023-03-03-13-51-06.heapsnapshot

I'm happy to do additional repro steps/troubleshooting on my end!

Here's me intentionally trying to overwork it:

https://user-images.githubusercontent.com/3246342/222865281-1b1be172-b777-4466-bd2b-062b1b46947b.mov

Describe the Bug

After 5 mins of using the app (interacting and hot reloading), the server consumes > 4 GB and I get the message:

The server is running out of memory, restarting to free up memory.

Expected Behavior

This either wouldn't happen, or Next would inform me if there was something egregiously wrong.

Which browser are you using? (if relevant)

110.0.5481.177 (Official Build) (arm64)

How are you deploying your application? (if relevant)

next dev

NEXT-1353

timfee commented 1 year ago

If this helps:

warn  - Fast Refresh had to perform a full reload when (app-client)/./app/meet/picker.tsx changed. Read more: https://nextjs.org/docs/messages/fast-refresh-reload

<--- Last few GCs --->

[18442:0x138008000]   824166 ms: Mark-Compact (reduce) 1524.2 (1547.6) -> 1524.2 (1547.1) MB, 107.2 / 0.0 ms  (average mu = 0.160, current mu = 0.000) allocation failure; GC in old space requested
[18442:0x138008000]   824272 ms: Mark-Compact (reduce) 1524.2 (1547.1) -> 1524.1 (1547.1) MB, 105.6 / 0.0 ms  (average mu = 0.085, current mu = 0.000) last resort; GC in old space requested

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10442cc64 node::Abort() [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 2: 0x10442df30 node::ModifyCodeGenerationFromStrings(v8::Local<v8::Context>, v8::Local<v8::Value>, bool) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 3: 0x1045888b0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 4: 0x10458885c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 5: 0x104723b34 v8::internal::Heap::GarbageCollectionReasonToString(v8::internal::GarbageCollectionReason) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 6: 0x104726090 v8::internal::Heap::ComputeMutatorUtilization(char const*, double, double) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 7: 0x10472449c v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 8: 0x10472259c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
 9: 0x104726b70 v8::internal::Heap::CollectAllAvailableGarbage(v8::internal::GarbageCollectionReason) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
10: 0x1047198a8 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
11: 0x1046fd638 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
12: 0x1046f1d94 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
13: 0x1046f1c7c v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
14: 0x104996ef0 v8::internal::MaybeHandle<v8::internal::OrderedHashMap> v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Allocate<v8::internal::Isolate>(v8::internal::Isolate*, int, v8::internal::AllocationType) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
15: 0x104996a94 v8::internal::MaybeHandle<v8::internal::OrderedHashMap> v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash<v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::OrderedHashMap>, int) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
16: 0x104996a3c v8::internal::MaybeHandle<v8::internal::OrderedHashMap> v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::EnsureGrowable<v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::OrderedHashMap>) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
17: 0x104a57fb4 v8::internal::Runtime_MapGrow(int, unsigned long*, v8::internal::Isolate*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
18: 0x1042872ac Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/opt/homebrew/Cellar/node/19.7.0/bin/node]
19: 0x104258824 Builtins_MapPrototypeSet [/opt/homebrew/Cellar/node/19.7.0/bin/node]
20: 0x10c328f64
21: 0x10c35f9c8
22: 0x10c329620
23: 0x10c5a3174
24: 0x10c329620
25: 0x10c5a3174
26: 0x10c329620
27: 0x10c35f0bc
28: 0x10c329620
29: 0x10c5a3174
30: 0x10c329620
31: 0x10c35ea20
32: 0x10beb39e4
33: 0x10c329620
34: 0x10c35f0bc
35: 0x10c329620
36: 0x10c5a3174
37: 0x10c329620
38: 0x10c088ae8
39: 0x10c329620
40: 0x10be976c8
41: 0x104204064 Builtins_InterpreterEntryTrampoline [/opt/homebrew/Cellar/node/19.7.0/bin/node]
42: 0x10c0f55b4
43: 0x10c329620
44: 0x10beb6b0c
45: 0x10beb7374
46: 0x10c61a828
47: 0x1042dae38 Builtins_PromiseFulfillReactionJob [/opt/homebrew/Cellar/node/19.7.0/bin/node]
48: 0x10422a834 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/19.7.0/bin/node]
49: 0x1042023c4 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/19.7.0/bin/node]
50: 0x1046a9388 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
51: 0x1046a9ad0 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
52: 0x1046cc5a8 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
53: 0x1046cc3d8 v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
54: 0x104364af4 node::InternalCallbackScope::Close() [/opt/homebrew/Cellar/node/19.7.0/bin/node]
55: 0x104365004 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
56: 0x1043805ac node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
57: 0x104433b04 node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
58: 0x1044352d4 node::fs::AfterNoArgs(uv_fs_s*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
59: 0x104426f9c node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
60: 0x106e16ff0 uv__work_done [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
61: 0x106e1a3c4 uv__async_io [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
62: 0x106e2a1e0 uv__io_poll [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
63: 0x106e1a7bc uv_run [/opt/homebrew/Cellar/libuv/1.44.2/lib/libuv.1.dylib]
64: 0x1043658b8 node::SpinEventLoopInternal(node::Environment*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
65: 0x10446f044 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
66: 0x10446edc4 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node/19.7.0/bin/node]
67: 0x1043f42a8 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResultImpl const*) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
68: 0x1043f442c node::Start(int, char**) [/opt/homebrew/Cellar/node/19.7.0/bin/node]
69: 0x1a4ab7e50 start [/usr/lib/dyld]

I tried:

It seems particularly bad in active development, e.g. lots of HMRs vs when I'm just using the app.

lucasfrotam commented 1 year ago

Same issue here

mamlzy commented 1 year ago

i'm facing this same issue too

ruskyvisky commented 1 year ago

same issue :(

n1developer-ubt commented 1 year ago

same issue here, MacOS (13.2.1 (22D68))

OfirYC commented 1 year ago

same stuff happening here

nocodehummel commented 1 year ago

Same here (Next 13.2.4). Do you have suggestions how I could investigate the problem and/or get more log information? Would it be possible to see which code is being recompiled?

event - compiled successfully in 1 ms (11834 modules)
wait  - compiling...
event - compiled successfully in 1 ms (11834 modules)
wait  - compiling...
event - compiled successfully in 0 ms (11834 modules)
wait  - compiling...
event - compiled successfully in 2 ms (11834 modules)
wait  - compiling...
event - compiled successfully in 1 ms (11834 modules)
wait  - compiling...
event - compiled successfully in 1 ms (11834 modules)
wait  - compiling...
event - compiled successfully in 1 ms (11834 modules)
warn  - The server is running out of memory, restarting to free up memory.
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
warn  - You have enabled experimental feature (appDir) in next.config.js.
info  - Thank you for testing `appDir` please leave your feedback at https://nextjs.link/app-feedback
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.

event - compiled client and server successfully in 2.8s (262 modules)
mujud commented 1 year ago

I was able to mitigate the issue on my side by changing my icon lib(react icons) import to import only the specific files.

from:

import { FaBeer } from 'react-icons/fa';

to:

import { FaBeer } from "@react-icons/all-files/fa/FaBeer";

This reduced the issue substantially. I do still notice my ram usage grow but not enough to cause a restart or slow down the compiles.

nocodehummel commented 1 year ago

@mujud, thanks for the suggestion, I do not use react-icons, but you gave me a hint in the right direction.

Next.js v13.2.4 compiler is really slow, looping and running out of memory in development. This was caused by the MUI icon import. I changed the import as below.

import Fast from '@mui/icons-material/Fast';
import { NotResponsive } from '@mui/icons-material';

After changing this 20x in the sources the development environment is running fine. I do no longer notice the compiler.

eunseokOh commented 1 year ago

same issue..

danmartens commented 1 year ago

I'm not sure what initiates it, but sometimes a page will just keep making requests to the server as if I'm editing files related to that page. The response seems to always be empty. When this starts happening, the memory usage of the node process just keeps increasing until it eventually crashes with the out of memory message.

After navigating to a page and waiting a few seconds, Next made over 200 requests in a row and the memory usage increased by about 1.5Gb without me editing any files or interacting with the page. Here's what the network tab looks like:

Screenshot 2023-03-24 at 4 20 30 PM

masterkain commented 1 year ago

from:

import { FaBeer } from 'react-icons/fa';

to:

import { FaBeer } from "@react-icons/all-files/fa/FaBeer";

I have the same memory issue, what package do you have installed? I have an import issue with this solution

import { TbBrandLastfm } from '@react-icons/all-files/tb/TbBrandLastfm'

instead of

import { TbBrandLastfm } from 'react-icons/tb'

but it cannot be found.

nocodehummel commented 1 year ago

Did you try import TbBrandLastfm from 'react-icons/tb/TbBrandLastfm'?

masterkain commented 1 year ago

Did you try import TbBrandLastfm from 'react-icons/tb/TbBrandLastfm'?

tried @react-icons/tb/TbBrandLastfm and react-icons/tb/TbBrandLastfm also but still the same result

"react-icons": "^4.8.0",

nocodehummel commented 1 year ago

For me it had to be default import without curly quotes (not a named import).

masterkain commented 1 year ago

Has to be default import without curly quotes (not a named import).

yes sorry I did not paste the import but it's the same without curly braces, I'm looking inside the package now and see what I can do.. thanks for the reply

masterkain commented 1 year ago

you probably have npm install @react-icons/all-files --save, I think I have npm install react-icons --save

nocodehummel commented 1 year ago

I am using the MUI icons library.

masterkain commented 1 year ago

managed to get it going with @react-icons/all-files package (instead of react-icons) and changing set given the one I choose previously is not in this package, will keep an eye on memory, thanks

Marviel commented 1 year ago

Having the same issue. Also using the MUI Icons library but am unsure if root cause.

timfee commented 1 year ago

FWIW, my original issue didn’t use mui so might be something else too

itegmark commented 1 year ago

I have the same issue, but no MUI icons or react icons in my code though. Got long sheet of this: 

wait  - compiling...
event - compiled successfully in 1 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 2 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 2 ms (2199 modules)
[next-auth][warn][EXPERIMENTAL_API]
`getServerSession` is used in a React Server Component.
https://next-auth.js.org/configuration/nextjs#getServerSession}
https://next-auth.js.org/warnings#EXPERIMENTAL_API
wait  - compiling...
event - compiled successfully in 2 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 1 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 2 ms (2199 modules)
[next-auth][warn][EXPERIMENTAL_API]
`getServerSession` is used in a React Server Component.
https://next-auth.js.org/configuration/nextjs#getServerSession}
https://next-auth.js.org/warnings#EXPERIMENTAL_API
wait  - compiling...
event - compiled successfully in 12 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 3 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 1 ms (2199 modules)
[next-auth][warn][EXPERIMENTAL_API]
`getServerSession` is used in a React Server Component.
https://next-auth.js.org/configuration/nextjs#getServerSession}
https://next-auth.js.org/warnings#EXPERIMENTAL_API
wait  - compiling...
event - compiled successfully in 1 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 1 ms (2199 modules)
wait  - compiling...
event - compiled successfully in 1 ms (2199 modules)
[next-auth][warn][EXPERIMENTAL_API]
`getServerSession` is used in a React Server Component.
https://next-auth.js.org/configuration/nextjs#getServerSession}
https://next-auth.js.org/warnings#EXPERIMENTAL_API
rudiwawa commented 1 year ago

like infinite loop

wait  - compiling...
event - compiled successfully in 1 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 1 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 1 ms (1044 modules)
[next-auth][warn][EXPERIMENTAL_API] 
`getServerSession` is used in a React Server Component. 
https://next-auth.js.org/configuration/nextjs#getServerSession} 
https://next-auth.js.org/warnings#EXPERIMENTAL_API
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
[next-auth][warn][EXPERIMENTAL_API] 
`getServerSession` is used in a React Server Component. 
https://next-auth.js.org/configuration/nextjs#getServerSession} 
https://next-auth.js.org/warnings#EXPERIMENTAL_API
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
[next-auth][warn][EXPERIMENTAL_API] 
`getServerSession` is used in a React Server Component. 
https://next-auth.js.org/configuration/nextjs#getServerSession} 
https://next-auth.js.org/warnings#EXPERIMENTAL_API
wait  - compiling...
event - compiled successfully in 1 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
wait  - compiling...
event - compiled successfully in 0 ms (1044 modules)
[next-auth][warn][EXPERIMENTAL_API] 
`getServerSession` is used in a React Server Component. 
https://next-auth.js.org/configuration/nextjs#getServerSession} 
https://next-auth.js.org/warnings#EXPERIMENTAL_API
warn  - The server is running out of memory, restarting to free up memory.
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
warn  - You have enabled experimental feature (appDir) in next.config.js.
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.

info  - Thank you for testing `appDir` please leave your feedback at https://nextjs.link/app-feedback
event - compiled client and server successfully in 643 ms (323 modules)
wait  - compiling...
event - compiled client and server successfully in 144 ms (323 modules)
wait  - compiling /_error (client and server)...

I used react-icons I have also experimented with changing the next config.

modularizeImports: {
    'react-icons': {
      transform: 'react-icons/{{member}}',
    },
  },

It remains the same, there is no change.

itegmark commented 1 year ago

It seems that they've just fixed it in v13.2.5-canary.20 few hours ago. You can update it with npm install next@canary

rudiwawa commented 1 year ago

Sure, it seems like the issue has been resolved in the latest update v13.2.5-canary.20. Thank you very much, Next.js. Certainly, I will notify you again if there are any new issues. Update OOM still exist

danmartens commented 1 year ago

I'm not seeing 100s of requests when using v13.2.5-canary.20, but the server is still running out of memory after a few minutes of use.

jrysana commented 1 year ago

Same here as @danmartens noted above.

Running on v13.2.5-canary.20, the memory issue seems somewhat relieved as dev is overall snappier and takes longer to run out of memory and restart. No absurd bursts of requests seen so far, but it still is consistently running out of memory and restarting every few minutes, and pages are still compiling much slower than similar pages in the Next v <= 12 apps I've worked on.

This has only really been a noticeable issue a few weeks into the project, so it seems related to either 13.1/13.2 or a scaling issue with the size of a project and certain files within

Marviel commented 1 year ago

Just had it crash for me as well. v13.2.5-canary.20 No runaway requests, but still OOM issues.

danmartens commented 1 year ago

I added a comment to the app directory feedback thread to hopefully get more visibility on this: https://github.com/vercel/next.js/discussions/41745?sort=new#discussioncomment-5470560

Amar-89 commented 1 year ago

Next 13.2.4 is really unstable. I am not even sure if I should progress with the project or I should just use Next 12.

Same here as @danmartens noted above.

Running on v13.2.5-canary.20, the memory issue seems somewhat relieved as dev is overall snappier and takes longer to run out of memory and restart. No absurd bursts of requests seen so far, but it still is consistently running out of memory and restarting every few minutes, and pages are still compiling much slower than similar pages in the Next v <= 12 apps I've worked on.

This has only really been a noticeable issue a few weeks into the project, so it seems related to either 13.1/13.2 or a scaling issue with the size of a project and certain files within

I started a new project for my company with 13.2.4 couple of days ago and facing the same issue. Also I am new to NextJS (mostly a Vite user), and I am not really sure if I should proceed with Next 13. Should I just use Next 12 to build my app?

timfee commented 1 year ago

I started a new project for my company with 13.2.4 couple of days ago and facing the same issue. Also I am new to NextJS (mostly a Vite user), and I am not really sure if I should proceed with Next 13. Should I just use Next 12 to build my app?

Are you experiencing the instabilities with Next 13 + appDir? In cases where I've used Next 13 without experimental features, I haven't noticed the same stability issues.

Amar-89 commented 1 year ago

Yes with the appDir. I am gonna try without it now to see if that works.

danielgroen commented 1 year ago

also check out this video guys: https://www.youtube.com/watch?v=zwQs4wXr9Bg

This probaply won't solve your problems, however this will fix the infinite data fetching loop.

danmartens commented 1 year ago

For me the infinite fetches aren't related to data fetching from our code. It happens even on routes with no fetch() calls and the origin of the requests is an internal Next.js function. Anecdotally, it does seem to perform much better with the latest canary release (v13.2.5-canary.30).

iRevolutionDev commented 1 year ago

For me they are the same problems, except that I am using MUI and the routes are extremely slow, but this only happens in dev mode with the hot reload, running in production mode the site is performatico, my computer is not bad to be so slow to compile and perform the hotreload besides it has a lot of ram memory and it only increases until it exceeds the ram memory limit, that is, maybe MUI is causing memory leaks, or even the routes in dev mode

jgb-solutions commented 1 year ago

For me it was MUI with Next 13's app directory. I got it improved drastically by importing named exports directly from @mui/material and @mui/icons-material.

import { Box } from "@mui/material"
import { Home as HomeIcon } from "@mui/icons-material"

But the truth is that it was still slow. Just better.

Hope it helps someone.

Update

I found the solution for MUI/Next 13 slowness. Update your next.config.js with a modularizedImports key like this:

const nextConfig = {
  modularizeImports: {
    "@mui/material": {
      transform: "@mui/material/{{member}}"
    },
    "@mui/icons-material": {
      transform: "@mui/icons-material/{{member}}"
    }
  }
}

I saw compilation speed that was ranging from 5 to 10 seconds before to now down to about 200-300 milliseconds. I'm happy now. And of course update your MUI imports in your code as well.

ltk99 commented 1 year ago

my proplem same that, i dont know, when deploy production env, it can happen again

stocke777 commented 1 year ago

facing same issue, none of the fixes are working

depak379mandal commented 1 year ago

Same here +1

nicholasgriffintn commented 1 year ago

Same on the latest version, during E2E tests on local M1 (with 32GB of RAM), if this is happening locally than I imagine it's also going to happen in production...

Not changed much from the pages route, outside of simply moving the app to the new directory, so wouldn't expect this (no infinite loops, I have checked logs and we're not using MUI, all custom stuffs, just a lot of requests as is the nature of E2E, but this is only 5-15 requests per second max...).

Seems like memory is getting filled a lot by next and GC is unable to clean up.

Stack Trace

``` <--- Last few GCs ---> web-app-web:dev: web-app-web:dev: [98218:0x7fcd3e84d000] 4333536 ms: Scavenge 4066.0 (4114.7) -> 4065.4 (4136.7) MB, 10.2 / 0.0 ms (average mu = 0.819, current mu = 0.462) allocation failure; web-app-web:dev: [98218:0x7fcd3e84d000] 4334287 ms: Mark-sweep (reduce) 4088.4 (4153.8) -> 4084.7 (4130.8) MB, 370.7 / 0.0 ms (+ 345.6 ms in 85 steps since start of marking, biggest step 21.3 ms, walltime since start of marking 752 ms) (average mu = 0.703, current mu = web-app-web:dev: web-app-web:dev: <--- JS stacktrace ---> web-app-web:dev: web-app-web:dev: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory web-app-web:dev: 1: 0x1027fbfb5 node::Abort() (.cold.1) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 2: 0x10127ca29 node::Abort() [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 3: 0x10127cc0e node::OOMErrorHandler(char const*, bool) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 4: 0x10140bcc3 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 5: 0x1015d4975 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 6: 0x1015d3352 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 7: 0x1015c568a v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 8: 0x1015c6005 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 9: 0x1015a7c4a v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 10: 0x1015a1669 v8::internal::MaybeHandle v8::internal::FactoryBase::NewRawStringWithMap(int, v8::internal::Map, v8::internal::AllocationType) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 11: 0x1016f9f3c v8::internal::JsonParser::MakeString(v8::internal::JsonString const&, v8::internal::Handle) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 12: 0x1016f85ec v8::internal::JsonParser::ParseJsonValue() [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 13: 0x1016f7951 v8::internal::JsonParser::Parse(v8::internal::Isolate*, v8::internal::Handle, v8::internal::Handle) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 14: 0x101498866 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 15: 0x101dd3eb9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/nicholas.griffin/.nvm/versions/node/v18.15.0/bin/node] web-app-web:dev: 16: 0x106d60ddd ```

brianfryer commented 1 year ago

Same same, but no MUI or react-icons.

lucasalima commented 1 year ago

I'm facing the same issue "next": "^13.4.1".

rmagon commented 1 year ago

Facing the same issue with "next": "^13.3.1" as well as "next": "^13.4.1". Removed the react-icons library completely but did not help, we're also not using MUI etc.

siyasangab commented 1 year ago

Was facing the same issue on ^13.3.4 but I upgraded to ^13.4.2 and it seems to be fixed

event - compiled client and server successfully in 748 ms (1442 modules)
[next-auth][warn][EXPERIMENTAL_API] 
`getServerSession` is used in a React Server Component.
https://next-auth.js.org/configuration/nextjs#getServerSession}
https://next-auth.js.org/warnings#EXPERIMENTAL_API
[next-auth][warn][DEBUG_ENABLED] 
https://next-auth.js.org/warnings#debug_enabled
wait  - compiling /(clients)/my-requests/[id]/page (client and server)...
event - compiled successfully in 291 ms (638 modules)
[next-auth][warn][EXPERIMENTAL_API] 
`getServerSession` is used in a React Server Component.
https://next-auth.js.org/configuration/nextjs#getServerSession}
https://next-auth.js.org/warnings#EXPERIMENTAL_API
[next-auth][warn][DEBUG_ENABLED] 
https://next-auth.js.org/warnings#debug_enabled
wait  - compiling /favicon.ico/route (client and server)...
wait  - compiling /api/auth/[...nextauth] (client and server)...
event - compiled successfully in 116 ms (683 modules)
event - compiled successfully (699 modules)
wait  - compiling /page (client and server)...
[next-auth][warn][DEBUG_ENABLED]
https://next-auth.js.org/warnings#debug_enabled
warn  - The server is running out of memory, restarting to free up memory.
error - Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:217:20) {
  errno: -4077,
  code: 'ECONNRESET',
  syscall: 'read'
}
[next-auth][warn][EXPERIMENTAL_API]
`getServerSession` is used in a React Server Component.
https://next-auth.js.org/configuration/nextjs#getServerSession}
https://next-auth.js.org/warnings#EXPERIMENTAL_API
[next-auth][warn][DEBUG_ENABLED]
https://next-auth.js.org/warnings#debug_enabled
holicreact commented 1 year ago

i use "^13.4.2-canary.4"
It's better than before, but I still use a lot of memory, and I frequently request and restart it

masterkain commented 1 year ago

this is really driving me nuts, how can we profile or find the root cause?

tomul commented 1 year ago

Same issue with: "next": "^13.4.2", "react": "^18.2.0", node v18.16.0 with 32GB of RAM on Ubuntu 20.04.6 LTS. Not using react-icons or MUI.

iduuck commented 1 year ago

For everyone struggling: I have moved to @tabler/react-icons with import modularization. This fixed the issue for me.

LordSeb commented 1 year ago

@mujud, thanks for the suggestion, I do not use react-icons, but you gave me a hint in the right direction.

Next.js v13.2.4 compiler is really slow, looping and running out of memory in development. This was caused by the MUI icon import. I changed the import as below.

import Fast from '@mui/icons-material/Fast';
import { NotResponsive } from '@mui/icons-material';

After changing this 20x in the sources the development environment is running fine. I do no longer notice the compiler.

I can confirm I had the same issue - I was using icon like this: import HomeOutlinedIcon from '@mui/icons-material/HomeOutlined' I refactored it (with tons of different things) to: import { HomeOutlinedIcon } from '@mui/icons-material'

It didn't showed any error, the icon was there so I was thinking its working just fine and just later on I released its super slow and couldn't figure out how I broke it... so confusing, please work on a fix.

=> This only unstuck the app to be frozen/broken. But the memory leak issue is still happening. Probably because of Global Styles - styled-components or next.js localFont or some behind a scenes way how Next.js 13 is including styles to the root layout.tsx component. What you guys think?

Maxafangsco commented 1 year ago

I am having the same problem with v13.4.4