Another Memory Leak in `next/image` #44685

jaunruh · 2023-01-07T17:11:04Z

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.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000
Binaries:
Node: 19.0.1
npm: 9.2.0
Yarn: 1.22.19
pnpm: 7.21.0
Relevant packages:
next: 13.1.1
eslint-config-next: 13.1.1
react: 18.2.0
react-dom: 18.2.0

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

Image optimization (next/image, next/legacy/image)

Link to the code that reproduces this issue

https://github.com/jaunruh/next-image-test

To Reproduce

Set up docker image:

docker build --no-cache -t next-test .
docker run -p 3000:3000 --name next-test next-test

Surf the app:

open browser at localhost:3000
scroll the home page and the project pages randomly
use the Resource usage extension to monitor the memory usage
see the memory only increase and never decrease

Describe the Bug

The apps memory usage only ever increases and never really decreases anymore. On docker I have easily managed to pass 1gb in memory usage.
The app was run on digitalocean as a bare nodejs app and as a docker container locally and in digitalocean.
The memory usage in digitalocean (1 CPU, 512mb memory) looks as follows, but can also be reproduced with docker:

In the provided repo there are also commented-out image tags. As soon as these are used the problem disappears.

Expected Behavior

No continuous memory increase.

Which browser are you using? (if relevant)

All major browsers

How are you deploying your application? (if relevant)

docker run and build

_NEXT-2023

The text was updated successfully, but these errors were encountered:

remvn · 2023-01-10T07:25:03Z

I tested your repo and had no memory leak when running it as a bare node.js server. However, when I ran it on Docker (using WSL2 and Docker on Windows), I encountered a memory leak. It could be because of this issue: wsl 2 memory leak issue (I experienced a massive memory leak of around 11 GB).

Memory spike a little bit (your image is quite big and NextJS optimize image before send it to client)

Memory did decrease:

jaunruh · 2023-01-11T06:37:24Z

So as mentioned above I was using Digital Ocean Apps or Docker for deployment. The assumption that Digital Ocean Apps use docker to deploy bare nodejs repos should be a fair one. Locally on macOS there does not seem to be any memory leak. I have not tried this on any windows machine. I have updated the repo to use ubuntu instead of debian. But the issue persists. It does not seem to be distro specific.

Mikroser · 2023-02-02T05:57:02Z

Try setting this in next.config.js. I hope it solves the problem

Module.exports = {
images: {
unoptimized: true,
},
}

jaunruh · 2023-02-02T18:32:08Z

I have seen this option. I am going to try it in my repo. But even if it solves the memory leak problem, it creates the issue of unoptimized images. I can then just use a general <img/> tag instead. No need for next/image anymore.

jaunruh · 2023-02-21T14:05:56Z

Generally using unoptimized images seems to fix the memory leak. But well, the images are unoptimized... so I still think this is a bug that needs to be fixed.

khoramshahy · 2023-03-07T15:43:16Z

I have the same issue with using nextjs Image. I am using nextjs 13.1.1 and docker container will be killed.
my question is that if the solution is setting the images unoptimized, so is there still any benefit of using nextjs Image instead of usual Html img?

jaunruh · 2023-03-27T12:54:21Z

Persists in next 13.2.4.

caprica · 2023-05-13T06:55:53Z

I am seeing similar in 13.4.1.

Deployed a small website to Digital Ocean that uses RSC and Image. There's maybe 50 mid-size images total in this entire web-site.

In the screenshot, after the black line is after image optimisation disabled in config. The other dips in the graph before that point are due to server restarts.

As per a warning in the NextJS documentation I am using jemalloc in my deployment.

swedpaul · 2023-07-04T21:50:12Z

Persist in 13.4.7.

Three solutions worked:

add to next.config.js

images: {
 unoptimized: true
},

Change all next.js <Image> to <img>
Add to all next.js <Image> param unoptimized

alan345 · 2023-11-09T16:05:13Z

Same issue for us.

We are using AWS Fargate (ECR, ECS). And yes it is using a docker image.

This solve it, but yes, the images are not optimized anymore.

