When determining the default maxWorkers, Pool leverages the number of CPUs reported by os.cpus() (via the environment module). This is an incorrect use of os.cpus() and the os.availableParallelism() function is provided for that purpose. The documentation for os.cpus() explicitly states:
os.cpus().length should not be used to calculate the amount of parallelism available to an application. Use os.availableParallelism() for this purpose.
Why does this matter? In environments where the application is running inside of containers -- in my case an Ember.js build running in Kubernetes -- the os.cpus().length call returns the number of CPUs on the host machine; not the number of CPUs available to the container. This causes more parallelism in the worker pool than is actually efficient. In my use case, it also results in an out of memory error.
When determining the default
maxWorkers,Poolleverages the number of CPUs reported byos.cpus()(via the environment module). This is an incorrect use ofos.cpus()and theos.availableParallelism()function is provided for that purpose. The documentation foros.cpus()explicitly states:Why does this matter? In environments where the application is running inside of containers -- in my case an Ember.js build running in Kubernetes -- the
os.cpus().lengthcall returns the number of CPUs on the host machine; not the number of CPUs available to the container. This causes more parallelism in the worker pool than is actually efficient. In my use case, it also results in an out of memory error.