Dimensioning of the SWAP space

[LE_746F6D617A7A69]

Generally, swap storage space is just a nightmare - it is slow like hell, and You should avoid to use swap memory at all costs (unless You have no choice). If You can't increase RAM capacity to suit Your needs, better limit the number of programs that are running simultaneously.
(btw I think that lowering the vm.swapiness is the first thing to do, no matter if it's a server or a desktop PC)

Swap memory means nothing but problems - low speed of swap memory is the least problematic factor - real problems are starting in case of time-critical or real-time applications.

Swap memory has just one purpose: to protect the system from triggering the OOM Killer.

Swap partitions: don't create swap partitions, unless You have a server with a dedicated raid-based swap storage system: better use sparse files as a swap.
Sparse swap files are flexible: i.e. You can adjust their size without re-partitioning of the drive.
Side effect is, that when You have a single Raid array for a /root directory, You can put a swap file on it, assuring that the swap space also has a redundancy, without creating a dedicated Raid for swap memory. Having a Raid system for /root without having redundant swap storage makes no sense - swap storage failure means unavoidable crash of the OS.

Swap capacity:
Yes, there's no formula for that, but assuming that swap memory is used only in emergency situations, its size should be chosen to match maximum amount of memory expected to be used by all the applications that are supposed to run simultaneously, decreased by the RAM size.

In typical cases (desktop), a swap space of 2..4GB should be more than enough - in case of servers, better buy 64...256 Gigs of ECC RAM

[CwF]

Swap memory has just one purpose: to protect the system from triggering the OOM Killer.

Observable, this is obviously false.

Gigs of ECC RAM

This is true! Gigs good...and ECC should be standard.

[p.H]

You should avoid to use swap memory at all costs

You cannot be more wrong.

Swap memory has just one purpose: to protect the system from triggering the OOM Killer.

You cannot be more wrong again.

use sparse files as a swap

Sparse files cannot be used as swap. The kernel needs to map all the swap space to the underlying block device. Of course this is not possible with a sparse file which does not have allocated blocks for all its space. Swap files are a dirty hack which does not work with all files and filesystems.

Having a Raid system for /root without having redundant swap storage makes no sense

At least one true statement.

when You have a single Raid array for a /root directory, You can put a swap file on it, assuring that the swap space also has a redundancy, without creating a dedicated Raid for swap

You can also use a partitioned array, or LVM logical volumes over the RAID array.

[CwF]

Sparse files cannot be used as swap

Actually I believe my advocated 'zramswap' is sparse!
...and yes, it's swap!

[p.H]

'zramswap' is sparse!

Yes, but it is a block device, not a file. The zram block device driver allocates blocks on demand (and deallocates on discard). In a sparse file, the filesystem layer is in charge of block allocation, but the kernel by-passes the filesystem layer when using a swap file.

[LE_746F6D617A7A69]

You should avoid to use swap memory at all costs

You cannot be more wrong.

Uhm.
Avoid to use != Don't create a swap.
Try to use any modern OS with a 1GB of RAM and 16GB of swap - probably even a web browser will start to choke because of swappiness.

Swap memory has just one purpose: to protect the system from triggering the OOM Killer.

You cannot be more wrong again.

But of course this is the *only* reason.
All the swap-related kernel activity, like swapping-out "unused" memory pages (containing code or data that was not referenced in some defined period of time) is serving exactly this single purpose: avoid OOM situations.
The costs are obvious: the higher swap usage, the higher probability of hitting swapped page, what means deadly slowdown in task switching/data access.
The problem is very serious, most of time-critical applications are usually entirely disabling swapping of their RAM areas, f.e. by calling mlockall(MCL_CURRENT|MCL_FUTURE).

use sparse files as a swap

Sparse files cannot be used as swap. The kernel needs to map all the swap space to the underlying block device. Of course this is not possible with a sparse file which does not have allocated blocks for all its space. Swap files are a dirty hack which does not work with all files and filesystems.

Yes, I've made a mistake regarding the term "sparse" - it was late night, and my knowledge of english have failed me - again

[CwF]

But of course this is the *only* reason.

It's a matter of perspective. I relate OOM with a single task that runs out and while in focus, needs to pause for slow swap. That is one sense. When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all. In this sense, the use of swap is to intentionally manage an over committed condition.

The use of swap has evolved.

[p.H]

Avoid to use != Don't create a swap.

I did not make that confusion. I understood "avoid to use swap" as "avoid to swap out pages".

Try to use any modern OS with a 1GB of RAM and 16GB of swap - probably even a web browser will start to choke because of swappiness.

No, it will choke due to insufficient RAM. The main purpose of swap is not to replace insufficient RAM but to unload rarely used pages from RAM and make space for a better use, typically page cache (aka disk cache).

All the swap-related kernel activity, like swapping-out "unused" memory pages (containing code or data that was not referenced in some defined period of time) is serving exactly this single purpose: avoid OOM situations.

Nope, swapping out unused pages has nothing to do with OOM. In an OOM situation the kernel will swap out even frequently used pages, creating thrashing.
What is to be avoided is thrashing, not swapping out.

I've made a mistake regarding the term "sparse"

Then what did you mean ?

[LE_746F6D617A7A69]

No, it will choke due to insufficient RAM. The main purpose of swap is not to replace insufficient RAM but to unload rarely used pages from RAM and make space for a better use, typically page cache (aka disk cache).

Which is what I've already said - insufficient RAM space leads to higher swap usage -> performance drop.

Nope, swapping out unused pages has nothing to do with OOM. In an OOM situation the kernel will swap out even frequently used pages, creating thrashing.
What is to be avoided is thrashing, not swapping out.

Uhm, excluding the fact that in most cases the kernel is swapping the memory above vm.swapiness treshold.

I've made a mistake regarding the term "sparse"

Then what did you mean ?

Hmm... "dense" perhaps?

But of course this is the *only* reason.

It's a matter of perspective. (...) When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all.

De-compression is at least 10'000 times slower than normal RAM data access (typically around 60 nano-seconds), but indeed it can be faster than reading swap data from HDD or from a 3-months old SSD

[MicroScreen]

All the swap-related kernel activity, like swapping-out "unused" memory pages (containing code or data that was not referenced in some defined period of time) is serving exactly this single purpose: avoid OOM situations.

Nope, swapping out unused pages has nothing to do with OOM. In an OOM situation the kernel will swap out even frequently used pages, creating thrashing. What is to be avoided is thrashing, not swapping out.

Oh man, as you can see, that's exactly the kind of discussion I wanted to avoid here, but there are always people who believe they know better than the rest of the world and then 90% of all statements turn out to be demonstrable totally wrong. It would have been better if he had gone to bed on time and read a good textbook on the subject first, than to spread his superfluous "intellectual" effusions here.

[LE_746F6D617A7A69]

Yeah, reading with understanding can be a challenging task ...

[MicroScreen]

I relate OOM with a single task that runs out and while in focus, needs to pause for slow swap. That is one sense.

Not really! Nowadays, OOM is a rather theoretical state that can only be reached when a task has already started at the limit and has to share the remaining memory with other tasks. What happens after that has p.H. already aptly explained. Process data loss would therefore occur much sooner than actually reaching the physical memory limits. Apart from that, an operating system should be set up in such a way that it warns of this in good time.

When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all. In this sense, the use of swap is to intentionally manage an over committed condition.

That's exactly right, so it's a fallacy to assume that the compression or decompression process could slow down something here. In fact, the access time for this data is exactly the same as for everything else in RAM!

[LE_746F6D617A7A69]

I relate OOM with a single task that runs out and while in focus, needs to pause for slow swap. That is one sense.

Not really! Nowadays, OOM is a rather theoretical state that can only be reached when a task has already started at the limit and has to share the remaining memory with other tasks. What happens after that has p.H. already aptly explained. Process data loss would therefore occur much sooner than actually reaching the physical memory limits. Apart from that, an operating system should be set up in such a way that it warns of this in good time.

What happens is that newly starting process forces the kernel to swap RAM areas of other processes - and this is the beginning of a disaster.
Mr p.H is right only in one aspect: low RAM means smaller FileSystem/disk caches, but this has nothing to do with swapping of the memory.

When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all. In this sense, the use of swap is to intentionally manage an over committed condition.

That's exactly right, so it's a fallacy to assume that the compression or decompression process could slow down something here. In fact, the access time for this data is exactly the same as for everything else in RAM!

It's rather typical, that forums are full of trolls which are spreading bullshits.

Explanation:
Let's assume a very simple (theorethical) situation: the only task that the kernel is performing is swapping of the RAM pages <SWP> and there's just one single-thread user program running <UProg>
Case 1:
The amount of free memory have dropped below vm.swapiness -> SWP is starting to save the memory pages to a swap storage.
This process can be executed in parallel to UProg, but it affects the UProg in at least two aspects:
1. On multicore CPUs at least the L3 cache is shared -> the SWP is partially invalidating the L3 cache, what means that UProg must share the cache with SWP,
2. In turn this means greater probability of cache misses -> slower data/code access -> slower execution of UProg.

Case 2:
UProg needs to access a memory page which has been swapped (saved in swap storage).
When UProg tries to access such page, it is "frozen" by the kernel until the page is loaded from a swap storage -> it is completely meaningless whether the page data is loaded or decompressed - the UProg can't continue until the operation is finished.
Even if the decompression is running on a separate CPU core, it does not change anything -> the UProg still has to wait until the page becomes ready (loaded or decompressed into UProg process' RAM area)

[MicroScreen]

It's rather typical, that forums are full of trolls which are spreading bullshits.

Right, that's why you should finally stop spreading this hypothetical bullshit!
Your utterances have clearly shown recently that you have no idea what you are talking about and p.H was completely right, he is competent and to be taken seriously. People like you should be constantly ignored!

[p.H]

low RAM means smaller FileSystem/disk caches, but this has nothing to do with swapping of the memory.

Yes it does. Filesystem cache and swap are the two sides of a single coin : virtual memory management.
Under memory pressure, the kernel has two options : either discard anonymous pages (process data) to swap or cache pages (filesystem data). Both may cause I/O to write the discarded data to swap or filesystem (if unclean), and will cause I/O to reload the data from swap or filesystem into memory when they are needed again.

The amount of free memory have dropped below vm.swapiness

Nonsense. vm.swappiness is not a threshold.