Next.js development high memory usage

[timneutkens]

Before posting a comment on this issue please read this entire post.

Previous work

The past few weeks we've been investigating / optimizing various memory usage issues. Specifically geared towards production memory usage. In investigating these we were able to find there was one memory leak in Node.js itself when using fetch() in Node.js versions before 18.17.0 (you'll want to use 18.17.1 for security patches though).

Most of the reports related to memory usage turned out to be reports of "it's higher than the previous version" rather than a memory leak. This was expected because in order to run App Router and Pages Router at the same time with different React versions two separate processes were needed. This has been resolved by reducing the amount of processes to two, one for Routing and App Router rendering, and one for Pages Router rendering. So far we haven't received new reports since the latest release.

In some issues there were reports related to Image Optimization in production, however no reproduction was provided so it could not be investigated adequately, if you have a reproduction for that please refer to this issue: #54482

New

With the memory usage in production resolved we've started investigating reports of development memory usage spikes. Unfortunately these reports suffer from the same problem as the production memory usage issues people raised before, they're full of comments saying same issue or posting screenshots of monitoring tools saying "Look, same issue".

Unfortunately, as you can image, these replies are not enough to investigate / narrow down what causes the memory usage, for example in multiple cases that we did get a reproduction and could investigate the reason for the high memory usage was:

• A bug in the application code, causing infinite looping components
• Accidental import of ~11.000 modules through icon libraries -- Yes, many icon libraries ship massive amounts of re-exports and those have to be bundled before it can be tree-shaken. We've been working on an automated way to split these up in optimize_barrel SWC transform and new optimizePackageImports config #54572 that should help a bit to reduce the size (and compilation speed too).
• Webpack customization, e.g. adding external libraries that change webpack settings, for example to write additional sourcemaps

So far I've been able to make one small change to webpack's memory caching to make it garbage collect a bit more aggressively in #54397. I'm not expecting that change to have a big impact on the reported issues though.

We'd like to investigate these reports further, however we're unable to narrow these down if there is no code to run to collect heap snapshots and profiles for, hence this issue. If you are able to please provide runnable code of what you're experiencing.

Comments that don't include runnable code will be automatically hidden in order to keep this issue productive. This includes comments that only have a screenshot and applications that can't run.

I'm going to combine the other reports into this issue as separate comments.

I've made sure that we have 2-3 engineers on our team available to investigate when we get runnable reproductions to investigate.

Thanks in advance!

_NEXT-1569

[timneutkens]

@noetix Disagree that this had anything to do with bullying. All I did was explain that my posts are continuously being ignored, including in this issue. Then I explained what to do, which is to provide a runnable application. There is nothing we can do without a runnable example, which was already shared in the initial issue, I even made it bold to highlight that further.

Happy to explain it again, the reason we can't do anything without runnable code is that in order to narrow down the memory usage we need to change the Next.js core code in the application, for example to disable client components compilation and such in order to narrow down where the memory usage comes from. There is no way to do that based on screenshots / messages / information you can provide as it would require countless hours of your time and our time (think 2 weeks full time at least) in order to investigate this.

The emoji reactions not being shown for off-topic marked posts is a bug in GitHub. As mentioned in the initial issue any posts that don't include a reproduction will be automatically hidden.

Since you didn't like the earlier explanation I'll just remove it, don't feel strongly about keeping the comment. Definitely wasn't bullying, you were reading into that. Bullying would be the threats I've received recently from anonymous developers on Twitter that they'll come visit my house soon...

@weyert we haven't made changes to development memory usage besides the PR linked in the issue so really all I need is a reproduction, luckily @AhmedChabayta posted one, hopefully that is enough, fingers crossed.

@Thinkscape please open a separate issue, that bug would be separate from this issue 👍

[limeburst]

I've posted a reproduction here: https://github.com/limeburst/vercel-nextjs-54708

Start the development server, navigate from

• http://localhost:3000/1
• http://localhost:3000/2
• ...
• http://localhost:3000/20

And watch the memory usage grow, until the server restarts.

[rajat1saxena]

You can use this code to see the issue. The server is getting aborted silently without any errors.

https://github.com/codelitdev/courselit/tree/tailwindcss-2

Logs

