Skip to content
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

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

Closed
1 task done
timfee opened this issue Mar 4, 2023 · 97 comments
Closed
1 task done
Labels
area: app App directory (appDir: true) bug Issue was opened via the bug report template. linear: next Confirmed issue that is tracked by the Next.js team.

Comments

@timfee
Copy link
Contributor

timfee commented Mar 4, 2023

Verify canary release

  • I verified that the issue exists in the latest Next.js 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:

repro-small.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 timfee added the bug Issue was opened via the bug report template. label Mar 4, 2023
@timfee
Copy link
Contributor Author

timfee commented Mar 5, 2023

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:

  • removing all swcPlugins
  • refactoring code to simplify re-renders

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

@balazsorban44 balazsorban44 added area: app App directory (appDir: true) type: needs investigation labels Mar 7, 2023
@balazsorban44 balazsorban44 changed the title appDir + RSC: "The server is running out of memory, restarting to free up memory" [NEXT-790] appDir + RSC: "The server is running out of memory, restarting to free up memory" Mar 7, 2023
@lucasfrotam

This comment was marked as off-topic.

@mamlzy

This comment was marked as off-topic.

@ruskyvisky

This comment was marked as off-topic.

@n1developer-ubt

This comment was marked as off-topic.

@OfirYC

This comment was marked as off-topic.

@nocodehummel
Copy link

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
Copy link

mujud commented Mar 21, 2023

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
Copy link

nocodehummel commented Mar 21, 2023

@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
Copy link

same issue..

@danmartens
Copy link

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
Copy link

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
Copy link

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

@masterkain
Copy link

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
Copy link

nocodehummel commented Mar 26, 2023

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

@masterkain
Copy link

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
Copy link

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

@nocodehummel
Copy link

I am using the MUI icons library.

@masterkain
Copy link

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
Copy link

Marviel commented Mar 27, 2023

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

@timfee
Copy link
Contributor Author

timfee commented Mar 27, 2023

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

@itegmark
Copy link

itegmark commented Mar 27, 2023

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
Copy link

rudiwawa commented Mar 28, 2023

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
Copy link

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
Copy link

rudiwawa commented Mar 28, 2023

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
Copy link

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.

@FairyPenguin
Copy link

The same issue today with "next": "13.4.12", Since I started the project a lot of Lag, Freeze, and crashes in my Chrome and the website itself I suspected everything until I closed the dev server, and everything was back to normal.

image
High memory usage with every simple website it's all static no data fetching.

the higher usage starts as soon as I navigate to any route.

@FairyPenguin
Copy link

I'm using 13.4.12. this is what I'm seeing in development: next-router-worker (one per app started) next-render-worker-app (one per appDir) next-render-worker-pages (one per appPage)

the router-worker seems to grow quickly 2.6Gb after a couple of clicks. This router-worker is connected to the render-worker-app. the render-worker-app is a bit more stable, but grows to 1.6Gb.

Over development time both of these processes are only consuming more memory. Navigating to the same pages seems only increase memory.

@timneutkens : Could it be that also data is cached? is there a way to disabled that completely? We are using apollo, but caching is set to network-only, so disabled. Please let me know if you need more details.

I'm facing the same issue with the worker and the router consumes a lot of memory in Dev - Even the refresh takes time and loads slowly.

@FairyPenguin
Copy link

FairyPenguin commented Jul 27, 2023

The same issue today with "next": "13.4.12", Since I started the project a lot of Lag, Freeze, and crashes in my Chrome and the website itself I suspected everything until I closed the dev server, and everything was back to normal.

image High memory usage with every simple website it's all static no data fetching.

the higher usage starts as soon as I navigate to any route.

Fixed thanks to solution from #49929 (comment)

Disable Image Optimization and things are back to normal with no lag, freeze, or hangs.

Memory usage still the same

@HamAndRock
Copy link

Haven't tried disabling the image optimizations in dev mode since we leverage them in prod. But I have also been getting Out-Of-Memory restarts in dev mode with the latests version. Will post the log when it happens again.

