3.1.x to 3.2.0 upgrade hangs/fails on 1GB instance

@JammyDodger @Falco @Ed_S thank you all for your help in working through this.

So I was finally able to get it to build on a 2GB RAM instance. It appears that while trying to build 3.2.0 discourse it was asking for 64GB of VM for ember. That’s looks pretty wild.

So it looks like 3.1.5 is the last version that will run on 1GB of RAM. Starting 3.2.0, the minimum appears to be 2GB. @falco @sam can we expect the hardware requirements to keep doubling to upgrade discourse? Discourse can run pretty happily on 1GB, it’s the upgrades that are killing it. Is there no way to prebuild the assets or images and keep them on GitHub and have them downloaded while upgrading to reduce the memory load? The concern is there that for smaller sites, we don’t need 2GB, 4GB, 8GB etc instances.

Ed, just FYI - my strategy does not work with Lightsail. Once you upgrade to a larger instance there’s no way to downgrade. So I can take a snapshot of the 1GB server, then spin up a new 2GB server (and upgrade discourse), but then when I take a snapshot of the 2GB server there’s no way to spin that back up on a 1GB server (because the filesystem goes from 40GB to 60GB and that can’t be reversed). Having said that it’s still not a happy situation that one needs to “upscale” the server just to upgrade the software.

So basically if you’re using Lightsail, you need to get atleast a 2GB instance (bye bye 1GB) and if the 2GB instance for whatever reason (like needing 64GB VM for a small site) fails to build/upgrade discourse, you’re SOL :frowning:
The only solution would be likely switch over to EC2 or something like Digital Ocean where you can dynamically scale up your RAM/CPU to complete the discourse upgrade and then scale it back down after the upgrade completes. I still have a hard time fathoming that we need more resources to upgrade the software than to run the software.

Finally, it would be nice if the upgrade process gave some sort of error if it needs more RAM but couldn’t get it. Failing silently and causing the entire system to slow down isn’t right (BTW, for reference, I tried overcommit_memory with 1 and 0 on my 1GB instance - but like I said, no errors, even the RAM/swap wasn’t maxed out at the time of hanging from the screenshots above).