Re: [MLUG] Swap vs. No swap

[Michael <EMAIL:PROTECTED>]

When possible I run without swap because it does make your systems 
faster and more stable. Of course that isn't always affordable but when 
I need performance that's what I do. For that matter this thin-client 
I'm using is read-only for all filesystem functions because it's faster too.

>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.
>  
>
This is the main reason to avoid swap. Just watch what happens to your 
system load as you add swap. Max out your ram and things die. Max out 
your swap and the system thrashes painfully which IMO is worse.

>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.
>  
>
Swap is fine for a bandaid but I try not to use it anywhere I need 
performance. Servers and embedded systems especially I suggest going 
swapless. If you must use swap then try to break it up across multiple 
disks and try to put it near the first of the disk.

>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.
>  
>
Exactly. Even with swap you can run out of memory.. only things will 
behave much worse when you do run out. You're better to just learn to 
live in what physical memory you can actually afford. With a gig of ram 
selling for $100 that shouldn't be to rough these days.

>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.
>  
>
This is the one I was fighting with people about. This is IMO where swap 
is at it's worse. Instead of a runaway process maxing out and dying it 
goes into swap and grinds the system to a halt. Admins should be using 
memory limits to auto-kill run away processes anyway so this is all 
bunk. I do think Linux needs some tools to change memory limits during 
runtime and to configure which processes should die first in case memory 
runs out.

>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.
>  
>
Or.. with enough swap.. the system grinds down to a horrible slowness 
which can last forever.. never quite dying but to slow to be usable in 
the meantime.. meanwhile giving your hdd a serious beating which causes 
it to fail lossing your important files.

>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.
>  
>
I generally leave swap off and only turn it on in special cases where I 
need it for a specific purpose. Say if once a night I run a task that 
does a system backup and requires more memory than I have physical RAM. 
The cron job switches the swap on, does the backup, and switches the 
swap back off.

>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.
>  
>
This 233Mhz w/ 64MB RAM I'm using as a thin client is running swapless. 
With swap it periodically grinds to a halt when I load to many windows 
in X. Without swap it doesn't do that but will occassionally run out of 
memory and restart X. The real clincher though is that without swap it 
can run considerably more open windows than with swap before it tops 
out. As I said, I also made the fs read-only on it. That helps keep it 
from grinding to a halt too. No hdd involvement makes the entire thing 
run much better.
_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members