[svlug] Hardware for a new server

Rick Moen rick at linuxmafia.com
Sun Feb 10 06:59:46 PST 2013


Quoting Joey Hess (joey at kitenet.net):

> Personally I've been running my small home servers on arm for well over
> five years already. :P However, I don't use things that need gobs of
> memory, on small home servers. Or small remote virtualized servers, for
> that matter. Avoiding memory hungry things is a good way to a) save money
> and b) run better software.

The thing I've found grabs the most RAM is aspiring to do highly
effective programmatic detection/rejection of SMTP spam during the
incoming SMTP session.  Marc Merlin's SA-Exim tweak to the Exim4 MTA is
part of the design I use, after doing a first pass of rejecting the
low-hanging-fruit spam using Exim4 ACLs because those are run using fast
and small code.  Anyway, SA-Exim
(http://marc.merlins.org/linux/exim/sa.html) is, IIRC, a modification of
the MTA's localscan front-end code module permitting consulting a
daemonised instance of SpamAssassin & any associated helpers to measure
spamicity before the MTA says either '250 You're cool and I accept this
message', '451 I'm teergrubing you but please hold the line and don't
notice', '550 Die spammer scumsucker, die', etc.

The hitch is that SA, despite usefulness after you tweak it, remains big
dumb perl, somewhat slow and RAM-grabbing.  Being that it's slow, you
end up having to spawn a number of simultaneous instances of it so that
spamicity can be measured.  Fortunately, the Exim4 ACLs have done most
of the heavy lifting before localscan consults SA on the remainder of
incoming mail, or the whole thing might not work.

Now, you might ask, is there a special reason why I _have_ to spawn a
bunch of big dumb perl daemons?  No, I could endure more spam.  However,
I prefer running a tight ship in the antispam department, RAM burden
is the cost I pay for that, and it seems like money extremely well spent.

Also, I cannot help noticing that Linux puts available spare RAM to
extremely effective use for caching that in turn does a hell of a job
reducing hardware wear and disk actvity.  Seems to me there are two
reasons my VA Linux 2230 and scarily antique hard drives are still
cranking after 12 years:  (1) I crammed all the RAM I could find into
it, reducing hardware stress.  (2) I replaced the incredibly crappy,
cheap-ass case fans that VA Hardware Engineering saw fit to use with
ones that don't suck.

Anyway, ack your point about avoiding memory-hungry things, generally.
E.g., I keep finding places where lazy programmers (including me)
avoidably used dynamically generated HTML in situations where Makefiles
more than sufficed, and I've been gradually rooting those out.
_However_, SMTP spam-blocking good enough for my purposes simply needs a
whole lot more RAM than current-generation ARM hosts can address.  (My
view, not necessarily anyone else's.)

On the design I have in mind for my next-generation personal server,
having (and taking advantage of) the ability to address 16GB RAM (with
the Intense PC unit running a dual-core 1.1 GHz Celeron - $441) would
reduce stress on whatever I use for mass storage, reduce AC power draw,
reduce heat generation, extend hardware lift, and eliminate long-term
hassle, which are all primary objectives.  And also boost performance,
though I care less about that.

I _do_ love the SheevaPlug design generally, however, and think Debian's
superior support for ARM is going to be a serious asset in the near
future.
 




More information about the svlug mailing list