eleventy: large data sets: 1.x has issues that 0.11.1, 0.12.1 do not
Describe the bug I’ve a semi-open site generator project that squishes gigabytes of data sources down to about 6.9k pages to be processed by eleventy in two ways:
- the legacy markdown repo
- the more up-to-date json data source (pagination ftw!)
0.11.1 handles the 6.9k documents & 15.6mb json file without issue, 1.0.0 falls over in a similar fashion to that described in #695
To Reproduce The site generator is semi-open in that the source is available at https://github.com/Satisfactory-Clips-Archive/Media-Search-Archive, but it’s not feasible to stash 2.7gb+ of source data into the repo, so the repro steps aren’t readily reproduceable by anyone that doesn’t have the data set.
While the method mentioned in #695 of specifying --max-old-space-size
does move the goalposts somewhat, it still falls over with 8gb assigned.
Steps to reproduce the behaviour:
npm run build
or./node_modules/.bin/elevent --config=./.eleventy.pages.js
- watch & wait
Expected behaviour 1.x to handle 6.9k markdown documents or 6.9k json data file entries as reliably as 0.11.x does
Screenshots
<--- Last few GCs --->
[16544:000001D55D359230] 168029 ms: Mark-sweep 4038.5 (4130.3) -> 4024.3 (4130.3) MB, 3347.8 / 0.0 ms (average mu = 0.138, current mu = 0.017) task scavenge might not succeed
[16544:000001D55D359230] 171431 ms: Mark-sweep 4039.7 (4131.5) -> 4025.8 (4132.0) MB, 3345.7 / 0.0 ms (average mu = 0.081, current mu = 0.016) task scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF70641DF0F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+113567
2: 00007FF7063AD736 v8::internal::MicrotaskQueue::GetMicrotasksScopeDepth+67398
3: 00007FF7063AE5ED node::OnFatalError+301
4: 00007FF706DA0CAE v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF706D8B2FD v8::Isolate::Exit+653
6: 00007FF706C2EC5C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
7: 00007FF706C3AC57 v8::internal::Heap::PublishPendingAllocations+1159
8: 00007FF706C37C3A v8::internal::Heap::PageFlagsAreConsistent+2874
9: 00007FF706C2B919 v8::internal::Heap::CollectGarbage+2153
10: 00007FF706BDC315 v8::internal::IndexGenerator::~IndexGenerator+22133
11: 00007FF70633F0AF X509_STORE_CTX_get_lookup_certs+4847
12: 00007FF70633DA46 v8::CFunctionInfo::HasOptions+16150
13: 00007FF70647C27B uv_async_send+331
14: 00007FF70647BA0C uv_loop_init+1292
15: 00007FF70647BBAA uv_run+202
16: 00007FF70644ABD5 node::SpinEventLoop+309
17: 00007FF706365BC3 v8::internal::UnoptimizedCompilationInfo::feedback_vector_spec+52419
18: 00007FF7063E3598 node::Start+232
19: 00007FF70620F88C CRYPTO_memcmp+342300
20: 00007FF707322AC8 v8::internal::compiler::RepresentationChanger::Uint32OverflowOperatorFor+14488
21: 00007FFB71217034 BaseThreadInitThunk+20
22: 00007FFB71402651 RtlUserThreadStart+33
Environment:
- OS and Version: Win 10, running tool via git bash
- Eleventy Version: 1.0.0
Additional context
- 6.9k markdown files (still falls over if the path is excluded due to the json file)
- 6.9k objects in a pretty-printed json file, totalling 15.6mb spread over 280k lines
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 3
- Comments: 31 (7 by maintainers)
The most terrible option would be to duplicate templates & split the data up.
Howdy y’all, there are a few issues to organize here so just to keep things concise I am opening #2360 to coordinate this one. Please follow along there!
/summon @zachleat Possible performance regression between 0.12.x and 1.0.
Thanks @SignpostMarv, I’ll try fetching the ZIP file from https://github.com/11ty/eleventy/issues/2226#issuecomment-1059791740 and see if it will build on my laptop locally (disclaimer: it’s a higher end M1 MacBook Pro, so results may differ).
@esheehan-gsl How complex is your content from your database? (is it Liquid or Markdown? etc) I’ve toyed with creating a “11ty lorem ipsum” blog generator in the past which just creates X pages based on some global variable so I can poke at performance issues like this w/ bigger sites. But sometimes it comes down to more of how many other filters and plugins and the general complexity of the site instead of just 600 pages vs 6000 pages (which can be frustrating).
So, i think you’re saying: ✔️
0.11.1
✔️
0.12.1
❌1.0.0
❌1.0.1-canary.3
Doubting this has already been fixed in 1.0.1-canary builds, but if you were looking to try the sharpest of cutting edge builds, you could try <kbd>npm i @11ty/eleventy@canary</kbd>. 🔪