I believe this will make you very memory constrained now.
It’s getting to the point where I’d actually recommend a minimum of 4GB for a Discourse instance (plus swap!) (even with 2GB + 2GB swap I find online updates painfully slow).
Thank you! Unfortunately that’s about four time the price for an improvement I would probably only feel during updates. Also, the cloud install guide still says:
The default of 1 GB RAM works fine for small Discourse communities. We recommend 2 GB RAM for larger communities.
Do we know where the memory pressure in this step is coming from? Perhaps it would be possible to trade off worse compression ratio or something for decreased memory requirements?
I think for my next update on my two servers, I will use the hosting provider’s flexibility to migrate to larger RAM before updating, and migrate back to my present minimum immediately afterwards. There’s a small amount of extra downtime, but if the rebuild is much quicker then it could be an overall win. The extra expense should be under $1 or perhaps even just 1 cent, for an hour of extra RAM (in my case, from $6 per month to $12 per month, charged hourly on Digital Ocean at respectively 1 cent and 2 cents.)
As noted in the linked thread, sometimes a reboot is helpful in any case, so it’s a good time to update OS packages and reboot, for me.
I’m hoping that this will cause less wear and tear on me, too.
I might in fact choose to go up from 1G to 8G, which will cost an extra 6 cents per hour, to give myself the freedom to delete my swapfile temporarily, and ease the disk space crunch.
Everything peaks at update time - in between times, the present minimal configuration still seems to be adequate.
It’s certainly part of a tradeoff of cost vs time. For myself, I’ve already committed to do an hour of babysitting for the upgrades, and I know fully how to do this sysadmin dance, so the time is already booked. I prefer to keep the monthly running cost as low as I can, even if it does take me some time - others will have other tradeoffs.
For sure, if spending money comes easily, get a comfortably large instance!
Just for reference, I just updated my two forums, both done within an hour elapsed, in both cases I temporarily resized to 8G RAM and back again. This particular step took about 5mins, with (temporarily) 4 CPUs and 8G RAM.
I, [2024-01-10T16:07:58.323464 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300] INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js
Here we see ember (column 12) is using 2.5G RAM (column 6) and more than one CPU (column 3)
Probably 4G RAM would have been enough for me, but as noted this whole thing only cost a few cents. (I see now that I could have chosen faster CPUs for an extra cent.)
Edit: I took a backup before I started and another after the job was done, and they were 35 mins apart. So the downtime as seen by the users was no longer than that.
Edit: note that Digital Ocean control panel says the resizing operation may take up to 1min per GB of data on the disk - in my case only 14G and as it turned out only 2 mins for each resize. But if you have a great deal of data on the instance, this resizing dance might take longer. (Then again, if you have a great deal of data you are perhaps not trying to run in less than 4G of RAM)
4GB RAM is still not enough in some cases. For example, I have an 8GB RAM sandbox with virtually no traffic but is a multisite setup to allow for having 5 disposable sandboxes. Rebuilding today failed due to Error 137 (OOM) and I had tried the trick @richard suggested above. However, to save myself from the hassle of doing this everytime, I’ve created a larger swap (4GB) which seems to have allowed the rebuilds to happen for the time being. It seems like we’re just upgrading servers in the last 1 year because discourse rebuilds are really getting RAM hungry for some reason.
Thinking about this, the benefit is really limited to full rebuilds - I cannot currently use online upgrades in a 2+2 config … and I don’t think I’m going to be doing this upgrade/downgrade dance just to update e.g. a single plugin …
I personally feel a permanent upgrade to at least 4GB is the only way …
Note: I’m not really grumbling about having to move with the times … but we should perhaps start reflecting reality in the documentation and advice to administrators?
It does unfortunately make Discourse a little less accessible to new, especially younger people though
I am in fact on board with this idea: keep the present minimum recommended configuration as a target and look into tweaks in the code or changes upstream to keep the lid on things. It’s a major change in the offering if minimum config is now twice the price. Which is why I opined elsewhere that excessive memory requirements is a bug.
Indeed that’s an out of memory error. If you have the disk space to add swap, that will be enough, although the process will take more time than if you were to add RAM. Your hosting provider might offer the chance to upgrade RAM temporarily and then revert, which will probably cost you a couple of reboots, a little down time, and a few cents of extra cost.
Edit: to be clear, memory = RAM + swap. RAM is fast and swap is cheap.
… and I don’t think I’m going to be doing this upgrade/downgrade dance just to update e.g. a single plugin …