Suddenly "too many simultaneous mail messages"

Vernon Schryver
Tue Feb 24 23:52:03 UTC 2004

> From: Spike Ilacqua 

> > (I don't understand what you mean by FD_SETSIZE being unreal in any
> > select() implementation that uses arrays of bits.  I've not been
> > paying attention; has FreeBSD replaced the classic 4.* BSD select()
> > with something like the Winsock 2.0 tactic or a wrapper for poll()?)
> As far as I can tell the value of FD_SETSIZE does not necessarily
> reflect the actual limit of that select(), but select() does still have
> limits. 

I think it would be a bug if FD_SETSIZE were not the limit on the
size of the array of bits that select requires be passed between
the application and the kernel.  It certainly shouldn't be larger
than that limit and it would be dumb if it were smaller.

>          The new, recommend replacement for poll/select on FreeBSD is
> kqueue().  It is supposed to be much faster that select because the file
> descriptors of interest are kept by the kernel instead of being passed
> back and forth from the application.  

Select() does not pass file descriptors.  Instead it passes arrays of
bits, with the size of the arrays determined by the numeric value of
the largest file descriptor number.  The problem with select is less
in passing those arrays since with today's hardware shuffling even
thousands bits through uiomove()/copyio() is bad but not a big deal.
The evil in select() is scanning those arrays in the kernel looking
for bits that are set. 

Well, unless you use the Winsock trick of making FD_SET() etc. only
pretend to fiddle with arrays of bits but really generate lists or
arrays of poll() style blocks.

(Yes, there are neat hacks for relatively quickly finding the first
bit set in an array of bits.  Making them useful without an absolute
need is a Bad Thing(tm).)

> ...
> And of course there is a man page on any FreeBSD system.

thanks.  It looks like a straight forward generalization of poll().

> > Are you sure you want to support or allow more than 350 simultaneous
> > incoming SMTP transactions per SMTP server?  ...

> The server is running fine, loads are single digit, sendmail has load
> and max connections per second throttles in place.  Everything seems
> fine, the only problem is that DCC hits max_jobs and starts sendmail
> deferring.  However the mail server handles hundreds of thousands of
> messages per-day, not millions.  Maybe something else is going on?

My first guess is that some spammers are hanging up the phone instead
of sending a proper TCP FIN.  In other words, spammer (possibly worms)
are starting SMTP/TCP connections and then abandoning them until a
sendmail timeout hangs up.  If this guess is right, then when dccm is
complaining, you'll find lots of SMTP connections that have been idle
for a long time.  There should also be complaints in /var/log/maillog
about time outs.

My second guess is that you're being hit by one of the spammers that
is too stupid to spread its load among its targets and starts zillions
of connections to individual targets.  I've seen plenty of evidence
of this in the logs for my vanity domain's SMTP server.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.