Re: Sendmail or Qmail ? ..
On Fri, 2003-09-05 at 01:14, Russell Coker wrote:
> I was under the impression that Sendmail also queues everything to disk. How
> does it's queue operate then?
While the message is coming in, Sendmail buffers the message to memory,
optionally piping the DATA portion to a socket (for milter scanning).
Only after the <CR>.<CR> does Sendmail accept responsibility for the
message (providing it was not rejected by a milter) and queue it. Some
might say this risky (power outages and such) but I would counter that
until the entire message has been received and processed, the receiving
MTA is not responsible for the message. In fact, I think this is
RFC-specified. Why then, if the receiver isn't responsible, would it
want to spend disk I/O queuing a message that may end up being rejected
or may fail to come completely in?
> I'm not sure what the situation was like in 1999, now Qmail and LDAP support
> is adequate.
But only with patches to the source code. And since it sounds like you
can't distribute modified binaries, you'd have to patch/build qmail on
every MTA. I choose not to install a development environment on my
production servers. I distribute only binary packages with apt from a
central repository.
> You need two mail storage servers for 60,000 accounts?
Yes. Actually we now have 4 mail stores. We have discovered, at least
for our situation, that it is not wise to put more than 20K accounts on
a single mailstore. This is not so much for the mail delivery, but for
POP3. As many other ISP admins know, a large percentage of customers
are the psychotic kind, prone to POPing their multi-MB mailboxes every
$%^&#@! minute, and leaving all the messages on the server. This puts a
non-trivial strain on even a fairly hefty dual-x86 box with H/W RAID5
and 2GB of RAM.
Yes, I know we could set a larger minimum interval for POP, but the
political implications of generating tech support calls about "why can't
I POP my mail?" prevent it. Don't get me started on THAT. 8^o
> Of course there are lots of things you can do to tune performance, such as
> mounting with noatime and using a patched kernel to fix the performance
> limiting bugs (I used a SUSE kernel for the mail servers in question).
Yes, we use the noatime trick to great effect on the mail stores.
While we're on the disk topic, does anyone have or know of a tool to
gather I/O statistics on a DAC960? Two of our 4 mail stores have these
controllers, and I'm curious how they're doing.
I did some more figuring on our mail volume and found that even though
each of our 4 mail routers processes 11-12 messages/second (each message
requires up to 20 LDAP lookups and a milter for spam filtering), I see
virtually no latency in delivery to the mail store. I don't say that to
brag, I just have no idea how other folks process their mail, and I'm
curious whether we're out of the ordinary or just run-of-the-mill,
ho-hum. ;)
Good discussion all around though. I'm learning a lot here.
Eric
Reply to: