Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] to swap or not swap



On 9/5/2014 9:50 AM, Jack Coats wrote:
> Before you do without swap, answer a few questions...
>   1. Is my application well defined and well behaved?

It's not about your application's definition and behavior. Having some
swap means that the kernel can page out dirty, idle pages and reclaim
the RAM for active processes. An example off the top of my head: sshd on
a database server. You don't need the daemon resident all the time. Page
out the daemon when it's idle so that the server can use that RAM for
something useful. If the server has no swap configured then the SSH
daemon is wasting RAM.

Always configure some swap. Always. This is not a rule of thumb; it's a
requirement for good Linux performance.

But how much swap to configure? It depends.

Linux hibernates (power state S4) to swap and it requires at least 50%
of physical RAM configured as swap. I recommend 60-75% to provide some
extra headroom in case of lots of incompressible pages.

If you're in production on a commercially supported distribution then
you may be called upon to provide system dumps (kdump facility) to
diagnose problems. If you're a systems level developer then you may want
this facility for your own debugging needs. Red Hat recommends RAM + 2%
configured as swap in order to hold a complete dump.

Otherwise, you'll want to have enough swap to keep the OOM killer at bay
but not so much that the OOM killer doesn't kick in to kill rogue
processes that are thrashing RAM and swap. If you're using LVM then you
can configure a little bit of swap and add more as you need it.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org