WARNING: Ignoring deprecated option --unzip

Simon Jones simonmjones at gmail.com
Tue Jan 27 14:39:12 GMT 2009

2009/1/27 Simon Jones <simonmjones at gmail.com>:
> 2009/1/27 Steve Freegard <steve.freegard at fsl.com>:
>> Simon Jones wrote:
>>> Hi Steve,  thank you.
>>> I seem to have resolved the hold queue problem and can see performance
>>> is very good on the mailscanner front but smtp is very slow to
>>> connect.  It's fine if I restart MS, I get a connection right away on
>>> port 25 but it soon slows down and within a couple of mins it takes
>>> ages to connect.
>>> 20636 pts/0    S+     0:00          \_ grep -i mailscanner
>>> 12582 ?        Ss     0:00 MailScanner: master waiting for children, sleeping
>>> 12583 ?        S      0:10  \_ MailScanner: waiting for messages
>> <SNIP>
>> LOL - based on that output; MailScanner is completely quiet - it's not
>> doing anything except waiting for messages....
>> The reason why it slows down within a couple of minutes has nothing to
>> do with MailScanner; it's due to the number of concurrent connections in
>> Postfix building up.
>> Based on this you can completely ignore MailScanner as the source of
>> your woes; the problem is in Postfix or the database.
>>> it does smell of DNS but I can do nslookup / dig no probs on the
>>> system and I've tried changing the DNS resolvers to different name
>>> servers both on and off my network which has made no difference.
>> Hmmmm - I would have a good look at your Postfix configuration and look
>> for any typos in RBL lists etc. as an unlucky typo there could cause all
>> sorts of timeouts.
>>> I also store relay_domains relay_recipients and transport_maps in a mysql db and
>>> use _maps.mysql.conf to point postfix to the relevant table.
>> I don't know much about Postfix interfaces to MySQL; I would check all
>> the SQL and make sure there are no 'LIKE' directives within the
>> statements and that any WHERE fields are indexed together correctly for
>> maximum query speed.   I would also look at using the 'proxymap' service
>> to prevent bazillions of concurrent MySQL connections from each of the
>> Postfix child processes...
>>> I tried the Log Speed thing but it didn't seem to show any output in the maillog?
>> Maybe you haven't got any mail through since you switched it on; a
>> simpler grep would be:
>> grep Batch /path/to/mail/log | grep processed
>> This still wouldn't hurt leave this on and see how fast your batches are
>> completing; (total time / batch size) = average time per message; this
>> should be between 1 and 8 seconds - any higher and you have a problem
>> somewhere - but I really don't think MailScanner is the source of your
>> issues; it's definitely a Postfix problem.
>> Regards,
>> Steve.
>> --
> I restarted postfix on its own as Jason suggested and this does indeed
> allow connections to become available for a short time and then slow
> up to as previously described.  This is definately something to do
> with postfix and not MS, I've just copied over my main.cf from a
> working system and restarted, same results.  I don't have any firewall
> config active which would imit connections, the server can resolve its
> host name both locally and using dns, ptr works and resolves, postfix
> checks out ok with no errors, permissions in /var/spool/ look OK and
> match with a working system.  getting stuck now, guess it could be a
> denial of service but nothing obviously points to this at the moment.

upped the max processes in /etc/postfix/master.cf and the server is
now responsing normally so it would seem that the default of 100 is
being maxed out, guess I need to do some tcpdump commands to see who's
hammering the system...

More information about the MailScanner mailing list