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