Topic: Mail Server transaction times

[sdykes]

I have recently installed a new SME Server running 7.2 when I checked my mail server properties at www.mxtoolbox.com i find my transaction time is pretty slow around 10-12 sec. if i redirect my mail to my old server 6.1 it is fine and also if i change to my exchange server it is fine around 2 sec. i have tryed turning off virus checking and spam checking no difference. I have had a couple of people saying they have had problems sending to me so thought this may be the problem, although not sure of the exact reason i don't think a transaction time this high is very good.

Also I have setup to hand the mail straight on to my exchange server and turning this off does not make any difference.

Not sure where I should check from here pretty sure not a network issue as the other servers i have are fine. System is used only for mail delivery and spam and AV checking do not use for anything else. it is up to date with patches etc

[mmccarn]

Make sure you've installed the latest updates -- there were a number of updates released after the creation of the 7.2 iso dealing with qpsmtpd that might have bearing here.

I've had ongoing issues with occasional server overload and resulting high email processing times since SME 7.0 that have (knock wood) completely disappeared since Septembers updates.

Also, check your settings for DNSBL and RHSBL - both of these rely on DNS, and if your DNS is slow or overloaded may insert delays in email processing.

[sdykes]

Did some more updates this morning and it has come right (touch wood) Not that i saw any updates relating to SMTP so we will just wait and see.

Thanks for the help though

[sdykes]

Unfortunatly this still seems to be a problem, the only reason it got better was because I rebooted the machine, seems it runs ok for awhile after I have restarted the machine but eventually it slows down again between 10-12 secs which seems far to long for my likiing

[mdo]

I do not suspect that the transaction time should be a problem at all for the mail delivery process but I am no expert to make such a judgement (does it make a difference whether the email from server A to server B is delivered in 10-12 or less seconds?).

If you feel this to be a problem or potential bug that might cause a problem please follow the header to "report bugs and potential bugs in the bug tracker".

[dave simmons]

Just to confirm what sdykes has observed, I have one SME 6.? machine - standard install - no contribs or extras - with all updates applied, and one 7.2 machine, also standard install with no contribs/extras - and all updates.  I see exactly the same - a low transaction time on the 6.1 machine and a very high transaction time on the 7.2 machine.

All our mail goes out on the 7.2 machine.  As far as I know, all our mail is getting to the recipient, and nobody is calling me to say I haven't responded to a mail they've sent, so I don't really know if it is a problem or not. 

[sdykes]

Can someone confimr if I should report this as a bug, I just don't like having it this long as I figure there is a chance that mail server timout may occur.

[mmccarn]

My understanding is that we should feel free to report anything as a bug on which we want the input of the developers.  I've been assured it's easier on them that way, and have been encouraged to post some very simple-seeming questions as bugs.

The 'fix' for your bug may be a line in the Email howto or in the FAQ that we can point to for future admins who share your concern, but the first step is to open a bug...

[Boris]

SME6.x without addons doesn't include AntiVirus and Spamassassin for mail processing like 7.2 does.
Can this extra checking be responsible for small delay?

[sdykes]

MY SME 6.X had all Antivirus Spamassasin etc. I actually had alot more stuff on my old box than i have on my new one. The new box is only doing mail where as my other ver 6 box is hosting, fax server, VPN etc.

To me it looks like a process issue memory maybe becuase it is fine after the machine has been rebooted give it a day and it is back to been slow.

[mmccarn]

Hardware Requirements
I believe that the SME 7.x hardware requirements are significantly higher than they were for SME 6.x.  At least, after I loaded SME 7 onto a PIII / 933MHz with 256MB RAM that I would have expected to work fine w/ SME 6, I found frequent system slowdowns and other problems. 

When I finally looked up the hardware requirements, I found:

Note that we do not believe such a system will provide satisfactory performance for features such as webmail, remote access via PPTP, Virus and Spam Scanners, which are cpu intensive will not perform well on this platform. To utilize all the features of SME Server 7.0, please have a look at the 'Recommended' Hardware Requirements.

The 'Recommended' configuration referred to includes a 1.5GHz CPU and at least 512MB RAM...

Diagnostic Steps
On trying the test you refer to at 'mxtoolbox.com' I had a 17 second transaction time on the first connection to one of my servers, which dropped to 1.7 seconds on the second and all subsequent checks.  My other 3 active SME servers all responded within 3 seconds on the first attempt.

This leads me to believe the problem may be in the DNSBL or RHSBL checking processes - the first connection takes a while as the DNS server looks up the relevant information, then runs quickly once the DNS info is cached locally.  (Note: there has been a DNS cache update released within the last couple days that increases the DNS cache size by a factor of 5 or 10).

I found that I would need to increase the qpsmtpd 'LogLevel' if I wanted to find the exact source of the delay, but it is now too late since all of my servers respond quickly.

If you are still seeing extra long response times, install the latest updates using yum update.  If you're still seeing long response times, try this:

Code: [Select]

config setprop qpsmtpd LogLevel 8
signal-event email-update
sv restart qpsmtpd
Then run the test from 'mxtoolbox.com', then examine /var/log/qpsmtpd/current.

If you can't find the source of the delay, I suggest you open a bug report and *upload* (as an attachment) the sections of your qpsmtpd log related to the interaction with 'mxtoolbox.com'.

If you're unaware, the 2nd column in /var/log/qpsmtpd/current is the i-node number used for any given connection, so you can easily find the lines related to 'mxtoolbox.com' by first searching for 'mxtoolbox.com', then noting the number in the 2nd column of that line and searching for that number through the rest of the log file.  (Since these are i-node references, the numbers will be reused - but it should be easy to figure out which ones relate to the 'mxtoolbox.com' connection).

Once you're done testing with your elevated LogLevel, be sure to change it back or your log files will fill up very quickly! The SME default LogLevel for qpsmtpd is 6:

Code: [Select]

config setprop qpsmtpd LogLevel 6
signal-event email-update
sv restart qpsmtpd
Other Thoughts
There is at least one qpsmtpd plugin available whose specific purpose is to delay the smtp connection - check_earlytalker, for example, inserts a 1 second delay by default, but this delay could be increased to any amount using custom templates.  (the results would show in /var/service/qpsmtpd/config/peers/0). 

I *think* that some of the RBL providers insert delays on their responses if they think you're making too many requests - so if your server is really busy you might get odd delays.

Some other SMTP agents behave as though 'greylisting' is simply the act of delaying the initial helo.  I use one such (Kerio Mail Server) at one site - which by default inserts a 10 second delay in every connection.  Exchange 2003 can also be configured to insert a delay - I have one site configured with a 15 second delay with no adverse impact on their email.


Conclusions
Unless you're seeing actual mail flow problems through your SME 7, there is nothing wrong with a 10-12 second smtp response time.

You should install all of the latest updates.

You should verify your hardware capacity  (On my inadequate hardware I turn off spamassassin with config setprop spamassassin disabled to keep my servers from locking up on busy days...).

Since I think the delay identified by 'mxtoolbox.com' is in the DNS lookups, you should make sure the SME server is using itself for DNS and not forwarding lookups to another server.  If DNS is forwarded to another server, make sure that that server is responding in a timely manner.

If your hardware is adequate and you have installed all the latest updates and your DNS is copacetic, increase your qpsmtpd LogLevel, open a bug, and upload some log info...