[Users] recommended swap space

[Kirill Korotaev]

Dariush Pietrzak wrote:
>>documentation says swap should be pyhsical RAM*2.
> 
>  This rule was created when HDD were many times faster compared to RAM then
> they are today(and when programs needed way more virtual space in relation
> to what could be available).
>  Imagine how long it would take read/write 32G from HDD..., also, most
> really large requirements for ram come from various layers of essentially
> caching. In the 90s it was quite typical to run servers with half of
> virtual space permanently swapped out ( 64M ram machine, with 128M swap,
> and never less then 64M swap used, 512M machine with 1G swap and never less
> then 512M of swap used etc..). 
>  It was possible to do that, because of large amounts of inactive code/very
> rarely called code in programs, thus you could safely swap out half of the
> code and safely assume that it won't ever be needed. 

BTW, code is mapped directly from binaries of the filesystem and never swaps out.
Instead, when you need some memory in Linux, kernel simple drops/frees such code pages
because it knows that it always can be loaded from the filesystem executable/library again.

Effectively this works as a swapping out, except for the fact that "write" (swap out)
operation is ommited and only "read" (swap in) is left.
So in some sense, swap out of code always works, even when you have no swap at all :)
And the fact that you don't notice this is another proof that swapout is not that
bad/slow thing for active memory working sets.

>  These days, most of ram goes to data, not to code, and alot of stuff works
> like hash tables - every single particular page of data is accessed relatively
> infrequently (thus, it would be swapped out) but there are a lot of such
> accesses and if you wouldn't want to make them wait for HDD.

When we were investigating apache live migration, it turned out,
that it's active memory set is ~20% of the whole RSS.
i.e. 80% of apache memory can be safely swaped out cause too rarely accessed.

Thanks,
Kirill