The rule of thumb (swap should be 2-3x RAM) has survived because it has minimal downside (you don't generally miss that amount of disk) and a small upside (you see performance degradation as the first symptom of memory overloading, rather than processes dying due to failed allocations).
Yes, if you know your workload very well, you can trim off the spare space and make it smaller. But the risk you run is that a change in circumstances will make itself known by failing jobs, rather than slow-running jobs. And the benefit you gain is very small.
A keen sysadmin could also trim swap down, if they're sure they'll notice warnings early enough in the event of a problem.
(This assumes 'normal' amounts of disk+RAM in a box (i.e. diskspace at least two orders of magnitude bigger than RAM, so you're sacrificing of the order or 2-3% diskspace). Unusual devices might reasonably make different tradeoffs).
The article misses a lot. Swapping happens often even when there isn't directly pressure on memory. Because Linux very aggressively keeps recently touched files cached in memory (usually, although not always, a performance win), it will swap out unused processes—again, even when there's plenty of memory to go around.
How aggressively Linux swaps stuff out can be tuned via /proc/sys/vm/swappiness, although it's arguably still too aggressive even when swappiness is given a low value.
I still don't follow the article's conclusion that you need 2x as much swap as physical memory. I generally go with physical memory + 100-200MB. That leaves enough space to suspend to disk even if you use a bit of swap in normal operation; I've never had problems with that setup on systems that have enough RAM to be tolerably fast. If in doubt, buy more RAM - it's dirt cheap at the moment.
However, I also think you should make your swap space as large as possible--many times larger than RAM, if possible. Then, instead of having on-disk indexes, on-disk caches, and on-disk temporary files, have your applications cache everything in memory-resident data structures. The operating system will automatically swap stuff in and out as necessary. The better your operating system's VM, the better the performance will be. Save explicit disk usage for things that must be persistently stored like database tablespace files.
Yes, if you know your workload very well, you can trim off the spare space and make it smaller. But the risk you run is that a change in circumstances will make itself known by failing jobs, rather than slow-running jobs. And the benefit you gain is very small.
A keen sysadmin could also trim swap down, if they're sure they'll notice warnings early enough in the event of a problem.
(This assumes 'normal' amounts of disk+RAM in a box (i.e. diskspace at least two orders of magnitude bigger than RAM, so you're sacrificing of the order or 2-3% diskspace). Unusual devices might reasonably make different tradeoffs).