-
Notifications
You must be signed in to change notification settings - Fork 27.1k
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
Another Memory Leak in next/image
#44685
Comments
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: |
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. |
Try setting this in next.config.js. I hope it solves the problem Module.exports = { |
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 |
I have the same issue with using nextjs Image. I am using nextjs 13.1.1 and docker container will be killed. |
Persists in |
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. |
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%) |
One year passed. Still open. Have the same image memory leak but for opengraph |
The memory leak seems to only be present when running in I don't see the memory leak when using the the recommended This is likely related to |
Thank you for your response! Maybe I should try standalone distribution with DOcker, if I self-hosted |
downgrading the node to 18-alpine resolved the issue for me. Thanks! |
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).
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).
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).
The memory leak persists on node 18 alpine, here's the scenario for new nextjs app:
And some memory usage trends from my local tests with Docker Desktop: |
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
@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.
|
ImageResponse and FigmaImageResponse that means |
Did you find a solution for coolify? The issue is still present today |
…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
Verify 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:
localhost:3000
Resource usage
extension to monitor the memory usageDescribe 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: