Re: How much swap?
From: Gordon Messmer <yinyang(a)eburg.com>
Subject: Re: How much swap?
Uno Engborg wrote:
>
> Would I need a swap anyway. There is some old rule of thumb to have
> twice as much virtual memory as you have physical RAM, but that
> sounds a bit ridiculous as it would take a lot of time to swap
> in/out this much memory from disk.
I used to think it was kind of ridiculous, myself, until I discovered a
quirk of Posix's behavior. If I get any of these details wrong, I
invite corrections:
When a process called fork() on an old unix system, the OS required an
amount of free memory equal to the size of the process, plus the size of
a process table entry. If this memory wasn't free, fork() would fail.
After fork(), the OS would copy the full set of memory from the parent
process to the new process. Since fork() is so often followed by
exec(), which throws away all of that memory, modern unix systems don't
copy the whole set of memory when a process forks. However, they still
require that there is enough memory to do so (at least normally; Linux
has an "overcommit" feature that you can enable).
Not sure if the fork/exec issue applies to paged memory versus swap (i.e., where the
entire process is swapped versus memory pages). It's been a long time for me too :D
I'm also not certain if this applies to Linux, but I recall that certain other
Unices require twice the page space as physical RAM depending on configurations.
For example, some OSes will automatically write to both the in-memory pages and the
corresponding page on disk. The idea being that if the in-memory page needs to paged
out, it can do so with just an update to the page table rather than a full write.
This makes a page-out instantaneous.
I understand that in certain VM implementations it was simpler to just have a direct
mapped copy of all pages on disk. This required that in order to increase the
available memory (real + VM) you'd need at least as much page space as you had real
memory.
With very large memory systems (above 4G for example), there are probably other
considerations. The size of the page table on a 32-bit system may be fixed, but on
machines with huge memories, the page table itself may grow/shrink. The consequence
is that trying to allocate too large a page area could end up shrinking your usable
physical memory. On an already loaded system that's near capacity adding page space
could cause worse problems.
I'm not sure that I'd run entirely without page space, however. I seem to recall
that unused pages can get paged out entirely. I.e., if the process is not doing much
it won't cause a memory hit. Also keep in mind that 8G of disk space may not be all
that much relative to the size of disks today. That is, 32M of page/swap space back
in the day, was probably relatively more than 8G today.
With 8GB of RAM, that may not affect you directly, but it may, too.
Lets say that you have no swap, and you were using a 3d modeler, or
high-end graphics package. If that application was using 5GB of your 8,
and needed to launch a helper application, like an out-of-process perl
or python script, it wouldn't be able to do so. Even though that script
only needs a few MB of the GB you have free, the parent is too big to
fork(), so it can't spawn new processes.
So, when you decide whether or not to follow the traditional advice
offered about the amount of swap to allocate, you should first
understand how the Linux VM works:
http://www.redhat.com/magazine/001nov04/features/vm/
...if you don't want to spend the time learning the details, I'd just
stick with the advice offered.
Take all statements with a grain of salt. I'm old and doddering now, and bit rot
has surely set in on my recollections.
--
* The Digital Hermit http://www.digitalhermit.com
* Unix and Linux Solutions kwan(a)digitalhermit.com