Hi @Ed_S - what version of Discourse were you using for these tests? We regularly update ember-cli and its addons, so I just want to be sure we’re looking at the same thing.
Also, how many CPU cores do your VMs have? 1? (you can check by running lscpu in the console)
So that we’re all working with the same data, could you try running:
/var/discourse/launcher enter app
cd /var/www/discourse/app/assets/javascripts/discourse
apt-get update && apt-get install time
NODE_OPTIONS='--max-old-space-size=2048' /usr/bin/time -v yarn ember build -prod
On my test droplet (1 CPU, 1GB RAM, 2GB swap), I see this:
Command being timed: "yarn ember build -prod"
User time (seconds): 369.74
System time (seconds): 22.62
Percent of CPU this job got: 81%
Elapsed (wall clock) time (h:mm:ss or m:ss): 8:02.73
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 774912
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 253770
Minor (reclaiming a frame) page faults: 1158920
Voluntary context switches: 519269
Involuntary context switches: 383328
Swaps: 0
File system inputs: 7521784
File system outputs: 316304
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
We’re using pretty standard ember tooling here, so I’m not sure there’s much we can do in terms of config to reduce memory usage. Our long-term aim is to move to using Embroider, which may give us more options.