WARNING: Ignoring deprecated option --unzip

[Simon Jones]

2009/1/27 Alex Broens <ms-list at alexb.ch>:
> On 1/27/2009 3:39 PM, Simon Jones wrote:
>>
>> 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...
>
> Could be misbehaved bots are eating up all your available sessions.
>
> if you have a zillion of inactive open connections try reducing your
> smtpd_timeout
>
> start off with and tune according to timeout requirements
>
> smtpd_timeout = 90s
> (read the postfix docs and understand what this setting can do for you, good
> & bad)
>
> Also
> maps_rbl_reject_code = 421
>
> will trigger an immediate session closing after a RBL reject so misbehaved
> bots won't eaat up all your sessions
>
> h2h
>
> Alex
> --
> MailScanner mailing list
> mailscanner at lists.mailscanner.info
> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>
> Before posting, read http://wiki.mailscanner.info/posting
>
> Support MailScanner development - buy the book off the website!
>
Thanks Alex, have enabled that - am now trying to get some sensible
results from tcpdump -i eth1 -qn port 25