• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Slow SMTP response from Qmail

cmaxwell

Regular Pleskian
We are seeing intermittent slow responses from SMTP on a RHEL6 server running Qmail on Plesk 11.5. The response is being measured from a remote Zabbix server.

The response time seems to be slow (>10s) for a period of 2-3 minutes and then returns to normal (<1s). All other services continue to be ok during the period of slowness.

The server_args line in /etc/xinetd.d/smtp_psa already contains "-Rt0" and all the DNS servers in /etc/resolv.conf are resolving properly.

From looking at the maillog file the server was receiving about 35 SMTP connections a minute at the time of the slowdown. We have the server configured to use 2 x RBL's.

I wonder if we are hitting a limit on the maximum amount of SMTP connections. The file /var/qmail/control/concurrencyincoming does not exist so, according to the Qmail manual, there shouldn't be a limit on the number of incoming SMTP connections.

Does anyone have any suggestions on what more to check?
 
@IgorG Thanks for your reply. Unfortunately the file /var/qmail/queue/lock/trigger already exists on the server so this doesn't appear to be the issue. Is there an xinetd limitation perhaps?
 
A limitation on the number of incoming connections for example? Just trying to work out what could be causing the response times to vary so much. Server loads are low and it's servicing ~30 SMTP connections per minute on average.
 
Unfortunately doesn't seem to be that issue either - there are no "Deactivating service..." lines in /var/log/messages so doesn't look like that's the cause of the problem.
 
At the time of the slowness/timeouts occurring, we seem to be having some very long SMTP sessions occurring:

Code:
Jun 17 08:04:00 server xinetd[11309]: EXIT: ftp status=0 pid=24979 duration=1(sec)
Jun 17 08:04:02 server xinetd[11309]: EXIT: smtp signal=13 pid=20651 duration=73(sec)
Jun 17 08:04:06 server xinetd[11309]: EXIT: ftp status=0 pid=25524 duration=0(sec)
Jun 17 08:04:08 server xinetd[11309]: EXIT: smtp status=0 pid=22241 duration=53(sec)
Jun 17 08:04:13 server xinetd[11309]: EXIT: smtp status=0 pid=24901 duration=15(sec)
Jun 17 08:04:15 server xinetd[11309]: EXIT: smtp status=0 pid=25206 duration=14(sec)
Jun 17 08:04:15 server xinetd[11309]: EXIT: smtp status=0 pid=22882 duration=46(sec)
Jun 17 08:04:16 server xinetd[11309]: EXIT: smtp status=1 pid=22022 duration=65(sec)
Jun 17 08:04:17 server xinetd[11309]: EXIT: smtp status=0 pid=25900 duration=6(sec)
Jun 17 08:04:18 server xinetd[11309]: EXIT: smtp status=1 pid=22127 duration=65(sec)
Jun 17 08:04:21 server xinetd[11309]: EXIT: smtp status=0 pid=21952 duration=71(sec)
Jun 17 08:04:21 server xinetd[11309]: EXIT: smtp status=0 pid=25286 duration=18(sec)
Jun 17 08:04:22 server xinetd[11309]: EXIT: smtp status=0 pid=23485 duration=45(sec)
Jun 17 08:04:22 server xinetd[11309]: EXIT: smtp status=0 pid=22447 duration=62(sec)
Jun 17 08:04:22 server xinetd[11309]: EXIT: smtp status=1 pid=25391 duration=17(sec)
Jun 17 08:04:25 server xinetd[11309]: EXIT: smtp status=0 pid=22397 duration=66(sec)
Jun 17 08:04:25 server xinetd[11309]: EXIT: smtp status=1 pid=25901 duration=14(sec)
Jun 17 08:04:26 server xinetd[11309]: EXIT: smtp status=1 pid=23401 duration=51(sec)
Jun 17 08:04:27 server xinetd[11309]: EXIT: smtp status=0 pid=25941 duration=15(sec)
Jun 17 08:04:29 server xinetd[11309]: EXIT: smtp status=0 pid=24052 duration=43(sec)
Jun 17 08:04:33 server xinetd[11309]: EXIT: smtp status=0 pid=23851 duration=52(sec)
Jun 17 08:04:35 server xinetd[11309]: EXIT: submission status=0 pid=27016 duration=3(sec)
Jun 17 08:04:40 server xinetd[11309]: EXIT: smtp status=0 pid=23992 duration=55(sec)
Jun 17 08:04:42 server xinetd[11309]: EXIT: submission status=0 pid=27427 duration=2(sec)
Jun 17 08:04:48 server xinetd[11309]: EXIT: smtp status=0 pid=26719 duration=22(sec)
Jun 17 08:04:49 server xinetd[11309]: EXIT: smtp status=0 pid=23915 duration=66(sec)
Jun 17 08:04:50 server xinetd[11309]: EXIT: smtp status=0 pid=27123 duration=16(sec)
Jun 17 08:04:50 server xinetd[11309]: EXIT: smtp status=0 pid=26211 duration=32(sec)
Jun 17 08:04:57 server xinetd[11309]: EXIT: smtp status=0 pid=22302 duration=100(sec)
Jun 17 08:04:58 server xinetd[11309]: EXIT: smtp status=0 pid=25789 duration=47(sec)
Jun 17 08:04:59 server xinetd[11309]: EXIT: smtp status=0 pid=27945 duration=11(sec)

Is there a maximum number of SMTP sessions that can be handled at one time?
 
Maybe switching to modern Postfix MTA would be faster and better solution?
 
Thanks for your responses, IgorG.

After further checking we found it was the RBL b.barracudacentral.org that was causing the intermittent delays - when we disable it and only use sbl-xbl.spamhaus.org the SMTP connections are very quick. Is it possible to prevent an RBL lookup from taking too long?
 
Back
Top