rajat@rajat-laptop:~/projects/courselit$ yarn dev
- info Loaded env from /home/rajat/projects/courselit/apps/web/.env.local
- info Loaded env from /home/rajat/projects/courselit/apps/web/.env
- ready started server on [::]:3000, url: http://localhost:3000
- event compiled client and server successfully in 545 ms (18 modules)
- wait compiling...
- event compiled client and server successfully in 263 ms (18 modules)
- info Loaded env from /home/rajat/projects/courselit/apps/web/.env.local
- info Loaded env from /home/rajat/projects/courselit/apps/web/.env
- info Loaded env from /home/rajat/projects/courselit/apps/web/.env.local
- info Loaded env from /home/rajat/projects/courselit/apps/web/.env
- wait compiling /404 (client and server)...
- wait compiling / (client and server)...
rajat@rajat-laptop:~/projects/courselit$

[stigmartins1]

I'm getting 'server out of memory' after a while by letting the server run and writing/saving code that calls the following functions a few times.

import { google } from "googleapis";

export async function authSheets() {
  //Function for authentication object
  const auth = new google.auth.GoogleAuth({
    keyFile: "./auth/auth-sa-sptk.json",
    scopes: ["https://www.googleapis.com/auth/spreadsheets"],
  });

  //Create client instance for auth
  const authClient = await auth.getClient();

  //Instance of the Sheets API
  const sheets = google.sheets({ version: "v4", auth: authClient });

  return {
    auth,
    authClient,
    sheets,
  };
}

import { authSheets } from "./authSheets";

export async function clearSheetContents(sheetName) {
  console.log("sheet =", sheetName);
  const SHEET_ID = "123";
  const sheetId = SHEET_ID;
  const { sheets } = await authSheets();

  try {
    const result = await sheets.spreadsheets.values.clear({
      spreadsheetId: sheetId,
      range: sheetName,
    });
    console.log("result.data =", result.data);
  } catch (err) {
    // TODO (developer) - Handle exception
    throw err;
  }
}

import { authSheets } from "./authSheets";

// https://developers.google.com/sheets/api/guides/values
export async function setSheetValues(sheetName, input) {
  const SHEET_ID = "123";
  const sheetId = SHEET_ID;
  const values = [input];
  const resource = { values };
  // Updates require a valid ValueInputOption parameter
  const valueInputOption = "RAW"; // The input is not parsed and is inserted as a string.
  const { sheets } = await authSheets();

  try {
    const result = await sheets.spreadsheets.values.append({
      spreadsheetId: sheetId,
      range: sheetName,
      valueInputOption: valueInputOption,
      resource,
    });
    console.log("result.data =", result.data);
  } catch (err) {
    // TODO (developer) - Handle exception
    throw err;
  }
}

{
  "name": "test",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "autoprefixer": "10.4.15",
    "axios": "^1.5.0",
    "encoding": "^0.1.13",
    "eslint": "8.48.0",
    "eslint-config-next": "13.4.19",
    "googleapis": "^126.0.1",
    "next": "13.4.19",
    "postcss": "8.4.29",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "tailwindcss": "3.3.3"
  }
}

Node v. v18.17.1

[jpmnteiro]

Same boat here.

Running nextjs (v14.x) takes 9.2GB~ RAM. Switching on --turbo brings the memory usage to 13.2GB~ RAM.

Is there any way to investigate what's causing the increase in memory usage?

[broscr]

The cause of the RAM overflow is using fetch. I had the same issue; I replaced all fetch requests with axios, and the project never went over 200MB of RAM after that.

[KillerCodeMonkey]

@broscr did you tried nextjs v15 before? i think fetch caching is deactivated per default, so there should no such strange memory usages, now

[broscr]

@broscr did you tried nextjs v15 before? i think fetch caching is deactivated per default, so there should no such strange memory usages, now

Yes I tried nextjs v15.0.1

[yogithesymbian]

 webpack: (config, { dev }) => {
    if (config.cache && !dev) {
      config.cache = Object.freeze({
        type: "memory",
      });
    }
    // Important: Return the modified config
    return config;
  },

doesnt work still in case consume high memory
here is my fullnext.config.js

// /* uncomment for analyze */
const withBundleAnalyzer = require("@next/bundle-analyzer")({
  enabled: process.env.ANALYZE === "true",
});

