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