I agree that in our cost-constrained worlds scaling swap by RAM size is no longer a great plan. The next idea after that historically seems to have been that RAM is huge and you don’t need swap. After that comes the wisdom that some swap is useful because it allows better use of RAM. (In an unconstrained world we just have enormous amounts of RAM, but that’s a niche.)
What we are seeing in this past couple of months is more people having out of memory problems and failures to rebuild. More people finding web upgrades failing but command line working. From a simple support perspective, and from the perspective of the reputation of the product, I think we do need a change to the usual advice and the usual setup. I think 3G of swap is the simplest smallest change and we should do that if we don’t anything else.
But I still think that multiple smaller swap files is a wiser choice - and we have seen support threads on here which point to that. And I still think it would be best to try to size RAM+swap because that is the limiting factor, the thing which causes people to have trouble. It might be that there are different ways of doing that computation. The usual caveats apply about what tactics are maintainable, understandable, will have longevity.
As for transparent huge pages, my understanding is that it’s the “transparent” which causes trouble: the kernel can thrash about, merging and de-merging, for a performance hit and no great benefit. I’m pretty sure hugepages are ill-advised for smaller systems.