module.exports = withBundleAnalyzer({
  reactStrictMode: false, //Disable strict mode
  webpack: (config, { dev }) => {
    if (config.cache && !dev) {
      config.cache = Object.freeze({
        type: "memory",
      });
    }
    // Important: Return the modified config
    return config;
  },
  productionBrowserSourceMaps: false, // Disable source maps in development
  optimizeFonts: true, // Disable font optimization
  compiler:
    (process.env.NODE_ENV === "production") == true
      ? {
          styledComponents: true,
          // removeConsole: true,
          // removeConsole: {
          //   exclude: ["error"],
          // },
        }
      : {
          styledComponents: true,
          // removeConsole: { // laters exclude by --turbo
          //   exclude: ["error"],
          // },
        },
  swcMinify: true,
  transpilePackages: ["lodash-es"],
  experimental: {
    turbo: {
      rules: {
        "*.svg": {
          loaders: ["@svgr/webpack"],
          as: "*.js",
        },
      },
      resolveAlias: {
        underscore: "lodash",
        mocha: { browser: "mocha/browser-entry.js" },
      },
      resolveExtensions: [
        ".mdx",
        ".tsx",
        ".ts",
        ".jsx",
        ".js",
        ".mjs",
        ".json",
      ],
      moduleIdStrategy: "deterministic",
    },
    staleTimes: {
      dynamic: 30,
      static: 180,
    },
    optimizePackageImports: [
      "antd",
      "@ant-design/icons",
      "@ant-design/pro-components",
      "@emotion/css",
      "date-fns",
      "lodash-es",
      "ahooks",
      "crypto-js",
      "dayjs",
    ],
  },
  env: {
    use_otp: "1",
    use_otp_simulation: "1",
  },
});

[tnfssc]

Workaround for Linux users.

You can use the following command to limit the memory usage of the dev server. The compilations get slower when your memory limit is too small.

systemd-run --user --scope -p MemoryMax=4000M pnpm dev

Source: https://unix.stackexchange.com/a/536046

EDIT: This command limits the physical memory usage only. If your system doesn't have swap memory allocated, this method will crash the process.

[wintercounter]

How is this a workaround? Next dev server will keep restarting itself if it reaches the memory threshold when using Webpack. When using Turbopack it'll just silently kill itself.

…

On Tue, 26 Nov 2024, 06:21 Sharath, ***@***.***> wrote: Workaround for Linux users. You can use the following command to limit the memory usage of the dev server. The compilations get slower when your memory limit too small. systemd-run --user --scope -p MemoryMax=4000M pnpm dev Source: https://unix.stackexchange.com/a/536046 — Reply to this email directly, view it on GitHub <#54708 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHLJQGYBBXJ5KDH5GADIFD2CQANBAVCNFSM6AAAAAA4CX4LH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJZGY4DKMBWGM> . You are receiving this because you commented.Message ID: <vercel/next. ***@***.***>

[tnfssc]

How is this a workaround? Next dev server will keep restarting itself if it reaches the memory threshold when using Webpack. When using Turbopack it'll just silently kill itself.
…
On Tue, 26 Nov 2024, 06:21 Sharath, @.> wrote: Workaround for Linux users. You can use the following command to limit the memory usage of the dev server. The compilations get slower when your memory limit too small. systemd-run --user --scope -p MemoryMax=4000M pnpm dev Source: https://unix.stackexchange.com/a/536046 — Reply to this email directly, view it on GitHub <#54708 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLJQGYBBXJ5KDH5GADIFD2CQANBAVCNFSM6AAAAAA4CX4LH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJZGY4DKMBWGM . You are receiving this because you commented.Message ID: <vercel/next. @.>

@wintercounter I tried it on my machine with 2000MB limit with turbo. The process instantly hit 1950+MB as expected. But it stayed there. The compilation times were a tad slower, but the program never crashed. I tried 200MB just for fun. Compilation took forever, but the program never crashed.

I asked my teammate to try the same after posting the workaround here, he faced the exact same issue as you described. Could it be related to my hardware configuration? I use Ubuntu 24.04 on a Ryzen 9. He didn't have swap memory allocated.

EDIT: Confirmed that it increases my swap usage. Most linux installs don't allocate swap memory, so it's crashing on them.

[TylerNRobertson]

This is still very much an issue. Currently running into 6-7 GB's used just for the ideal server, I'm not even navigating around the app.

Any tips or insights would be awesome, seems like this issue has been open for a while

