|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
In the message dated: Wed, 19 Aug 2009 14:34:29 EDT,
The pithy ruminations from Richard Freeman on
<Re: [PLUG] Swap on SD> were:
=> Art Alexion wrote:
=> > So what happens to a Linux system without swap that runs out of physical
=> > memory?
=>
=> Linux has a routine called the out-of-memory killer that takes case of
=> this. The name does a good job of implying how it works. Processes are
=> killed and their memory is freed. The algorithm attempts to get the
Absolutely.
=> most space from the fewest killed processes, with some emphasis on
=> trying to find ones the user won't mind losing too much.
You can make an attempt to "tune" the kernel's response to running low on
memory with sysctl (see "vm.swappiness").
However, in my experience, once the OOM activates, you're almost certainly
going to need to reboot. I've seen OOM kill things like:
syslog (meaning that whatever OOM killed after that doesn't get
logged)
sshd (making system administration & use of remote servers just a
touch more difficult)
portmapper (try running an NFS server without it!)
My general rule is that the oom-killer introduces a high enough level of
uncertainty about the future stability of the system that a reboot is the
safest course of action. Yuck.
=>
=> Processes that were recently started that use lots of RAM and are niced
=> and don't have admin privileges tend to be the first to go.
For some definitions of "recently" and "lots" and "niced" and "privileges". :)
See:
http://lwn.net/Articles/104185/
=>
=> > how does it manage that extra memory demand?
=>
=> Once memory has been freed - just like any other request for RAM.
=>
=> > My guess is, whatever
=> > it does is not as fast as if it could use swap.
=>
=> Oh, I suspect that the OOM killer is a whole lot faster than swap, for
=> the same reason that torching your house is a whole lot faster than
=> renting a uhaul and a storage shed.
Absolutely.
=>
=> > If that wasn't the case, it
=> > would seem that no system would ever benefit from swap.
=> >
=>
=> Well, in the sense that in an office with a really big paper shredder
=> has no need for filing cabinets, that would be correct.
Nice.
Sure, swap is slow. RAM is fast. On the other hand, if you're out of RAM, even
"slow" swap is almost infinetly better than the alternatives (oom-killer,
malloc() fails, etc).
=>
=> Suffice it to say, running out of RAM on a linux system isn't a good
=> thing. The OOM killer is a good solution to some process going nuts and
=> allocating GBs of RAM, but otherwise it is the sledge hammer solution.
=>
=> Keep in mind that swap also allows for infrequently accessed data to be
=> swapped out in favor of disk cache, so it can in theory benefit a system
=> even when all of the physical RAM is not needed for process working space.
=>
=> Gordon Dexter wrote:
=> > Actually that piques my curiosity... how exactly does the kernel react
=> > to the traumatic loss of it's swap partition? Anybody have any
=> > experience or expertise here?
=>
=> With even less grace than it handles running out of physical memory.
=> You can almost guarantee a panic, though there might be situations where
Yep.
=> the kernel can recover. It isn't uncommon to run your swap on raid on a
=> high-availability system. If you want to experiment just boot a live CD
Absolutely. Plus, RAID-1 gives nice fast reads (when tuned well) when it's time
to swap processes back in.
=> and set up some swap on a removable drive - you won't lose anything that
=> way. If you need to fill up ram set up a tmpfs.
Hmmm...somewhere I've got a trivial "C" program (~25 lines) that'll alloc()
huge amounts of memory for testing....be I can't find it. :)
Mark
=> ___________________________________________________________________________
=> Philadelphia Linux Users Group -- http://www.phillylinux.org
=> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
=> General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
=>
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|