JavaScript heap out of memory due to Ember CLI


I am trying to install Discourse to a minimal server 2vCPU / 1GB / 40GB (I don’t anticipate it will have much use, and cutting my costs)

I have been able to install Discourse previously on such an instance, but today I am getting these errors - I have searched the forum but haven’t seen anyone else report it

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.

I ran discourse-doctor as recommended by the script; it detected discourse was not running so started a rebuild, but the result is the same

Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile' failed with return #<Process::Status: pid 1117 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake themes:update assets:precompile'"]}
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
==================== END REBUILD LOG ====================
Failed to rebuild app.
1 Like

+1 Same problem when running the recent update (docker-manager was updated successfully, this was a discourse update from v2.8.0.beta11 to v2.9.0.beta1.

1 Like

Could you share the specs of your server? How much RAM / swap do you have?


My latest rebuild also failed with a 1GB digital ocean droplet. I think I need to temporarily(?) resize to 2GB, but I’ve ./launcher restart app and restarted the pre-rebuild version while I mull it over. Not sure if that’s any help?

root@test:/var/discourse# free -h
              total        used        free      shared  buff/cache   available
Mem:          976Mi       753Mi        80Mi        29Mi       142Mi        64Mi
Swap:         2.0Gi       131Mi       1.9Gi

We’re going to temporarily revert our new Ember CLI build pipeline so we can debug things in lower memory environments.


I’ve edited the title to reflect this issue.


I am using a gCloud e2-micro instance (Micro machine type with 0.25 vCPU and 1 GB of memory, backed by a shared physical core)

edit: If someone is curious why in the world I would do this, I get more traffic from crawlers than users, and we’re trying to provide more points of contact for families and survivors of pediatric stroke. Nobody notices it being a little slow on first load or saving, and so the value delivered on free-tier Google Cloud is helpful.


This change is now reverted while we investigate further. Thanks everyone for the reports!


Please try another rebuild, it should work much better now


This topic was automatically closed after 11 hours. New replies are no longer allowed.