Closed vai0 closed 5 years ago
I'm having the same issue on 8 core i7 with 64gb ram and SSD! But I'm using only generated pages and mdx
content on a very small site. So, no external sources of any content. After a couple of hot reloads each reload is taking more and more time.
While working on the same project as @vai0, I also often get this error:
ℹ 「wdm」: Compiling...
———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
221 pages
<--- Last few GCs --->
[31514:0x36cc760] 259984 ms: Mark-sweep 1280.7 (1417.2) -> 1280.7 (1379.7) MB, 1635.9 / 0.1 ms (average mu = 0.808, current mu = 0.000) last resort GC in old space requested
[31514:0x36cc760] 261289 ms: Mark-sweep 1280.7 (1379.7) -> 1280.7 (1373.7) MB, 1304.2 / 0.1 ms (average mu = 0.695, current mu = 0.000) last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x2dfb3695be1d]
Security context: 0x0d4ec729e6e9 <JSObject>
1: byteLength(aka byteLength) [0x2cce61f92b39] [buffer.js:531] [bytecode=0x3ca65df7e411 offset=204](this=0x3ae4255826f1 <undefined>,string=0x0e77b27e1b59 <Very long string[36807366]>,encoding=0x0d4ec72bdd99 <String[4]: utf8>)
2: arguments adaptor frame: 3->2
3: fromString(aka fromString) [0x2cce61fa03a9] [buffer.js:342] [bytecode=0x3ca65df78611 o...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: 0x8e8c18 node::Abort() [node]
2: 0x8e8c61 [node]
3: 0xac0a02 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
4: 0xac0d58 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
5: 0xe97ad2 [node]
6: 0xeaaa3b v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [node]
7: 0xe751a6 v8::internal::Factory::AllocateRawWithImmortalMap(int, v8::internal::PretenureFlag, v8::internal::Map*, v8::internal::AllocationAlignment) [node]
8: 0xe7c32f v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [node]
9: 0xfbd44c v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [node]
10: 0xacab00 v8::String::Utf8Length() const [node]
11: 0x904e84 [node]
12: 0xb4340f [node]
13: 0xb4438c v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [node]
14: 0x2dfb3695be1d
Could you upgrade gatsby-plugin-netlify-cms to version 4.x and netlify-cms-app instead of netlify-cms? This issue should be resolved.
@wardpeet we are currently running on a forked version of version 4.1.6 and the issue persists: https://github.com/vai0/gatsby-plugin-netlify-cms
Here is a profile of the HMR - making a change, saving, undoing that change, then saving again.
The compile time for this was around 1300ms for each change. Note this is with us setting sourcemaps in development to eval
- the cheaper option.
Anyone see anything that we can do to improve this time? It appears graphql is recompiling our queries even though our change is literally updating text.
Here's the performance profile result using Chrome Devtools.
@vai0 can you tell me what version of gatsby you're running? Seems to be 2.8.8, we might have fixed some issues. This might not be the case but i've seen some source-map issues in the past.
Any chance we can have a look at your repo to resolve this? Feel free to DM me or send me a mail to ward@gatsbyjs.com
Hiya!
This issue has gone quiet. Spooky quiet. 👻
We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks for being a part of the Gatsby community! 💪💜
Hey again!
It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY
. Please feel free to reopen this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!
Thanks again for being part of the Gatsby community!
Description
Developing on Gatsby has been over time significantly slowing down - at times taking up 20-30 seconds for the hot loader to refresh the page. After around 10-20 updates to a page - it eventually always runs into the following error below:
Our site is has roughly 250+ static pages in
/pages
, and is programmatically building around 30 pages from*.yml
files generated bynetlify-cms
.I suspect that it has something to do with sourcemaps becoming exceedingly large - and I'm guessing it may have something to do with what we're doing in
gatsby-node.js
orcms.js
for netlify-cms' admin page - although I'm not sure where to start to begin debugging an issue like this. Any pointers would be greatly appreciated.gatsby-node.js
package.json
cms.js
Environment