-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory #1728
Comments
Just checking, is this happening in production or dev? Also is it happening during rebuild? |
@uptownhr only when I |
Can you try running analyze? Would love to see how your bundles look like. |
@uptownhr What do you mean exactly by running analyze ? |
^ You can visually analyze your bundles by running build with argument |
@STnetwork You are definitely not alone. I also experienced problems with a memory leak this week. Disclaimer: My staging environment has been running stable on v0.10.7 since 5 months and I still did not migrate to v1.0.0, because when I tried migrating during the alpha phase, there were too many side effects and now I feel too close to my clients production beta roll out to go through the migration pain. And due to the fact that people here were experiencing leaks with the latest v1.0.0-rc-11 and I didn't have issue with 0.10.7 until last week, I decided to stay on the deprecated version for my investigations. Without exactly knowing what I was searching for (tbh: I did not even know what I was doing at all), I was trying to analyze heapdumps as suggested here: #805 No deeper knowledge was needed to observe that my dumps went incredibly large (~1,8G after 5 hours of uptime with almost no traffic) and were containing ridiculous amounts of It seemed that the memory leak started after I had dockerized my app. The fresh build pipeline introduced a couple of new module versions for dependencies which weren't issued before when I was manually updating the project with simple After 3 days of sweat and tears, I had my heureka moment today, when I realized, that there was a SSR rendering error (caused by testing for Maybe my story is unique and incredibly stupid, but I wanted to share it, because I found a couple of similar threads on this topic here. Just in case somebody becomes blind-eyed like I did, I recommend to make sure that the dev server output is not showing any weird errors. Even if your front end works fine and you ignore the output to focus on the bigger problem, there might be a good chance, that you introduced the problem yourself. @pi0 @Atinux @alexchopin Although my problem was home-made and could be fixed, there might still be a general problem when errors in the space of the |
@tillkolter Your investigation and report is more than enough 👍 So seems this problem is going to happen when some errors occur on server side. Would you please share (partial) |
My app contains an I think this is everything you would need to reproduce it in a minimal example: default.vue
AudioPlayer.vue
https://github.com/tillkolter/nuxt-oye-records/blob/master/components/audio/AudioPlayer.vue The project also has a Dockerfile https://github.com/tillkolter/nuxt-oye-records |
Confirm. My question 1750 is of the same nature, and leak caused not by the asyncData: after removing components (which use arrays from asyncData) from template (and hence, rendering) - memory usage decreases after some time to (a little bit more value, but) very near the initial. Also noticed huge positive impact on event loop perfomance (since no context coping maybe). Despite of above, I have no renderer warnings or errors at all (except of missing images in browser, but it doesn't matter, because I'm profiling with apache bench). And one more thing - all of my components inclusions are surrounded by divs of other containers and don't use computed data. |
Colleagues, sorry for crossposting #1750 (the details are there), but I think it is important to notice, that context copies made with vue-router via nuxt-link. I have a heavy page with many-many nuxt-links (catalog), > 200 links. When I apparently changed them to simple anchors, SSR instance memory footprint decreased after load test to initial values in meaningful time. |
I am very disillusioned to admit that I still face this memory leak. |
To help debug the issue, I have 3 commits for my site you can pull and run which are causing this exception on my machine: My latest occurrence: https://github.com/levibostian/levibostian.com/tree/0ff08e49c014054b42b189aa3541f14252233de1 Also, from a couple months ago (still having issue): nuxt-community/nuxtent-module#35 I include more details with this commit: https://github.com/levibostian/levibostian.com/tree/c4d17e971ee7f79098d1b5c899f7be0e6cf1375e |
Just like @AndruxaSazonov, I'm rendering a list of items with |
Just don't use nuxt-link... use a helper component, which pushes to the $router object... so we can overcome this issue |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hi,
I use the nuxtent module, when I
yarn generate
I have this message :You can reproduce the issue with my repo
I opened an issue in the nuxtent-module, because I thought it was related to the module, but It's probably related to NuxtJS.
Thanks to help me.
The text was updated successfully, but these errors were encountered: