Date: Wed, 22 May 2002 16:41:23 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Omar Thameen <omar@clifford.inch.com> Cc: FreeBSD Hackers List <freebsd-hackers@FreeBSD.ORG> Subject: Re: tuning a CPU bound server Message-ID: <200205222341.g4MNfNtt042444@apollo.backplane.com> References: <3CEC0E35.26DBB385@pipeline.ch> <20020522181822.A51741@mail.k12us.com> <3CEC2849.CBAFE41A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think this has gotten off-topic. I am going to go back and respond
to the original posting.
When I was doing BEST Internet we had very similar problems with our
mail servers. We were constantly cpu-bound. I was constantly fiddling
with it (sendmail in this case). For months. For years, in fact.
We did things like put sendmail's dns cache in a ramdisk, split the
queues, tuned the retry periods, etc.
The fiddling ultimately produced incremental gains but in retrospect it
was a waste of time. The solution that worked... *REALLY* worked,
was two throw more horsepower at the problem. Even more so the solution
was to simply add more servers. I created a set of 3 incoming mail
servers and a set of 3 outgoing mail servers. The mail servers were
load balanced simply with an IN A (DNS) round robin, which worked
wonderfully. Separating the incoming from the outgoing servers allowed
me to do relatively simple tuning of the incoming servers for incoming
traffic, and relatively simple tuning of the outgoing servers for
outgoing traffic. One also gets the added perk of being able to
turn down individual servers for maintainance without taking down the
entire company's mail system in the process.
So what I would recommend is that you add another duel-cpu server and
load balance the traffic with DNS. It's worth doing some tuning but I
would not waste my time at it.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205222341.g4MNfNtt042444>