Re: How to limit # of messages for one destination in the active queue?

From: Victor Duchovni (no email)
Date: Fri Mar 19 2010 - 11:13:31 EDT

  • Next message: Martin Schütte: "Re: alternatative to Mailman"

    On Fri, Mar 19, 2010 at 03:58:42PM +0100, Attila Nagy wrote:

    > I have a somewhat busy mail relay running postfix 2.7, which has problems
    > with a slow destination.

    > I can't limit the number (or rate) of incoming e-mails for that domain, and
    > I can't increase the throughput of the destination, because I don't operate
    > it (OK, that may be false, because postfix's destination concurrency
    > adjusments can make it worse than what it could accept).

    Forward mail for this domain to a separate queue (Postfix instance)
    that handles mail for this---and perhaps some other similar---domains.
    The slow domain will no longer clog your primary queue.

    Happy spamming...

    > And this is one for citromail:
    > Mar 19 15:47:47 mail postfix/smtp[33147]: 28E47768F4: to=<>,
    >[]:25, conn_use=76, delay=9538,
    > delays=5062/4475/0/0.33, dsn=2.0.0, status=sent (250 ok 1269010067 qp
    > 29585)

    The latency of "0.33" seconds is not unreasonably high. Is this typical
    for deliveries to this domain? With a concurrency of 20, you should be
    able to deliver ~60 messages per second to this destination. Can you
    compute a "smoothed" latency for this destination?

            initialize: lavg := 0;
                            count := 0;

            step: lavg := lavg * 0.95 + (c + d) * 0.05;
                            count := count + 1
                            if (count % 100 == 0)
                                    println lavg;

    The "c" and "d" values would be the sum of the connection and delivery
    delays in the log entry.

            delays=a/b/c/d, ...

    How many concurrent connections do you have for this destination?
    What is the destination concurrency limit?

    P.S. Morgan Stanley is looking for a New York City based, Senior Unix
    system/email administrator to architect and sustain our perimeter email
    environment.  If you are interested, please drop me a note.

  • Next message: Martin Schütte: "Re: alternatative to Mailman"

    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs

    Powered By FreeBSD   Powered By FreeBSD