images: {
 unoptimized: true
},

By reading your comments, I really think the issue is with Docker and next/image

sergio-milu · 2023-12-05T21:02:11Z

same issue here with NextJS 13.5.2, we are running out of memory in a docker with 1 GB of ram (usually ram usage is between 10%-20%)

rusakovic · 2024-02-07T21:33:27Z

One year passed. Still open. Have the same image memory leak but for opengraph

styfle · 2024-02-07T22:22:36Z

The memory leak seems to only be present when running in ubuntu:jammy base image (glibc).

I don't see the memory leak when using the the recommended node:18-alpine base image (musl).

This is likely related to sharp and documented here:

Docs: https://sharp.pixelplumbing.com/install#linux-memory-allocator
Related issue Leak on Linux? lovell/sharp#955

rusakovic · 2024-02-07T22:47:48Z

The memory leak seems to only be present when running in ubuntu:jammy base image (glibc).

I don't see the memory leak when using the the recommended node:18-alpine base image (musl).

This is likely related to sharp and documented here:

Docs: https://sharp.pixelplumbing.com/install#linux-memory-allocator

Related issue Leak on Linux? lovell/sharp#955

Thank you for your response!
I don't use Docker preset in my project. But I use coolify coolify.io that uses Docker, for sure.
My project started on Node 20.
This instruction is also was done: https://sharp.pixelplumbing.com/install#linux-memory-allocator

Maybe I should try standalone distribution with DOcker, if I self-hosted

CeamKrier · 2024-02-15T14:42:31Z

The memory leak seems to only be present when running in ubuntu:jammy base image (glibc).

I don't see the memory leak when using the the recommended node:18-alpine base image (musl).

This is likely related to sharp and documented here:

Docs: https://sharp.pixelplumbing.com/install#linux-memory-allocator

Related issue Leak on Linux? lovell/sharp#955

downgrading the node to 18-alpine resolved the issue for me. Thanks!

Jee-vim · 2024-03-01T06:56:09Z

same here, i try downgrade from 20 to 18-alpine and is work

