The VPS we just bought came with 3G RAM + 1G partition swap - should I also set a swap file, or should this be enough?
AI-generated summary
In a discussion titled â3G RAM + 1G Partition Swap - is it enough?â, user meglio asks whether their VPSâs 3GB RAM + 1GB swap partition is sufficient to prevent memory allocation errors in Discourse, especially during peak loads like upgrades or image resizing. Falco and Ed_S affirm that itâs adequate for small forums, noting that total RAM + swap matters more than RAM alone. sunjam disagrees, recommending 8GB RAM, but pfaffman counters that 1-2GB RAM with 2GB swap works fine for low-traffic sites. Jonathan5 and JammyDodger clarify that Discourse-setup automatically creates a 2GB swap file if none exists, though meglio seeks clarification on whether this applies if a 1GB partition swap already exists. Ed_S confirms multiple swap areas are safe and advises enabling vm.overcommit_memory = 1 to prevent failures during upgrades â a setting not included in default install scripts due to perceived niche benefit. Ed_S recommends adding up to 4GB swap if disk space allows, as a low-risk mitigation. The consensus: 3GB RAM + 1GB swap is sufficient for small forums, but adding more swap or RAM reduces risk, especially as forums grow. Monitoring tools like free and vmstat help track usage, and overcommit tweaks can prevent crashes â though not universally adopted.
Thatâs enough for a small Discourse instance.
I mean, not in terms of whether it will run fast etc, but in terms of whether it will/will not generate any errors like e.g. not being able to allocate extra memory etc. Does my question make sense? Also, will adding a file swap with an even lower priority help? Just to be sure.
Just pay for a more powerful VPS with at least 8gb of ram. Youâll be wasting time otherwise.
This is not answering my question.
I cannot imagine running Discourse on less than 8gb of ram.
Discourse team member saying it is fine, Iâm sure if it is fine.
Good luck.
Discourse-setup will flag any memory issues.
This does not answer my question either. Maybe I formulated my question in a bad way?
I have a relatively quiet forum on a Digital Ocean 2GB memory/50GB disk droplet and it works fine.
At the time the Discourse installation guide was recommending 1GB minimum but I upgraded at some point.
If you provide more information about how big/busy your forum is Iâm sure youâll get a more detailed answer.
I think the Discourse installer automatically sets up a swap file (I didnât do anything manually) - so that answers part of your question, I think.
I think it creates a 2GB one at install if it detects you donât have one already.
Edit: I think this is more accurate:
The official minimum supported is 1G RAM + 2G swap - and that is enough, if you have a pretty small forum. Although, every update gets just a little bigger so I expect there will come a time when itâs not enough.
For having the forum work correctly and not crash, the sum total of RAM and swap is the important figure.
For having the forum responsive and not be too slow, more RAM is preferred. So, if 1G RAM + 2G swap is enough, then 3G RAM + 1G swap will be enough, and might have better performance.
I have two forums, both quite small, one runs on 1+2 and the other on 2+2.
Last year I wrote this:
Edit: if you have the disk space to add swap, do it - thereâs no good reason not to, and it might be needed. The free command will tell you how much is in use, the vmstat command can give you a running commentary. But average use is not interesting - itâs peak use thatâs interesting.
Okay, my question is more theoretical. I canât predict the popularity of the forum at this time. What Iâm trying to understand is, what should I do to mitigate the theoretical possibility of running out of RAM in some scenario. Iâm not aware of when Discourse consumes memory the most - either when making backups, or when resizing images, or when updating through the admin console, or ⌠I have no idea.
So my thing was, what swap file should I make to make sure Discourse will not die but just get very slow in case there is not enough memory. In the same time, I found out that there is already a 1G swap partition, so my thought was, what if 3G real memory + 1G partition swap is not enough⌠should I also create a swapfile of a few gigs with an even lower priority (vs the partition gig). Hope my question makes more sense now.
If it does, then yes. It would be useful to update the installation readme file. Coming from the old days when it was officially mentioned to create a swap file right in the installation readme, Iâm now a bit confused whether it is done automatically, or not needed anymore, or any other reason why it was removed form the official howto.
⌠what about if it detects the 1G one but the partition-based one?
So, the continuation of my question would be, is it a good idea to have two swap areas, one partition-based, and the other one file-based.
No problem at all to have multiple swap areas (or indeed multiple swap files)
I believe the biggest memory peak is during an upgrade - and the risk there is of the forum being down until you can get help.
Itâs worthwhile also setting the overcommit to the more generous setting: youâll find itâs already noted in your upgrade log, if you havenât already adjusted it
WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add âvm.overcommit_memory = 1â to /etc/sysctl.conf and then reboot or run the command âsysctl vm.overcommit_memory=1â for this to take effect.
This has been mentioned many times before but thereâs resistance to adding it to the standard Discourse installation recipe. Itâs the kind of setting which canât be done inside the docker image but has to be done on the host.
All you can do is reduce risk, and if you have more funds, you can reduce risk to a greater degree. This question is in the territory of tradeoffs!
If I had unlimited disk, Iâd certainly add up to 4G of swap before even thinking about it - it wonât do any harm. If I had unlimited funds, Iâd have the maximum RAM I could get. But in my case, I donât.
If youâre expecting your forum might grow, you should expect to increase the resources you need to run it, over time, rather than expecting to size the machinery once at the outset.
I havenât yet increased the sizes of the machines I use for my forums, but I expect I will, maybe this year or maybe next.
It should be. I routinely set up 1 and 2gb droplets with 2gb of swap and they work. Currently a rebuild takes a lot of ram, but that should work.
Your need a better imagination.
I run that much only on sites with on the order of a million page views per month and fairly large databases.
I mentioned this as soon as I first installed Discourse (Warnings: overcommit_memory and Transparent Huge Pages). Why is it worthwhile doing and what is the reason for resistance? I havenât changed the default setting.
Hereâs something I wrote before:
Particularly
As-shipped, the kernel will reject allocations which it canât satisfy. With this tweak, it will accept those allocations, and failure might be averted, or it might happen later when the allocation becomes usage.
If your total of RAM and swap is big enough, youâll never need to change this setting. If your total is not big, changing it might help.
Also
Itâs to increase the amount of virtual memory available. (That is, the sum of RAM and swap.) If you run out of RAM, you start to suffer performance problems. But if you run out of virtual memory, processes will fail to start or will die or be killed. It gets brutal.
Those of us with both small RAM and small disk may not be free to add loads of swap, but 2G seems to be a good minimum. (If you had 16G of RAM you might not need any swap, but thatâs another story. Itâs the sum of the two which matters, when the problem is things failing.)
As for the resistance, I think itâs because of a perception that this change is for the benefit of redis, and most people wonât need it.
Edit: this recent thread is possibly a case in point, where a smallish instance ran out of memory, and didnât have overcommit set. But we donât know if setting overcommit would have solved this problem - the person upgraded to 8G RAM.