Sorry to get a little off topic for this particular thread, but...
Jaye Mathisen wrote:
> I did not save all my testdata unfortunately, but at one time, I had 2
> FreeBSD P6 boxes, NFS mounting a Netapp F540, using Maildir for delivery,
> and several boxes generating the email in front. The P6's were
> loadbalanced with a Cisco LocalDirector.
We are doing something very similar with an Alteon ACEDirector balancing to 4
Alpha's running Redhat and qmail. Backend network is a Netapp F230 that is
handling the Maildirs. I was wondering a few things.
a) Almost all delivery (from sending client to remote client) takes 3 to 4
minutes. However, If I look in the receiving client's Maildir/new after the
sending client sends the message, it is there in 5 to 10 seconds. Any POP3
connection simply does not notice the file is there even though it is present on
all 4 servers (via the Netapp, of course). Most likely this is the result of
some caching that the front end servers are doing, but we haven't been able to
track it down exactly. I was curious if you, or anyone else running a similar
setup, saw anything like this issue.
b) You said "At one time" you were running this setup. Have you changed to
something better? After upgrading our News server from using a NetApp F210 to a
DPT UW2-SCSI Raid our KB/second rate (accepting 3 news feeds) increased by up to
200% (240KB to 720KB) and I would think that similar performance increases may
be found for mail, but I am still in love with the fact that aside from the
Netapp which has been very reliable, we have no single point of failure in the
system. The load balancing switch would be one too I guess, but it has been
reliable and a life-saver in many cases.
c) You say you had several servers generating email... Right now all servers do
POP3 and SMTP balancing and all are connnected to the backend... if we would
upgrade to some Raid solution, only one would have access, and I cringe at
implementing NFS on Linux so I though the following solution might work....
Imagine 3 servers:
FRONT (could be a group)
REMOTE (also could be group)
LOCAL (single server with raid)
SMTP would go to FRONT, which then through control/smtproutes would decide
whether to pass the message on to LOCAL or REMOTE. POP3 connections would go
directly to LOCAL. Based on this list's collective experience, would you say
that this is a scalable solution? Better than the current one explained?
After sever tuning qmail-filter (used with Sam's maildrop) we have lowered the
load considerably and won't have to make any changes for a bit, but are looking
to the future.
d) Anyway.. another thing... I am sure most of you are aware of the fact that
qmail uses a lot of file descriptors. Even after setting
/proc/sys/kernel/file-max to 4096, our main server hit this limit shortly after
enabling logging (using splogger). We haven't been able to do logging in some
time because of the intense increase in load that it creates (we are logging to
the local disk of each machine) and the fact that we eventually run out of FDs
(we uppped it to 8192 recently and haven't hit that... but logging is off). Is
qmail-2.0 going to use the same structure of piping one process to another, or
will it be threaded and more efficient when the use of file descriptors is
concerned? Is there some URL for qmail-2.0 yet that may shed some light on the
changes and the timetable for its release?
> I have no doubts a million messages a day would be not impossible at all.
Even with as little as 20-30K users, I am certain that 1million messages /per
day (incoming and outgoing) would not be that unthinkable.
Thanks in advance for any thoughts that any one has on any of the questions.
--
------------------------------------------------------------------------
// Jere Cassidy - System Administration - D&E SuperNet
email: [EMAIL PROTECTED] phone: (717)738-7054
web: http://www.desupernet.net/jere
pager/pcs: [EMAIL PROTECTED] - (717)203-0042
~~~ "While sowing the seeds of Utopia,
you invoked a convenient amnesia" -BR ~~~
------------------------------------------------------------------------
