[kbn/optimizer] disable parallelization in terser plugin

[spalger]

In order to avoid a memory issue caused when running the build in smaller VMs we should prevent terser from launching worker processes. We're already running in workers and node child processes reserve the same amount of memory as the parent according to https://togithub.com/nodejs/node/issues/25382, additionally, when running on smaller computers we run the optimizer with two workers and 4GB of max-old-space-size for each worker. This combination seems to be exploding on build machines creating builds of the whole stack. Disabling the parallel option in TerserPlugin seems to fix this by running terser in the same process as the webpack compiler so it respects the worker count.

Additionally, rather than limiting the worker number to cpuCount/3, when building the distributable we'll use cpuCount-1 workers because, by default, we only build the dist when it's the only thing happening and we don't have to be quite as considerate to other processes running on the machine (like we try to do in dev).

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 1f65039

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[tylersmalley]

While I do see a slight reduction (~7%), I am doubting that this is the cause of the OOM in the release manager given how little memory it's consuming. Still, it's worth the reduction in memory usage and workers. I am going to run some tests during the actual build to see what we're seeing resource wise there.

---

Wrote a crude bash script to measure the change of memory usage over time:

#!/bin/bash

mem=`free -m | awk 'NR==2{printf "%s", $3}'`

while true; do
        let current_mem=`free -m | awk 'NR==2{printf "%s", $3}'`;
        let mem_diff=current_mem-mem;
        echo $mem_diff;

        sleep 1;
done

Built the platform plugins with the following command while monitoring the usage:

node scripts/build_kibana_platform_plugins.js --no-cache --workers=2

master:

Duration of ~69.07 (69.3, 68.1, 69.8)
Memory usage of ~3,533MB (3332, 3488, 3779)

fix/memory-usage-when-building-dist:

Duration of ~68.57s (68.3, 68, 69.4)
Memory usage of ~3,277MB (3308, 3153, 3370)

[spalger]

I am doubting that this is the cause of the OOM in the release manager given how little memory it's consuming

I'm not sure the exact memory usage is relevant, I think the issue is when memory usage is high and then we try to spawn a process it refuses to spawn the process unless there is enough uncommitted ram for the entire process to be doubled... Or something like that...

https://togithub.com/nodejs/node/issues/25382#issuecomment-580319938 is really interesting, this might be even worse once we're on node 12...

[spalger]

7.7/7.x: ce10569