Image optimization causes high memory usage, [source](vercel/next.js#44685). Temporarily disabling this until a fix is found. Manually compress large images using [Sharp CLI](https://github.com/GTD-IT-XXIV/gtd-xxvi-website?tab=readme-ov-file#sharp-cli).

art-alexeyenko · 2024-04-15T21:11:42Z

The memory leak persists on node 18 alpine, here's the scenario for new nextjs app:

Create nextjs-latest app
Take a large image (~10MB for my case) and put it into public folder
Render that image with next/image on home page
deploy this to docker with node:18.20-alpine
Open home page - this will cause a memory spike to ~2GB. After a bit it will fall to ~1GB and stay there
Open the page in incognito tab and keep refreshing the main tab and the incognito - this will cause a second memory spike and memory usage will remain that way.
A handy demo in case it's needed:
https://github.com/art-alexeyenko/next-image-oom

And some memory usage trends from my local tests with Docker Desktop:

styfle · 2024-04-18T12:00:37Z

That repo is missing sharp.

You need to run “npm install sharp” for production.

…ependency (#63321) ## History Previously, we added support for `squoosh` because it was a wasm implementation that "just worked" on all platforms when running `next dev` for the first time. However, it was slow so we always recommended manually installing `sharp` for production use cases running `next build` and `next start`. Now that [`sharp` supports webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no longer need to maintain `squoosh`, so it can be removed. We also don't need to make the user install sharp manually because it can be installed under `optionalDependencies`. I left it optional in case there was some platform that still needed to manually install the wasm variant with `npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't believe sharp has any fallback built in yet). Since we can guarantee `sharp`, we can also remove `get-orientation` dep and upgrade `image-size` dep. I also moved an [existing `sharp` test](#56674) into its own fixture since it was unrelated to image optimization. ## Related Issues - Fixes #41417 - Related #54670 - Related #54708 - Related #44804 - Related #48820 - Related #61810 - Related #61696 - Related #44685 - Closes #64362 ## Breaking Change This is a breaking change because newer versions of `sharp` no longer support `yarn@1`. - lovell/sharp#3750 The workaround is to install with `yarn --ignore-engines` flag. Also note that Vercel no longer defaults to yarn when no lockfile is found - vercel/vercel#11131 - vercel/vercel#11242 Closes NEXT-2823

Innei · 2024-05-07T04:03:50Z

@styfle Maybe it has nothing to do with sharp, I'm using standalone build and I have sharp installed on my system and also defined the path to sharp in env.

But I monitored that the memory is still rising continuously, then suddenly in a few seconds, the system lost response, at this time through the cloud platform monitoring observed that the CPU 100%, memory 100%, IO Read 100%. But the system didn't trigger the OOM killer which is very strange.

node -v
v22.0.0

Innei · 2024-05-07T10:51:08Z

Hi there, I just dumped a memory dump file. Here's what the memory stack looks like after it's been running for a while.

This was shortly after launch.

As you can see from the following dump, it's the ImageResponse-related modules that are leaking memory.

Innei · 2024-05-07T10:57:17Z

ImageResponse and FigmaImageResponse that means @vercel/og causes memory leak?

Six6pounder · 2024-05-12T21:08:26Z

The memory leak seems to only be present when running in ubuntu:jammy base image (glibc).
I don't see the memory leak when using the the recommended node:18-alpine base image (musl).
This is likely related to sharp and documented here:

Docs: https://sharp.pixelplumbing.com/install#linux-memory-allocator

Related issue Leak on Linux? lovell/sharp#955

Thank you for your response! I don't use Docker preset in my project. But I use coolify coolify.io that uses Docker, for sure. My project started on Node 20. This instruction is also was done: https://sharp.pixelplumbing.com/install#linux-memory-allocator

Maybe I should try standalone distribution with DOcker, if I self-hosted

Did you find a solution for coolify? The issue is still present today

chipcop106 · 2024-07-01T02:13:50Z

Here is our memory chart when using the Next 14.2.3. I confirmed it has a memory leak issue with open graph-image and twitter-image. From 27/6, we disable this function, and this chart becomes normal.

Solution

Try not to use dynamically generated metadata images using tsx,js,ts.

…ependency (#63321) ## History Previously, we added support for `squoosh` because it was a wasm implementation that "just worked" on all platforms when running `next dev` for the first time. However, it was slow so we always recommended manually installing `sharp` for production use cases running `next build` and `next start`. Now that [`sharp` supports webassembly](https://sharp.pixelplumbing.com/install#webassembly), we no longer need to maintain `squoosh`, so it can be removed. We also don't need to make the user install sharp manually because it can be installed under `optionalDependencies`. I left it optional in case there was some platform that still needed to manually install the wasm variant with `npm install --cpu=wasm32 sharp` such as codesandbox/stackblitz (I don't believe sharp has any fallback built in yet). Since we can guarantee `sharp`, we can also remove `get-orientation` dep and upgrade `image-size` dep. I also moved an [existing `sharp` test](#56674) into its own fixture since it was unrelated to image optimization. ## Related Issues - Fixes #41417 - Related #54670 - Related #54708 - Related #44804 - Related #48820 - Related #61810 - Related #61696 - Related #44685 - Closes #64362 ## Breaking Change This is a breaking change because newer versions of `sharp` no longer support `yarn@1`. - lovell/sharp#3750 The workaround is to install with `yarn --ignore-engines` flag. Also note that Vercel no longer defaults to yarn when no lockfile is found - vercel/vercel#11131 - vercel/vercel#11242 Closes NEXT-2823

carlos-dubon · 2025-01-28T14:55:55Z

It is indeed an issue with next/og/@vercel/og. Since we started using it our memory has been growing steadily...

"next": "15.1.6",

carlos-dubon · 2025-01-28T15:00:11Z

can we re-open #65451?

cc: @leerob (idk who to tag 😅)

Innei · 2025-01-28T15:57:35Z

can we re-open #65451?

cc: @leerob (idk who to tag 😅)

cc @huozhi

yekta · 2025-02-13T08:32:05Z

It is indeed an issue with next/og/@vercel/og. Since we started using it our memory has been growing steadily...

"next": "15.1.6",

I'm having the same issue. Using next/og and Next 15.1.6 on an ARM machine.

carlos-dubon · 2025-02-13T14:27:09Z

@huozhi 🙏

carlos-dubon · 2025-02-19T02:01:13Z

do we need to open another issue? @huozhi

yekta · 2025-02-19T14:02:56Z

For reference, I downgraded to 15.1.0 and the next/og memory leak issue seems to be gone.

Can we get some help here? @leerob

EDIT: Nope, problem is back even on 15.1.0.

VadimOnix · 2025-02-23T20:56:32Z

Hello! The issue that most people consider to be a leak is actually an accumulation of the file system cache in Linux.

If you examine the Nextjs caching algorithm in detail, you will see that it does not remove files that have already "expired" based on the expiredAt value. The Linux operating system, to optimize file access, tries to keep metadata (inodes) in RAM.

We observe this behavior because most often our application is deployed in an isolated container in a production environment on a cluster with large memory resources, and there are no parallel processes putting pressure on the RAM; as a result, the memory tries to fill up until it starts affecting performance.

I have created a script that automatically cleans up some of the cache files—you can give it a try.
Link: https://github.com/VadimOnix/next-image-cache-cleaner

If this helps you, I would be grateful for your star on my repository ✌️

yekta · 2025-02-23T22:26:50Z

Hello! The issue that most people consider to be a leak is actually an accumulation of the file system cache in Linux.

If you examine the Nextjs caching algorithm in detail, you will see that it does not remove files that have already "expired" based on the expiredAt value. The Linux operating system, to optimize file access, tries to keep metadata (inodes) in RAM.

We observe this behavior because most often our application is deployed in an isolated container in a production environment on a cluster with large memory resources, and there are no parallel processes putting pressure on the RAM; as a result, the memory tries to fill up until it starts affecting performance.

I have created a script that automatically cleans up some of the cache files—you can give it a try. Link: https://github.com/VadimOnix/next-image-cache-cleaner

If this helps you, I would be grateful for your star on my repository ✌️

I'm running it with unoptimized: true. The RAM usage still keep rising. My guess is OG images created by next/og aren't being cleaned up as well. I think source of the issue is not relevant though. NextJS could let us configure that as well since most people hosting with Node don't want their RAM usage to constantly rise regardless of how much RAM they have. I'm not sure if they do let you configure this already. I looked and couldn't find anything.

jaunruh added the bug Issue was opened via the bug report template. label Jan 7, 2023

kadey001 mentioned this issue Apr 4, 2023

Image Memory Leak Fix c2c-project/prytaneum#420

Merged

gabemeola mentioned this issue Jul 5, 2023

[NEXT-1314] High memory usage in deployed Next.js project #49929

Closed

1 task

styfle added the linear: next Confirmed issue that is tracked by the Next.js team. label Jan 8, 2024

styfle mentioned this issue Apr 25, 2024

feat(next/image)!: remove squoosh in favor of sharp as optional dependency #63321

Merged

Innei mentioned this issue May 7, 2024

next/og cause memory leak in production standalone build #65451

Closed

kapil1garg mentioned this issue May 27, 2024

Digitalocean crashing NUDelta/dtr-web#81

Merged

ethteck mentioned this issue Jul 3, 2024

Open graph image. SVG data parsing failed cause unknown token at 1:1 #61047

Closed

7jw92nVd1kLaq1 mentioned this issue Aug 27, 2024

[BUG] !!! 가장 큰 이슈 !!! Programmers-SpotLight/SpotLight#257

Closed

3 tasks

nakedfool mentioned this issue Oct 7, 2024

chore: remove next/image from codebase jk-labs-inc/jokerace#2607

Merged

styfle mentioned this issue Dec 4, 2024

fix: memory leak from warnOnce() #73483

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Another Memory Leak in `next/image` #44685

Another Memory Leak in `next/image` #44685

jaunruh commented Jan 7, 2023 •

edited by padmaia

Loading

remvn commented Jan 10, 2023 •

edited

Loading

jaunruh commented Jan 11, 2023

Mikroser commented Feb 2, 2023

jaunruh commented Feb 2, 2023

jaunruh commented Feb 21, 2023

khoramshahy commented Mar 7, 2023 •

edited

Loading

jaunruh commented Mar 27, 2023 •

edited

Loading

caprica commented May 13, 2023 •

edited

Loading

swedpaul commented Jul 4, 2023

alan345 commented Nov 9, 2023

sergio-milu commented Dec 5, 2023

rusakovic commented Feb 7, 2024

styfle commented Feb 7, 2024

rusakovic commented Feb 7, 2024

CeamKrier commented Feb 15, 2024

Jee-vim commented Mar 1, 2024

art-alexeyenko commented Apr 15, 2024

styfle commented Apr 18, 2024

Innei commented May 7, 2024

Innei commented May 7, 2024

Innei commented May 7, 2024

Six6pounder commented May 12, 2024

chipcop106 commented Jul 1, 2024

carlos-dubon commented Jan 28, 2025 •

edited

Loading

carlos-dubon commented Jan 28, 2025

Innei commented Jan 28, 2025

yekta commented Feb 13, 2025 •

edited

Loading

carlos-dubon commented Feb 13, 2025

carlos-dubon commented Feb 19, 2025

yekta commented Feb 19, 2025 •

edited

Loading

VadimOnix commented Feb 23, 2025

yekta commented Feb 23, 2025

Another Memory Leak in next/image #44685

Another Memory Leak in next/image #44685

Comments

jaunruh commented Jan 7, 2023 • edited by padmaia Loading

Verify canary release

Provide environment information

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

Link to the code that reproduces this issue

To Reproduce

Describe the Bug

Expected Behavior

Which browser are you using? (if relevant)

How are you deploying your application? (if relevant)

remvn commented Jan 10, 2023 • edited Loading

jaunruh commented Jan 11, 2023

Mikroser commented Feb 2, 2023

jaunruh commented Feb 2, 2023

jaunruh commented Feb 21, 2023

khoramshahy commented Mar 7, 2023 • edited Loading

jaunruh commented Mar 27, 2023 • edited Loading

caprica commented May 13, 2023 • edited Loading

swedpaul commented Jul 4, 2023

alan345 commented Nov 9, 2023

sergio-milu commented Dec 5, 2023

rusakovic commented Feb 7, 2024

styfle commented Feb 7, 2024

rusakovic commented Feb 7, 2024

CeamKrier commented Feb 15, 2024

Jee-vim commented Mar 1, 2024

art-alexeyenko commented Apr 15, 2024

styfle commented Apr 18, 2024

Innei commented May 7, 2024

Innei commented May 7, 2024

Innei commented May 7, 2024

Six6pounder commented May 12, 2024

chipcop106 commented Jul 1, 2024

Solution

carlos-dubon commented Jan 28, 2025 • edited Loading

carlos-dubon commented Jan 28, 2025

Innei commented Jan 28, 2025

yekta commented Feb 13, 2025 • edited Loading

carlos-dubon commented Feb 13, 2025

carlos-dubon commented Feb 19, 2025

yekta commented Feb 19, 2025 • edited Loading

VadimOnix commented Feb 23, 2025

yekta commented Feb 23, 2025

Another Memory Leak in `next/image` #44685

Another Memory Leak in `next/image` #44685

jaunruh commented Jan 7, 2023 •

edited by padmaia

Loading

remvn commented Jan 10, 2023 •

edited

Loading

khoramshahy commented Mar 7, 2023 •

edited

Loading

jaunruh commented Mar 27, 2023 •

edited

Loading

caprica commented May 13, 2023 •

edited

Loading

carlos-dubon commented Jan 28, 2025 •

edited

Loading

yekta commented Feb 13, 2025 •

edited

Loading

yekta commented Feb 19, 2025 •

edited

Loading