Re: [Mimedefang] MIMEDefang Digest, Vol 165, Issue 5

2017-08-29 Thread Dianne Skoll
On Mon, 28 Aug 2017 20:49:41 -0700
Amit Gupta  wrote:

> Regarding your comment about the downside is that it would "Hold open
> more connections and use more milter threads."  I wasn't quite sure
> what you meant by "using more milter threads"?

mimedefang (the C program, as distinct from mimedefang-multiplexor) is
multi-threaded, and it holds open a thread for each active SMTP session.
So there will be more threads active if sessions are queued than if you
don't queue sessions.

Regards,

Dianne.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang


Re: [Mimedefang] MIMEDefang Digest, Vol 165, Issue 5

2017-08-28 Thread Amit Gupta
Thanks Dianne! Our server has 16GB of ram and we have a 2GB RAMDISK
setup for md.

In the multiplexor man page, I saw this quote:
"Using the -R option has the side-effect of permitting new connections from
the loopback address to queue."  Does this mean you can have loopback
connections queue and non-loopback connections get a standard busy
warning if the max processes are used up?


Regarding your comment about the downside is that it would "Hold open
more connections and use more milter threads."  I wasn't quite sure
what you meant by "using more milter threads"?  Do you mean that it
will just use MX_MAXIMUM mimedefang.pl processes for longer? ie, until
the traffic spike is fully processed?

>
> > Assume a burst of emails comes in and all 20 md processes are busy
> > working.
>
> > 1) What should the 21st and higher connecting  clients
> > experience?
>
> Sendmail will appear to respond more slowly than usual.
>
> > 2) Is there a configurable limit to the number of queued
> > connections?
>
> Yep.  The "-q" option to mimedefang-multiplexor.  See the -q and -Q
> command-line options in the mimedefang-multiplexor(8) man page.
>
> > 3) What's the downside of letting the connections queue
> > other than holding open more TCP connections?
>
> Holding open more connections and using more milter threads.
>
> > 4) Any other tips on the settings you use in production?
>
> If you actually need to queue requests more than occasionally, you
> need a more powerful server.  The queueing feature is supposed to handle
> transient bursts of traffic.  It isn't meant to squeeze more steady-state
> performance out of a server.
>
> > The reason I'm asking is because we recently had a burst of traffic
> > that caused the IO on our server to go up to a point where everything
> > became unresponsive for a couple minutes.  We had our MX_MAXIMUM set
> > to 110.
>
> How much RAM did you have?  You really, really, really don't want a
> MIMEDefang scanning server to start swapping.
>
> Regards,
>
> Dianne.
>
>
> **
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID.  You may ignore it.

Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang