On 7 March 2012 10:12, Jim Cheetham <[email protected]> wrote: > Swap is overrated. These days we have sufficient RAM to keep the OS > running properly, and when machines descend into swap the machine > generally dies because we overcommit and have slow disks. Switch off > swap, and let the OOM killer do its job - on a well-run server a > critical service should be restarted by init anyway ... > > $ free > total used free shared buffers cached > Mem: 8149024 7968776 180248 0 192868 4736620 > -/+ buffers/cache: 3039288 5109736 > Swap: 0 0 0 >
I have to disagree. I've ran swapless before, and you make sacrifices. Often,, the data that does get moved to swap is useless anyway, and never needs to be swapped back, and the free space is used for other things, like File Caching and IO Buffers. More files in the cache means less access time to load those files. And with a balanced swap setting, the unused segments of memory get swapped out without you noticing. And then theres the OOM Killer. I've personally learnt to hate the OOM killer, it never works right, and its impractical on a desktop. And "it should be restarted by cron" is unacceptable in many cases, because the OOM killer forces things to terminate uncleanly, which can cause corruption. That, and the OOM killer frequently kills the wrong process, it kills the long running background services before it kills the active service that is causing the OOM condition to trigger, and when thats a runaway GCC instance, I'd rather GCC get told to die in a fire than say, mysql. I dislike the OOM killer so much, that I've actually disabled it, by using vm.overcommit_memory = 2 instead of vm.overcommit_memory = 1 , and combined that with sane per-user memory usage limits ( ulimit ) vm.overcommit_ratio = 150 vm.overcommit_memory = 2 vm.swappiness = 50 vm.min_free_kbytes=256 vm.lowmem_reserve_ratio=256 128 32 kernel.perf_event_paranoid = 2 vm.dirty_background_ratio=3 vm.dirty_ratio=30 This tends to result in the process that is trying to allocate excess memory simply being told "Sorry, we're out of memory", and that process can then decide to do something with that information. Usually, this event is unhandled and the process just dies. But the end result is the naughty process gets the knife, not some other process chosen seemingly at random. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" _______________________________________________ Linux-users mailing list [email protected] http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
