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 ([email protected]): > >> 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 > [email protected] > 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
