Re: Runaway processes ?
On Wed, Nov 24, 2004 at 07:15:43PM +0200, Uffe Pensar wrote:
> > [141 lines of quoted material deleted. please learn to trim your quotes ]
>
> ok thanks for all the good advices, I will install postfix and have a
> look att the dovecot and xinetd packages
if you're running dovecot, you don't need xineted. it is a standalone daemon,
which has it's own (configurable) limits on maximum simultaneous connections.
> but as a quick fix its seems that authenticating from a local server
> (instead of radius) and restricting the number of webmailsessions has
> helped for the moment. But I suppose we have to buy more servers in
> the near future.
yes, separating the tasks of 1) sending & receiving mail and 2) storing it &
providing imap/pop/webmail/etc access is very useful.
remember that mail is an I/O bound system. i.e. most of the time the processor
is sitting idle waiting for disk I/O to complete. upgrading the CPU will do
little or no good here. to improve performance, you need to improve the I/O
speed - you can do this with faster disks, hardware raid card with large
non-volatile cache, and by adding more RAM to the system. or by spreading the
I/O load over more disks and/or more servers.
a good starting point for a design is to have multiple small & cheap machines
which are configured to accept all incoming mail (i.e. the MX records point at
them), filter spam and viruses, and then either forward it on to the backend
mail store server, or write it directly into NFS-mounted mail spool
directories. if you use nfs, then you MUST use an NFS-safe mailbox store, like
Maildir. trying to use mbox over NFS will almost certainly lead to mailbox
corruption (although on debian it should be safe because *all* mail handling
programs should use the *same* NFS-safe locking method. i wouldn't count on it
though, especially if you compile your own mail programs rather than use the
packaged ones)
note that these MX boxes *MUST* have access to a list of valid recipients for
all domains that it accepts mail for. this allows it to reject mail for
unknown users during the smtp session rather than accept-and-bounce, so it
doesn't generate backscatter and get bogged down with virus bounces and
undeliverable spam bounces.
the backend mail store could be either one very large and expensive server
which stores the mail(*) and handles all the imap clients, or one medium-sized
file-server (which stores the mail) and several small and cheap imap boxes
which handle the imap connections, with NFS-mounted mail store (see comments
above about NFS-safe mailboxes). when building the mail store, I/O performance
is your key design criteria. don't worry about CPU, all the CPU-heavy tasks
(like spam and virus filtering) are dont by the MX boxes.
you may optionally want another box to handle all outgoing mail (i.e. the one
that your clients use to send mail through, the mail relay). this one should
also be optimised for fast I/O. one good way of doing this is to use a
solid-state-disk (SSD - essentially a large battery-backed ramdisk that looks
like a scsi or ide drive) for the mail queue. e.g. mount /var/spool/postfix
(or /var/spool/mqueue if using sendmail) on the SSD device. SSDs are
typically small and expensive, 1 or 2GB is likely to be the limit of
affordability....but that's more than enough for a mail queue partition.
in my experience, though, all but the largest ISPs receive dozens or hundreds
of times more mail than they send, even when taking mailing lists into account.
the mail store machine can double as the outbound mail relay - giving it an SSD
device for the mail queue is a good idea.
(*) e.g. on multiple 15000 rpm hard disks on a hardware raid-5 controller with
at least 128MB of non-volatile cache ram. or whatever else it takes to
optimise this box for extremely fast I/O.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: