Swap space question

Phil Meyer pmeyer at themeyerfarm.com
Sat Sep 30 16:01:09 UTC 2006


nicolas angel wrote:
> Hi,  i would to ask something about swap space:
>
>  i quote from the book "How Linux Works—What Every Super-User Should Know"
>
> "Reserve two to five times as much disk space as you have real memory 
> for swap. It doesn't make sense to go any lower, because you may 
> actually risk running out of memory. If you go higher and actually 
> intend to use all of this swap space, you will likely suffer serious 
> performance problems because the system will spend all of its time 
> swapping (a condition known as thrashing). "
>
> i can't understand why if create a really big swap partition i will 
> have a performance decrease????It seems to me
>  that in the worst case scenario, i will be throwing disk space 
> [because the system will never use the swap partition if it doesn't 
> need it......why this would have a negative impact on the system......]

Because in older systems, the largest file size possible was 2GB.  The 
swap space is treated by the kernel as a 'file'.  So if you are running 
a 32 bit version of Linux, you MUST limit swap to 2GB 'chunks' if you 
need more than 2GB.  If you specify more, only 2GB will be used, no harm 
done, and you have more space to 'dump' the kernel into in case of a crash.

With a 64bit kernel the 2GB file restriction does not apply.

Also, all modern UNIX/Linux kernels are page based and not swap based.  
In an old UNIX kernel it was necessary to allocate swap space equal to 
the size of an application as it loaded.  It did that so that if it ran 
out of RAM it could write the running image to disk at the location 
specified at run time, and then pull it from there when it could later 
on.  That is why you needed at least twice RAM for swap, because you 
needed to map all running applications directly to a physical swap space.

Paging kernels don't work that way at all.
  Instead, they load pages of a program until the kernel gets 'enough to 
start'.  Then it begins to run it.  The 'enough to start/run' amount of 
memory is called the resident set size of the application.

Paging kernels have a fixed location for kernel requirements in RAM, 
then they add the amount of swap space to the end of physical RAM and 
use the whole as virtual memory.  The kernel uses a sliding set of rules 
to determine where in RAM or swap things get put.  The higher priority 
items like additional kernel requirements (load a new kernel module) are 
put closest to the fixed kernel on the scale.  The lowest priority items 
like disk cache are put at the opposite end of the sliding scale.  User 
space (and other things) are in between those and can grow and shrink as 
necessary, thus forcing the disk cache to give up pages, or giving pages 
back to cache.

However, the kernel knows where the line is in virtual memory where swap 
starts.  If user memory starts to squeeze the disk cache too tightly 
(there is a minimum threshold) then parts of the sliding scale do in 
fact get pushed onto the physical disk, and swapping occurs.

How much swap do you need?  In modern kernels it is a different 
question.  How much disk do you consume when you swap?  Never swap?  
Then you don't need a physical swap space.  All paging can be (and 
usually is) done in RAM.

Do I ever recommend no swap space?  No.  But now days the answer is 'some'.

1xRAM? Probably fine for most things
2xRAM? Ok, go ahead, but remember the 32bit rule.  Stick to 2GB swap on 
32bit systems.

For servers:
4GB RAM = 8GB swap (remember to do chunks of 2GB for 32bit systems)
8GB RAM = 8GB swap (there may be some applications that need more, but 
its not Oracle or Informix)
 >8GB RAM?  You need to study the application mix and whether or not you 
may get a RAM sized kernel dump, and if so do you want it in the swap space?
It is just fine to run a large Oracle database on a system with 64GB RAM 
and no swap.
But at that level of costs and system, you will need to consult with 
experts before doing something like that.

Good luck!




More information about the fedora-list mailing list