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

Memory Leak - Nuxt3 #2762

Closed
dissy123 opened this issue Sep 2, 2024 · 14 comments
Closed

Memory Leak - Nuxt3 #2762

dissy123 opened this issue Sep 2, 2024 · 14 comments
Labels

Comments

@dissy123
Copy link

dissy123 commented Sep 2, 2024

Reproduction

https://github.com/dissy123/nuxt-pinia-memory-leak

Steps to reproduce the bug

The Repository i posted is just a blank Nuxt3 Project, i have added a Pinia Store like in the Documentation here:
https://nuxt.com/docs/getting-started/state-management

Have i done something wrong? Or is this a memory leak?

The Strings from the json objects are stored each request in the HEAP but not deleted again.

I tried it without the Code of the Store and no memory leak happens.

pnpm i

pnpm build

node --inspect .output/server/index.mjs

ab -n 50 -c 10 "http://localhost:3000/"

Sorry i am a little bit confused already hunting this for a few weeks now.

When you comment out the line in app.vue

await useAsyncData("todos", () => store.fetchIconsData());

no memory leak is happening!

Expected behavior

no memory leak

Actual behavior

image

Additional information

No response

@henk23
Copy link

henk23 commented Sep 2, 2024

Can confirm. Memory is slowly filling up.
Between each Snapshot I ran

  • 700 requests
  • garbage collection

Looks like roughly 20 MB memory increase per 700 requests.

leak

Is this a leak? Or is there a restriction like "You can't use fetch inside a store when in SSR"?

Copy link
Member

posva commented Sep 2, 2024

Given that the method is from Nuxt, please open a discussion or issue in Nuxt.
The usage doesn’t seem wrong at first glance It needs callOnce

@posva posva added the ⛰ pkg:nuxt Related to @pinia/nuxt label Sep 2, 2024 — with Volta.net
@manniL
Copy link

manniL commented Sep 3, 2024

I wonder if the same can be observed when not setting pinia state.

Also, useAsyncData should not be used to trigger side effects. callOnce is preferred when working with pinia stores and e.g. fetching data "once".

(Though @posva I think there might be some room for improvements to have sth. similar to useAsyncData but for pinia stores, but that's a different topic.)

@posva
Copy link
Member

posva commented Sep 3, 2024

Does the leak disappear with callOnce? If so, adding this to docs would be enough. I think we talked about this with Atinux

@dissy123
Copy link
Author

dissy123 commented Sep 3, 2024

hey i also tried it with callOnce the leak is also there!

I also tried it with https://vueuse.org/shared/createGlobalState/ and it also didn't change.

I also tried useFetch when fetching and $fetch

@danielroe
Copy link
Member

If the memory leak can only be reproduced with pinia then it is probably something to be tracked here. It could be an issue with the Nuxt module implementation.

I’ll take a look, but if you could try to reproduce without pinia that would be helpful too.

@dissy123
Copy link
Author

dissy123 commented Sep 3, 2024

image

https://github.com/dissy123/nuxt-pinia-memory-leak/tree/without-pinia

yes it also happens without pinia!

when just using useAsyncData haven't tried callOnce now

@danielroe
Copy link
Member

The issue is that you are logging those values. Because they are logged to the devtools when you are inspecting the server, they can't be GCed. Removing your console.log statement removes the 'memory leak'.

@dissy123
Copy link
Author

dissy123 commented Sep 3, 2024

omg... okay never thought about that... true...
sorry!

thanks for pointing that out!

@danielroe
Copy link
Member

danielroe commented Sep 3, 2024

Here's a reproduction with pinia + express (and without Nuxt) - it does seem to leak: https://github.com/danielroe/pinia-ssr-repro.

Steps to reproduce:

pnpm i
node --inspect server.js
ab -n 3000 -c 50 "http://localhost:3000/"
# GC + snapshot from devtools
ab -n 3000 -c 50 "http://localhost:3000/"
# GC + snapshot from devtools

@posva posva added bug Something isn't working contribution welcome and removed ⛰ pkg:nuxt Related to @pinia/nuxt labels Sep 3, 2024 — with Volta.net
@posva
Copy link
Member

posva commented Sep 3, 2024

I will have to take a deeper look later this month or in October. Feel free to take a deeper look in the meantime

@dissy123
Copy link
Author

dissy123 commented Sep 5, 2024

hey guys, sorry the leak i had in my bigger project was in nuxt-booster, it is duplicating the pinia store on each request (the snapshot looked like the one in the reproduction with the console.log ;) ), so i thought it would have to do something with pinia ;) !

see here:
basics/nuxt-booster#1121

@PanMisza
Copy link

PanMisza commented Sep 5, 2024

It looks like the memory leak is caused by this:

pinia.use(devtoolsPlugin)

Here is how it looks in dist files:

if ((((process.env.NODE_ENV !== 'production') || (typeof __VUE_PROD_DEVTOOLS__ !== 'undefined' && __VUE_PROD_DEVTOOLS__)) && !(process.env.NODE_ENV === 'test')) && typeof Proxy !== 'undefined') {
        pinia.use(devtoolsPlugin);
    }

After commenting out pinia.use(devtoolsPlugin); on my env, memory leaks are gone.
As a temporary fix on your environments you can run app with NODE_ENV=production.

@posva posva added ✨ enhancement New feature or request 🧑‍💻 pkg:devtools Related to devtools and removed bug Something isn't working labels Sep 6, 2024 — with Volta.net
Copy link
Member

posva commented Sep 6, 2024

That's interesting. Devtools shouldn't be use in production besides for inspection, so it's expected to remove that part when building for production. Usually, the code is stripped out when bundling for production. I tested with CJS and esm and it seems that the memory leaks are internals (weird) when using NODE_ENV=production. So this doesn't seem to be a problem

Screenshot 2024-09-06 at 09.45.20.png

@posva posva closed this as completed Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

6 participants