natan maciej milaszewski:
> Hi
> Thanx Wietse :) i realy read logs and tested via smtp-source (as You
> advised)
> 
> 
> 1)smtp-source -c -m 1000 -s 1 -C 1 -f a...@domain.ltd -t a...@domain.lt
> inet:127.0.0.1:25

How realistic is it to flood your system with 1000 messages? Fortunately
they were sent sequentially.

> Mar 20 16:29:07 mta-mx postfix/smtp[29226]: 48kSNL0YT4z20nvD:
> to=<a...@domain.ltd>, relay=127.0.0.1[127.0.0.1]:10628, conn_use=17,
> delay=33, delays=0.01/31/0/2, dsn=2.0.0, status=sent (250 2.0.0 from
> MTA(smtp:[xxx.xxx.xxx.]:10027): 250 2.0.0 Ok: queued as 48kSNz2mWXz20nRD)

This message spent 31 seconds waiting for a before-filter SMTP client
process to become available, then no time in connection setup and
2s in delivery to Amavisd.

So there is your bottleneck.

You need to pick a process count for Amavisd that your system can
handle, then set the before-filter SMTP client concurrency and
master.cf process limit accordingly. 

It is OK if the before-filter SMTP client process limit is larger
than the number of Amavisd process, but the before-filter SMTP
client concurrency should not exceed the number of Amavisd processes.

> Mar 20 16:29:07 mta-mx postfix/lmtp[29438]: 48kSNz2mWXz20nRD:
> to=<a...@domain.ltd>, relay=10.0.100.5[10.0.100.5]:24, conn_use=29,
> delay=0.43, delays=0/0/0/0.42, dsn=2.0.0, status=sent (250 2.0.0
> <a...@domain.ltd> 6KKUF0PhdF6eAgAA5fQimA Saved)
> 
> *total delay to amavis delay=33

This message spent very little time in the after-filter queue.

The other examples are the same, they wait less time for a before-filter
SMTP client process to become available, otherwise I see no significant
difference.

        Wietse

Reply via email to