@FairyPenguin

This comment was marked as off-topic.

@mthmcalixto

This comment was marked as off-topic.

@FairyPenguin

This comment was marked as off-topic.

@nicholasgriffintn

This comment was marked as off-topic.

@FairyPenguin

This comment was marked as off-topic.

@timneutkens
Copy link
Member

From @tghpereira in #49929 (comment)

Post

@billnbell i have uploaded the base of my project in the latest versions of next and the version "13.4.5"
https://github.com/tghpereira/next-crash-os.git

@ungarida comparing the "13.4.5" version with the latest version it is more stable, I can use it for longer, but the problem still persists, every time I save the project and the next one generates a new compilation the memory goes up 100 mb until it occupy everything available generating the operating system crash... Killing the process frees up more than 2gb of memory that the next occupies

Captura de tela de 2023-08-10 14-52-27

@BorisBarzotto

This comment was marked as spam.

@BorisBarzotto

This comment was marked as spam.

@Kurochen
Copy link

It seems to me, but if you install a simple site - https://github.com/Kurochen/next_issue.git
Server: Ubuntu Linux 22.04.3
Node: v18.17.1
NPM: 9.8.1
PM2: 5.3.0
NGINX: 1.18.0
Make several transitions through the pages of the site. Memory consumption (next-router-worker and next-router-worker-app) will start to grow.

2023-08-17 (1)
2023-08-17

@lxia1220
Copy link

lxia1220 commented Aug 21, 2023

imported module in rsc called twice in single request in dev mode.
(0 => 1): testSingleton => (2): layout => (0 => 1): testSingleton

The second module created is not sharing global context and it not looks cleaned up with gc

Is this an intended feature?

image

image

@timmywil
Copy link
Contributor

timmywil commented Aug 21, 2023

I use a custom server (see below) and recently switched to the app router and started seeing this. Unfortunately, the HMR socket (that actually started working again for custom servers using the app router in 13.4.19) stays open and can't recover.

Edit: The HMR socket does not recover even when no custom server is used.

- warn The server is running out of memory, restarting to free up memory.
TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at async invokeRequest (/usr/src/app/node_modules/next/src/server/lib/server-ipc/invoke-request.ts:22:10)
    at async handleRoute (/usr/src/app/node_modules/next/src/server/lib/router-utils/resolve-routes.ts:463:31)
    at async resolveRoutes (/usr/src/app/node_modules/next/src/server/lib/router-utils/resolve-routes.ts:718:22)
    at async handleRequest (/usr/src/app/node_modules/next/src/server/lib/router-server.ts:475:11)
    at async NextCustomServer.requestHandler (/usr/src/app/node_modules/next/src/server/lib/router-server.ts:695:7) {
  cause: SocketError: other side closed
      at Socket.onSocketEnd (/usr/src/app/node_modules/next/dist/compiled/undici/index.js:1:63301)
      at Socket.emit (node:events:526:35)
      at Socket.emit (node:domain:489:12)
      at endReadableNT (node:internal/streams/readable:1359:12)
      at processTicksAndRejections (node:internal/process/task_queues:82:21) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: '127.0.0.1',
      localPort: 60394,
      remoteAddress: '127.0.0.1',
      remotePort: 42607,
      remoteFamily: 'IPv4',
      timeout: undefined,
      bytesWritten: 2232,
      bytesRead: 144
    }
  }
}

@switz
Copy link

switz commented Aug 23, 2023

I have been seeing the same thing as @timmywil – when it runs out of memory the server stops working and breaks on fetch/undici.

@Gr33nLight
Copy link

Gr33nLight commented Aug 23, 2023

I have been seeing the same thing as @timmywil – when it runs out of memory the server stops working and breaks on fetch/undici.

Same issue here, since the newest version (13.4.19) instead of restarting, the dev server just crashes
Other than the the emory issue still persists, no notable improvement

@m1911star

This comment was marked as spam.

@thienguen
Copy link

