On 2/27/2014 11:07 AM, Nikolaos Milas wrote:
> On 27/2/2014 5:10 μμ, Nikolaos Milas wrote:
> 
>> Now,  I am thinking of temporarily removing the:
>>
>>    content_filter = smtp-amavis:[127.0.0.1]:10024
>>
>> line from main.cf and *restarting* postfix (or rebooting the
>> server), then run "postqueue -f" again, at least to have queued
>> messages delivered. 
> 
> I am worried that this may not be a solution, because the deferred
> mails seem to be waiting to be delivered to amavis (127.0.0.1:10024):
> 
> delivery temporarily suspended: connect to
> 127.0.0.1[127.0.0.1]:10024: Connection refused
> 
> ...so, even after a reload without the content_filter, these mail
> messages may still be trying to be delivered to 127.0.0.1:10024.
> 
> Am I thinking right?
> 
> If yes, can the deferred messages be re-processed from start (as new
> incoming messages) so as to avoid delivery through amavisd? How?
> 
> Please advise.
> 
> Thanks,
> Nick


After removing the content_filter lines from postfix main.cf, you
need to requeue messages that already have the content_filter set.

postsuper -r QUEUEID
  or
postsuper -r ALL

(note: requeuing a large number of messages is horrible for overall
postfix performance. Only requeue when required.)

Sounds as if the real problem is you're sending amavisd more mail at
a time than your system can handle. This can be especially bad if
it's causing the system to swap.

Or maybe you've configured postfix to make more connections to
amavisd than there are amavisd listeners. This also badly affects
performance.

The general rule of thumb is 2~5 amavisd processes ($max_servers)
per core available, but keep an eye on memory and make sure swapping
doesn't occur. Authoritative sizing requires testing throughput on
your server at different settings. The postfix master.cf smtp-amavis
transport must have the master.cf maxproc column 7 set equal to or
less than the amavisd $max_servers.

Follow up on the amavis-users list for tuning/sizing help.

Probably 90+% of the time and memory used by amavisd-new is really
used by SpamAssassin, so tuning SA can have a big impact on
performance too.  The low-hanging fruit for SA tuning are 1) use a
current version. 2) remove third-party rules if they cause a
slowdown. 3) SA does a lot of DNS lookups, so fast, local DNS is
required.


  -- Noel Jones

Reply via email to