next.js: appDir + RSC: "The server is running out of memory, restarting to free up memory"

I am having the same problem with v13.4.4

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.

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

I hope this is a dev bug and not a production issue.

While building out an app, every 30m or so I get:

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

But it never properly restarts, so I have to manually do it.

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.

I wonder if it’s related to Styled Components. There used to be a memory issue with Global Styles. Any thumbs up from people using Styled Components?

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

~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
    }
  }
}

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.

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.

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

- 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

i am using the latest version of nextjs (13.4.10) and still getting “warn The server is running out of memory, restarting to free up memory” also with this warning “getServerSession` is used in a React Server Component” and the compile is compiling too slowly

I’d be in favour of moving the chatter to a discussion, there’s no point playing guess who and y’all are simply pointing out false positives.

Most people are just waiting on this to be closed vs people’s theories as to what it is.

I think you can focus on other things more important than deciding what is false and negative with this tone of arrogance and entitlement. No one really needs or is interested in your favor!!

And BTW did you hear about “Turn of Notifications” Thank me later

Everyone is trying to help with code, screenshots, and experience.

If it wasn’t for people’s solutions here I wasn’t gonna fix it.

So calm down your arrogance and entitlement. And find other things useful to do.

Getting the same issue on app directory in Nextjs v13.4.8 production mode.

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

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

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:

same issue…

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)

I’d be in favour of moving the chatter to a discussion, there’s no point playing guess who and y’all are simply pointing out false positives (Yes it’s a false positive if you’re just turning off features that use CPU/RAM without doing a stack trace, ofc they will reduce your usage. Instructions for reporting things other than that: https://github.com/vercel/next.js/issues/48748).

Most people are just waiting on this to be closed vs people’s theories as to what it is.

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.

@jamilAbbas for the slow compiling you’ll definitely want to upgrade to at least 13.4.8+ as we did a bunch of optimizations. Can you provide the CPU profile and trace on #48748 following these steps: https://github.com/vercel/next.js/issues/48748#issuecomment-1578374105

I think this issue just happening on the app directory in dev mode. Because on production the issue doesn’t persist. And interesting this is if I use the pages directory the issue is also gone.

Bumping, having the same issue, this is unusable please do something. Fast refresh takes roughly 10seconds every single change i have to wait for the page to reload…

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.

Same same, but no MUI or react-icons.

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

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.

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.

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.

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.

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

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

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

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

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

same issue 😦

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.