Node running out of memory when running on 72-core machines

[philz]

When running something like yarn run nyc --reporter=text --reporter=html --reporter=lcovonly --report-dir=output/coverage report on a 72-core machine, I get the following error:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x9dab70 node::Abort() [/root/h/node/env-12.14.1/bin/node]
 2: 0x9dbd26 node::OnFatalError(char const*, char const*) [/root/h/node/env-12.14.1/bin/node]
 3: 0xb3b18e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/root/h/node/env-12.14.1/bin/node]
 4: 0xb3b509 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/root/h/node/env-12.14.1/bin/node]
 5: 0xce68a5  [/root/h/node/env-12.14.1/bin/node]
 6: 0xce6f36 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/root/h/node/env-12.14.1/bin/node]
 7: 0xcf2dca v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/root/h/node/env-12.14.1/bin/node]
 8: 0xcf3cd5 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/root/h/node/env-12.14.1/bin/node]
 9: 0xcf66e8 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/root/h/node/env-12.14.1/bin/node]
10: 0xcc95ce v8::internal::Factory::NewJSObjectFromMap(v8::internal::Handle<v8::internal::Map>, v8::internal::AllocationType, v8::internal::Handle<v8::internal::AllocationSite>) [/root/h/node/env-12.14.1/bin/node]
11: 0xdd0fd6 v8::internal::JsonParser<unsigned short>::BuildJsonObject(v8::internal::JsonParser<unsigned short>::JsonContinuation const&, std::vector<v8::internal::JsonProperty, std::allocator<v8::internal::JsonProperty> > const&, v8::internal::Handle<v8::internal::Map>) [/root/h/node/env-12.14.1/bin/node]
12: 0xdd187f v8::internal::JsonParser<unsigned short>::ParseJsonValue() [/root/h/node/env-12.14.1/bin/node]
13: 0xdd277f v8::internal::JsonParser<unsigned short>::ParseJson() [/root/h/node/env-12.14.1/bin/node]
14: 0xbec565 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [/root/h/node/env-12.14.1/bin/node]
15: 0x1376359  [/root/h/node/env-12.14.1/bin/node]
Aborted (core dumped)

I "resolved" this by applying the following patch locally:

diff --git a/node_modules/nyc/index.js b/node_modules/nyc/index.js
index e2ae1c2..0c11674 100755
--- a/node_modules/nyc/index.js
+++ b/node_modules/nyc/index.js
@@ -220,7 +220,7 @@ class NYC {

       const filesToInstrument = await this.exclude.glob(input)

-      const concurrency = output ? os.cpus().length : 1
+      const concurrency = output ? 1 : 1
       if (this.config.completeCopy && output) {
         const files = await glob(path.resolve(input, '**'), {
           dot: true,
@@ -416,7 +416,7 @@ class NYC {
         const report = await this.coverageFileLoad(f, baseDirectory)
         map.merge(report)
       },
-      { concurrency: os.cpus().length }
+      { concurrency: 1 }
     )

     map.data = await this.sourceMaps.remapCoverage(map.data)
@@ -514,7 +514,7 @@ class NYC {
     return pMap(
       files,
       f => this.coverageFileLoad(f, baseDirectory),
-      { concurrency: os.cpus().length }
+      { concurrency: 1 }
     )
   }

diff --git a/node_modules/nyc/lib/source-maps.js b/node_modules/nyc/lib/source-maps.js
index 8a3914c..721a28a 100644
--- a/node_modules/nyc/lib/source-maps.js
+++ b/node_modules/nyc/lib/source-maps.js
@@ -76,7 +76,7 @@ class SourceMaps {
           this._sourceMapCache.registerMap(absFile, this.loadedMaps[hash])
         }
       },
-      { concurrency: os.cpus().length }
+      { concurrency: 1 }
     )
   }
 }

The issue seems to be that the pMap calls create enough parallelism to overwhelm my V8 memory settings (which vary from 512MB to the effectively default 2GB).

Would you consider adding an option to limit parallelism or perhaps max out the CPU count to something like 4?

Notably, this is similar in spirit to the bug fixed in df34c1c. There a concurrency limit was added, but it can still be too large.

[coreyfarrell]

I can see how 72 could be problematic. I'd rather not add an option for this, if we max out the CPU count to 8 would that solve the issue for you?

[philz]

Yes it would. Thanks!

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.