-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
1.9.9 -> 1.9.100, now 'Javascript heap out of memory' #2796
Comments
found this comment & realized syntax was incorrect when increasing memory. Tried building w/this command:
... but still hit 'heap out of memory' error (though took a lot longer). I'm unable to replicate the error in a start kit w/ my JSON data sources, so I assume it has to be a confluence of factors, but a node process hitting 8GB of RAM on v 1.9.100, but building fine on v 1.9.9, has to be a memory leak somewhere under the hood in Gatsby, yea? Where in the src can I look to understand what's happening here & how I might alter my configs to work around this? I want in on all the cool stuff added since 1.9.9 :/ |
This sounds bad :-( Sorry you're running into this but we appreciate you jumping to help find the fix. We definitely need performance tests in the future. So best way to narrow down the problem is to use git bisect. Checkout Gatsby source and follow the contributing guide https://www.gatsbyjs.org/docs/how-to-contribute/ to run your code against source. Then find the git commit id for your current version and start the bisect process to find out when things stopped working. This isn't a perfect solution since it won't find out if one of our dependencies broke things but as long as the problem is in Gatsby's source, you should be able to track down where things broke fairly quickly. |
I'm getting the same error when I try to run EDIT: It works with Gatsby 1.9.9! With small changes though - I had to force the following versions: "resolutions": {
"graphql": "0.10.5",
"relay-compiler": "1.3.0"
}, Otherwise I was getting some errors. But now the build takes less than 10s:
I'll try to bump versions and see when it breaks. |
@KyleAMathews actually is there a way to see what Gatsby is doing in the background? the Update: running it with massive heap size unlocked Gatsby |
@KyleAMathews I looked into it and version 1.9.32 works, but 1.9.33 doesn't. It looks like the culprit is commit 7dd5f3b. Unfortunately, it added a bunch of recursive functions, so it's not that obvious yet which one(s) are causing it. |
Running into this issue on my project also. In our context it only kicks in once we have over ~2000 pages on our site & we only require ~1200 for our Jan milestone so we're using as is for now. Will provide details/tests later once we can commit time & resource to fixing but just bumping to let you know others are affected |
I'm also running into this issue when creating ~1700 pages. I've tried my best to optimize the queries on each page as much as possible, but I can't get the |
@robmccardle @benedfit There's already a PR that fixes this issue: #2969. Please +1 it or sth to get it merged sooner :) I've also created an issue (including very rough implementation) to not inline webpack chunk manifest here: #2992 It can also be something that you might be interested in, if you're trying to use Gatsby with so many pages. |
#2969 is out + a handful of other related performance PRs! Would love to hear from y'all if things work better now. Sorry about the troubles you had in the past. |
@KyleAMathews It works fine for us now with ~1K pages, so I think this issue can be closed now. |
I noticed I was having performance issues with page creation using Semantic UI and as soon as I commented it out it started working. I was doing about 1800 pages. |
I'm running into this issue (or something very similar) on my Gatsby-based blog. Here's what I get when I run
Maybe this is due to my blog being fairly image-heavy? Still, I don't have that many posts, and I can't imagine I have the most image-heavy Gatsby site out there. Strangely, I ran into this issue yesterday but got past it after updating to Gatsby 1.9.236. However, today I added a couple of images and a bit more text, and the issue is back. @KyleAMathews I'm not sure I know how to use Git Bisect or to adjust the Thanks for any insight! |
Strangely, I waited a few days and changed nothing ... and it now works. In case anyone else comes across this and is in the same bind as me: if I do run into the problem again, I will likely try the suggested fix at https://stackoverflow.com/questions/26094420/fatal-error-call-and-retry-last-allocation-failed-process-out-of-memory/48895989#48895989 |
v2 uses a lot less memory as we don't try to render all html files at one 😅 |
For me this is still happening. |
@KyleAMathews Could you tell me from what version this was fixed? |
For anyone that may still be having issues, don't forget to try removing any lock files ( |
I've been putting off upgrading Gatsby b/c I kept getting a 'heap out of memory' error, but I decided today to track it down.
One of my
source-filesystem
sources creates 656 nodes (of typeconsultant
) from a JSON. the JSON is about 800kb.This is the output from running
yarn develop
:This happens both with and without the
--max-old-space-size=8192
flag.However, when I remove the
pageQuery
export from myconsultant
template, the build completes fine.I've tried pulling fields from the
pageQuery
to see if it was just one query that was doing it, but even with a trivial 1-field query, the crash happens.I can't imagine my 658 nodes is more than Gatsby can handle, but OTOH everything worked fine pre-upgrade (and still does on my Master branch), so just trying to narrow-down cause here.
Here's my versions before the upgrade:
And here's my versions post-upgrade:
The text was updated successfully, but these errors were encountered: