MLUG: [MLUG] Swap vs. No swap
[MLUG] Swap vs. No swap
Email address obfuscation in effect -- please click here to turn it off.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Hey all, there's an interesting - albeit quite L-O-N-G - thread on kerneltrap.org about the virtues/vices of swap.  The dicussion roams all over the place, but they pose some interesting points.  Here's the link:

http://kerneltrap.org/node/view/3202?from=140&comments_per_page=35

The comments that are actually relevant tend to boil down to these:

1)  Several people feel that under normal conditions there is no penalty to having swap available, and disk is cheaper than RAM.

2)  Several other people have shown anecdotally that in fact there ARE penalties to having swap enabled, even when the total RAM needed for apps is less than the amount of RAM installed.  Say, 1GB RAM > 400MB X + Mozilla + a few gnome-terminals + daemons, etc.  Linux still swaps; performance suffers.

3)  Still others muddy the waters by throwing in the, "But what are you going to do when you run out of memory (OOM)?  You NEED the swap to avoid this!"

4)  Yet another group wandered away into discussions specifically about the performance issues of Linux swap and virtual memory (NOT the same as swap!).

5)  Lots of name-calling, redundant posts, and useless discussions about using ramdisks as swap (which is widely regarded as stupid... probably).  More on that in a minute.

Anyway, the discussion seems to peter out and starts repeating itself before any decent conclusion based on logical arguments was reached, so I thought I'd drop it in here and see what we get.  Here's what I see so far:

LIE #1:  "There's no penalty to having swap."  This is wrong.  There is a penalty for everything.  Having swap means you have to have an active system to manage the swap space, which consumes resources itself.  Further, any page fault is a *huge* performance hit compared to real RAM.  Disks are ~8ms + read time.  RAM speeds are on the order of 10ns.  That's a factor of 10^5!  By this argument, swap should be avoided as much as possible.

LIE #2:  "You need swap or you might run out of memory!"  This is also wrong, mostly.  If you're running out of memory, it means you system is too small and you need more RAM or you need to run fewer processes.  Swap space is - and was designed to be - merely a band-aid way to simulate additional RAM to account for the case where additional physical RAM was not *possible* for some reason or other.

But no matter how much RAM or swap+RAM you have, there will always be the possibility that you will run out of memory.  It is the system administrator's job to make sure that everything necessary can run in RAM without the need for swap.  Otherwise, by definition the system is designed to swap and performance will be poor.  That's a decision (or a financial reality), not a universal "need" for swap.

The other OOM case trotted out is the runaway process.  "Swap helps you recover gracefully!"  Blah, blah, blah.  It doesn't matter.  The runaway process case is an EXCEPTION.  On a normally running system, there shouldn't be runaway processes.  Those, by definition, are a disaster.  The design of the system should consider the normal, steady-state system - not the exceptions - when deciding on the best implementation.  Exceptions should be handled *as exceptions* by some routine or other specifically for that task.  And they are.  The kernel hunts for the most likely culprit and kills it.

People argue that the system slows down when the runaway process starts swapping and that tips you off that you have a runaway.  I can't see how this is good.  Consider:

a)  No swap:  The process runs away, all RAM is allocated, the kernel starts killing likely processes until the culprit is dead.  The survivors continue to run normally at all times.  There is a possibility that innocent bystanders will get killed.

b)  Swap:  The process runs away, all RAM is allocated, the system starts to swap to provide more VM to the runaway.  The *entire* *system* now slows down.  Eventually, the same conclusion.  Kernel kills culprit.  Other innocent processes may die.  Big performance penalty in the mean time.

TRUE... but:  Swap can be used in a steady-state case to provide more physical RAM to applications without a performance penalty.  All of these arguments, however, revolved around swap schedulers that behave differently from the ones currently in Linux and Windows 2K/XP/2K3.  Some good ideas were brought forth, but none are usable *today*.

...except a periodic "swapoff -a ; swapon -a" to force stuff back into memory that really belongs there.  Best done only if it will fit and only during periods of otherwise very light system load.

Opinions/discussion?  I'm strongly considering doing away with swap on all of the systems I run that have > 2-3x the RAM they need for normal operations.  This isn't all my systems (certainly not my current craptop), but it does include the UMC campus DNS and DHCP servers, running 2.4.21 from RHEL.

Thanks!

Justin McNutt
Network Systems Analyst - Principal
DNPS, Mizzou Telecom
(573) 882-5183

"All knowledge is learning and therefore, good."
        --D.A.R.Y.L.


_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members