FWIW, I run several servers and I tried doing without swap a few years
ago. I think it was Wheezy, but it may be even older. If memory serves
me well, it was a couple of Xen DOM0's, and I was careful to allocate my
DOMU's so that I had 8-12G of RAM just for the DOM0.

I ended up with some erratic lockups on the servers, which I solved by
throwing creating a small swap (on a RAID, but I never expect the
machines to use swap). Since I've done that, I have had no other issues.

I did not investigate any further; I just figured I hacked off the Unix
gods by not having any swap. I'd advise testing like crazy before
putting a machine into production without a swap.

Rod

On 11/28/2018 12:28 AM, Rick Moen wrote:
> Quoting Erik Christiansen (dvalin@???):
>
>> That leaves /var, which I've kept separate for three decades, to obviate
>> the risk of furious rates of logging fatally depleting /. OK, it takes
>> longer now, but the principle remains.
>
> Tip (and one man's opinion):
>
> On servers, I've long found it useful to hsve /var as an ext2 filesystem
> (for highest raw performance), with the following mount options:
> noatime,nodev,nosuid
>
> The noatime option further and substantially reduces metadata overhead,
> another non-trivial boost to system disk performance. The other two
> are an aid against software mishap and a first-level obstacle against
> automated system-cracking tools -- there being no legitimate reason for
> device nodes or SUID binaries on that filesystem. (Depending on your
> system, you probably want to ensure that /var/lib and /var/spool are
> served from elsewhere, either separate filesystems of their own or
> symlinks to trees elsewhere /like to dirs under /home or some such.)
>
>> Growth of /tmp was never a problem, as removal of several day old tmp
>> files was/is a standard cronjob, at least after you've been bitten once.
>
> I actually think tmpfs for /tmp is a fine idea, provided (1) you are
> aware of what'll happen if it balloons, and (2) you're OK with it being
> backed by volatile storage and aren't surprised by it being empty after
> reboots including unplanned ones. The speed gain is serious.
>
> If nervous about all of /tmp being volatile, you could, e.g., have
> subdir /var/volatile only mounted as tmpfs.
>
> For me, I'm leaning towards all of /tmp being on tmpfs and _no_ swap of
> any kind on near-future server systems because of intended use of only
> SSDs, no spinning rust at all. I don't have hard data, but suspect that
> the wear on SSDs from swap activity is substantial to a degree that
> outweighs swap's functional utility -- for my use-case, at least. I
> intend to have a go at a style of operation where running out of
> physical RAM means the OOM killer gets loose for a while, and see how
> that goes. The implicity assumption is 'I'll try to avoid that by
> having enough RAM and not running tasks configured so they're likely to
> blow up and drive the system into swap.' My metrics say that I haven't
> been driving into swap, so it's probably a reasonable stance.
> .
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>

--
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465 US
http://dailydata.net
214.827.2170