- warn The server is running out of memory, restarting to free up memory.
TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async invokeRequest (D:\thien-personal-website\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
    at async invokeRender (D:\thien-personal-website\node_modules\next\dist\server\lib\router-server.js:254:29)
    at async handleRequest (D:\thien-personal-website\node_modules\next\dist\server\lib\router-server.js:447:24)
    at async requestHandler (D:\thien-personal-website\node_modules\next\dist\server\lib\router-server.js:464:13)
    at async Server.<anonymous> (D:\thien-personal-website\node_modules\next\dist\server\lib\start-server.js:117:13) {
  cause: Error: connect ECONNREFUSED ::1:56549
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1495:16) {
    errno: -4078,
    code: 'ECONNREFUSED',
    syscall: 'connect',
    address: '::1',
    port: 56549
  }
}
- wait compiling /_error (client and server)...
- event compiled client and server successfully in 1077 ms (1838 modules)
TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11576:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async invokeRequest (D:\thien-personal-website\node_modules\next\dist\server\lib\server-ipc\invoke-request.js:17:12)
    at async invokeRender (D:\thien-personal-website\node_modules\next\dist\server\lib\router-server.js:254:29)
    at async handleRequest (D:\thien-personal-website\node_modules\next\dist\server\lib\router-server.js:447:24)
    at async requestHandler (D:\thien-personal-website\node_modules\next\dist\server\lib\router-server.js:464:13)
    at async Server.<anonymous> (D:\thien-personal-website\node_modules\next\dist\server\lib\start-server.js:117:13) {
  cause: Error: connect ECONNREFUSED ::1:56549
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1495:16) {
    errno: -4078,
    code: 'ECONNREFUSED',
    syscall: 'connect',
    address: '::1',
    port: 56549
  }
}

...

When I cleaned up my code, I started facing the issue after changing module export from default to named export. Upgrade next from 13.4.7 to 13.4.19, the problem persists though I don't see it happening on every development run. I'm unsure if the icons are the issue. But I do have both lucide icons and react-icons installed in the project.

node: v18.17.0
npm: 9.6.7

@temrb
Copy link

temrb commented Aug 24, 2023

same issue here in 13.4.18

on server start, the memory usage creeps up towards 3-4GB+.

also as mentioned from comments, server ends suddenly in 500 error at times

@onurravli
Copy link

The problem persists in 13.4.19. I tried to import packages as different ways, but it didn't help.

image

@maiconcarraro
Copy link

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

worked great to me, performance looks better as well

@Thinkscape
Copy link

Thinkscape commented Aug 28, 2023

We've been having the same problem. It would run out of memory after 3-4 page transitions.

  • using MUI including @mui/icon-material/*
  • using @tabler/icons-react/*
  • no wildcard imports, only individual glyphs.
  • RSC but no server actions.
  • tRPC
  • next@13.4.19

Initially I thought removing tRPC would solve the problem, but it just frees up enough memory to last longer, however it doesn't solve the memleak. A few more page transitions and it OOMs and crashes.

@timmywil
Copy link
Contributor

There are two issues here:

  1. Server runs out of memory too frequently. Memory builds up too fast and is forced to restart. Some are reporting that reducing their memory usage allows them to continue development without the server restarting.
  2. Server restart doesn't work. This is the bigger issue. No code was written to remake the HMR socket when the server restarts so it continues to throw errors trying to send messages to a closed server until you restart everything manually.

@sabigara
Copy link

In my case, the root cause of high memory usage was using googleapis from a Server Component. It was adding an extra 2GB+ to the next-router-worker process.

I'm using react-icons too, but eliminating all the import from react-icons or migrating to @react-icons/all-files didn't help at all.

@AhmedChabayta

This comment was marked as off-topic.

@timneutkens
Copy link
Member

We're consolidating these reports into this issue, please read the issue and provide a reproduction there so that it can be investigated: #54708

@vercel vercel locked and limited conversation to collaborators Aug 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: app App directory (appDir: true) bug Issue was opened via the bug report template. linear: next Confirmed issue that is tracked by the Next.js team.
Projects
None yet
Development

No branches or pull requests