Swapping is slow enough that I would not take “barely out of room now” as a reason to add more than 1GB to the default suggestion at this point. Each 1GB is a lot of swap, as experienced on a dedicated Discourse instance.
Yes, by default Linux uses swap in priority order, and it’s possible to use the same priority across multiple devices to explicitly stripe swap. But adding loads of swap for small sites isn’t particularly valuable, I would suggest.
So if after roughly a decade people are only occasionally tripping over 2GB, I’d suggest moving to 3GB rather than 4GB as the default. And the necessary quantity of swap for a dedicated Discourse instance shouldn’t increase particularly with memory, because the content that would actually be swapped out doesn’t change particularly much.
The idea of growing swap with more memory is primarily from general purpose computing, based on a generalized assumption that the more RAM you need, the larger the demand is likely to be. But swap pressure on a specialized Discourse instance is not likely to follow that pattern, I think.
THP are specific to platforms supporting huge pages, which aren’t all platforms. The generic way to handle that is to see whether it exists. On one Raspberry Pi I have:
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
By contrast, overcommit is a general VM parameter for Linux for the past few decades. On the same Raspberry Pi:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
Parsing output from free in shell is kind of a pain. Speaking as the original author of procps, for this I’d just look for SwapFree in /proc/meminfo. ![]()