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

installation
22

Okay, I can understand that. Would not be possible to streamline the bootstrapping/compilation process to take longer (CPU/serialize) but within constrained resources (i.e. RAM)?

1 Like
23

I think thatā€™d be a great idea. And one reason is this: if one canā€™t rebuild on a tiny server, then one canā€™t install on a tiny server. And if one installs on a medium sized server, one wonā€™t get the swapfile created that will be needed on the tiny server. (Ideally the install script would make the swapfile anyway, and also set the two kernel tunables which should be set.)

24

This too is a great idea. In the same way that ideally a software engineering process monitors build times, because otherwise the build times get ever longer, for Discourse the process would ideally test and monitor the installability on small instances. Make it a target.

1 Like
25

Iā€™ve experimented with making bootstrapped images that migrate and precompile assets on launch (with ENV settings to skip those tasks). This mostly works (not so much for huge sites and for things that count on the launch to happen in a certain amount of time.

Those do count on redis and postgres existing, however.

With a mostly-standard 2-container install, it might be possible to make it mostly work.

Ooooooooooooooooooooooh, but the precompiling assets I guess is the step thatā€™s causing the problems. . .

26

Iā€™m reading about this Ember 5 upgrade thatā€™s working itā€™s way through the system. What impact would that have on the build resources?

27

I think the documentation needs an update, discourse/docs/INSTALL-cloud.md at main Ā· discourse/discourse Ā· GitHub

  • The default of 1 GB RAM works fine for small Discourse communities.

1GB is no longer an option. The minimum requirement is 2GB to build discourse.

1 Like
28

Iā€™ve got a bunch of sites I upgraded recently with 1GB of ram. I did bump their swap to 3 or 4GB, though.

I certainly donā€™t recommend it, but for some people itā€™s a huge cost barrier and they get by. But maybe ā€œworks fineā€ is an exaggeration.

3 Likes
29

Yes, maybe specify that, 1GB RAM + 4GB swap. It failed with a 2GB swap.

30

Do you have any plugins? Many themes?

31

9 Plugins and just 1 theme. Again all this worked great until 3.1.x on the 1GB RAM with 2 GB swap (it was a little slow, maybe 20 min to rebuild but always worked)
Trying to upgrade to 3.2.0 it failed consistently (see above).

32

Yeah. Definitely no plugins with 1GB of ram. That seems like something to add to the install doc.

Iā€™d be interested to know if it worked without the plugins.

33

As an extreme shorthand I can see why youā€™d say this, but donā€™t you agree that the go/nogo for running Discourse is RAM+swap? 1+3 is just as good as 2+2 from a point of view of go/nogo.

Itā€™s only performance (responsiveness) which cares how much RAM you have.

RAM+swap is the right thing to check and test. Memory=RAM+swap.

BTW if something is not working with no obvious evidence as to why, and especially if you suspect memory shortage, itā€™s worth checking for the out-of-memory killer, also known as the OOM-killer. I recommend

dmesg|egrep -i "memory|oom|kill"

Edit: for convenience Iā€™ll add that to my list of standard instant diagnostics:

cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
4 Likes
34

I encountered the same issue, but not during an upgrade, rather while performing a fresh installation of version 3.2.0.

Iā€™m using AWS EC2, just like @RBoy.

Iā€™m seeking a solution to install version 3.1.5 instead of 3.2.0, as the old forum didnā€™t provide any assistance.

UPDATE:

sorry, I found this:

1 Like
35

I would be very interested to know if you were able to do a fresh install of 3.1.5 using the tag method mentioned in your link. Please do post back if you try it out.

As for 3.2.0 install on a 1GB system, you could try this, set your SWAP size to 8GB and see if that works. Itā€™ll probably CRAWL but it may work.

36

Thanks for your thoughtful guidance.

I recently completed a fresh installation of the Discourse 3.15 Docker version and wanted to share how straightforward the process was, especially for those using the AWS EC2 free tier, like myself.

Hereā€™s a concise guide based on my experience:

  1. Navigate to your Discourse configuration file located at /var/discourse/containers/app.yml.

  2. In the params section, update the version parameter to match the desired Discourse version. For instance:

    params:
  # ...
  ## Specify the Git revision for this container (default: tests-passed)
  version: v3.1.5 # Use the specific tag name here

  3. Save your changes and exit the editor. Then, execute the following command to rebuild your Discourse application:

    /var/discourse/launcher rebuild app

The process worked seamlessly for me, proving that maintaining a low-cost or even zero-budget Discourse setup is entirely feasible.

I hope this guide helps others looking to manage their Discourse installations efficiently and cost-effectively.

2 Likes