[schnubor]

This is insane, it seems like it got worse with 15.1?

Same app, cold start on a 32GB machine:

With Turbopack:

With Webpack (much better):

[guillaume-g]

Same here ! I would love to help or give feedbacks 😊

[gho1b]

This is insane, it seems like it got worse with 15.1?

Same app, cold start on a 32GB machine:

With Turbopack:

With Webpack (much better):

So, is this problem coming from turbopack and not nextjs, isn't?

[RealFascinated]

I get this duplicated strings issue in production. my heapsnapshot

[SC0d3r]

I'm facing a serious issue with Next.js 15, I can't upgrade from Next.js 14 because my 12GB RAM laptop simply can't handle it. I'm using MUI, which adds to the load, but with Next.js 14, the dev server still manages to start and load the site, even if it takes a long time. However, with Next.js 15, it just crashes and exits before the app even loads. For now, I'm sticking with Next.js 14.

[tnfssc]

I'm facing a serious issue with Next.js 15, I can't upgrade from Next.js 14 because my 12GB RAM laptop simply can't handle it. I'm using MUI, which adds to the load, but with Next.js 14, the dev server still manages to start and load the site, even if it takes a long time. However, with Next.js 15, it just crashes and exits before the app even loads. For now, I'm sticking with Next.js 14.

@SC0d3r You are likely using --turbopack with Next 15 but not with Next 14. The memory usage with turbopack is enormous on both 14 and 15. On Next 15 the dev command uses turbopack by default. I use two scripts in my package.json and use the dev:webpack one whenever I can't afford the memory usage.

  // snip
  "scripts": {
    // snip
    "dev": "next dev --turbopack",
    "dev:webpack": "next dev",
    // snip
  },
  // snip

[yusrmuttaqien]

This is insane, it seems like it got worse with 15.1?

Same app, cold start on a 32GB machine:

With Turbopack:

With Webpack (much better):

How do I use Webpack? Running npm/bun run dev command (in script --turbo/--turbopack has been omitted) still results in running the server with Turbo. Indicated by message below

[loki-tang]

Nextjs single-handedly promoted memory consumption and the development of semiconductors, it's human hope!

[BRAVO68WEB]

Vercel cooked too much

[laohanme]

nextjs 15.1.7 when build

Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

---

Memory usage report at "periodic memory snapshot":
- RSS: 132.19 MB
- Heap Used: 38.19 MB
- Heap Total Allocated: 41.04 MB
- Heap Max: 4144.00 MB
- Percentage Heap Used: 0.92%

---

[jewells77]

Facing the same issue while deploying on Digital Ocean App Platform — due to this issue, my app's memory usage hits 100%, causing frequent restarts.

[Mohit1310]

I'm experiencing high memory consumption when deploying my Next.js (15.2.4) app on DigitalOcean App Platform. I have a 1GB RAM plan with a shared CPU, and it's using all of it. Should I upgrade the RAM, or is 1GB sufficient? I'm using Strapi as a CMS with GraphQL.

This is my memory usage

this is my cpu usage which is low

this is restart count for same timeline

[Smef]

Here's a test repo (with a branch I'll leave, memory-usage-freeze-state) which is experiencing this when running pnpm run dev. It's a pretty new starter site, and often gets stuck compiling the root of the site with a message like Compiling / ...

From this repository I can reproduce this fairly regularly by performing the following steps:

• run pnpm run dev
• open the site at http://localhost:3000
• click the "browse the art" link (which goes to a missing page currently)
• navigate back in the browser.

This causes the server to get stuck compiling and the memory usage blows up.

Here's an example from the console which shows the process of loading the main page and it getting stuck, using a ton of memory, and then eventually restarting.

✓ Starting...
 ✓ Ready in 664ms
 ○ Compiling / ...
 ✓ Compiled / in 841ms
 GET / 200 in 1031ms
 GET / 200 in 271ms
 ⚠ Server is approaching the used memory threshold, restarting...
   ▲ Next.js 15.2.3 (Turbopack)
   - Local:        http://localhost:3000
   - Network:      http://192.168.1.212:3000

 ✓ Starting...
 ✓ Ready in 722ms

Image

I've noticed that when this happens you can watch the memory usage increasing and increasing over time until the inevitable crash and reset.

This does NOT happen if I remove --turbopack from the dev script.