I've learned a lot on managing my Plesk dedicated server through these forums but I am having trouble figuring out why my qmail is very slow.
When I send out email blasts on behalf of our clients to a few hundred recipients, the messages get in the qmail queue but there appears to be a bottleneck when they get there. Qmail will only send one or two emails a minute. A quick fix for me was setting up a cron to restart qmail every minute. This would send out about 50-75 emails a minute. Once the emails were all out, I'd removed the cron. Obviously this is inefficient.
Normal email traffic would work fine but within the past two days, the qmail queue is building from normal traffic. Within a few hours, a few hundred emails are getting stuck in the queue and not sending out. I'm on a 2GB server with plenty of resources to send 1000s of emails. I'm also on the latest version of Plesk and have installed qmail-scanner.
Any help or direction would be greatly appreciated.
Thanks,
Paul
Qmail slow to deliver (Plesk)
Re: Qmail slow to deliver (Plesk)
Hi Paul,
Firstly check your settings for concurrent delivery within qmail, specifically the two files :
/var/qmail/control/concurrencyremote (How many emails to attemp to send at once to remote addresses)
/var/qmail/control/concurrencylocal (The same but for remote).
By default on a plesk server its set at 10 (I think), we set it at 25 for normal servers and 50+ for servers that send out lots of mail (marketing).
Secondly check your queue lifetime (ie how long an email will sit around in the queue failing to be delivered before qmail gives up and bounces it back) :
/var/qmail/control/queuelifetime (Its in seconds).
By default this is 7 days I think, and I think according to the RFCs thats the correct value, ours is 48 hours both to stop the queue being cluttered and also because there's only one or two additional delivery attempts between the two (again i think), qmail uses an extending logarithm to decide when to attempt to resend mail (this only applies to temporary failure codes) reattempting something like 5 minutes after the first attempt, 20 minutes after the 2nd then getting bigger and bigger till its several days between each attempt.
I think restarting qmail resets this counter, so it does sound like you're being affected by this since things work much better after a restart, in which case you need to dig into your maillogs to find out why all the emails are being temporarily deferred by the recipient mail servers.
This is all very basic and generic, but essentially changing the former to higher values may fix things, but more likely you need to dig into whether your emails are being deferred at the remote end and address why thats happening.
Paul.
Firstly check your settings for concurrent delivery within qmail, specifically the two files :
/var/qmail/control/concurrencyremote (How many emails to attemp to send at once to remote addresses)
/var/qmail/control/concurrencylocal (The same but for remote).
By default on a plesk server its set at 10 (I think), we set it at 25 for normal servers and 50+ for servers that send out lots of mail (marketing).
Secondly check your queue lifetime (ie how long an email will sit around in the queue failing to be delivered before qmail gives up and bounces it back) :
/var/qmail/control/queuelifetime (Its in seconds).
By default this is 7 days I think, and I think according to the RFCs thats the correct value, ours is 48 hours both to stop the queue being cluttered and also because there's only one or two additional delivery attempts between the two (again i think), qmail uses an extending logarithm to decide when to attempt to resend mail (this only applies to temporary failure codes) reattempting something like 5 minutes after the first attempt, 20 minutes after the 2nd then getting bigger and bigger till its several days between each attempt.
I think restarting qmail resets this counter, so it does sound like you're being affected by this since things work much better after a restart, in which case you need to dig into your maillogs to find out why all the emails are being temporarily deferred by the recipient mail servers.
This is all very basic and generic, but essentially changing the former to higher values may fix things, but more likely you need to dig into whether your emails are being deferred at the remote end and address why thats happening.
Paul.
Re: Qmail slow to deliver (Plesk)
Thanks for the response. I did have the concurrencyremote at 50 already. concurrencylocal file was empty so I set it to 50.
Didn't have queuelifetime file so I created it and set it to 172800 (two days). But as you mentioned, I don't think this was the issue.
Is there anything or anywhere in specific I should look for to see what might be deferring the messages?
Also, when I looked at the log, I have noticed more spam than usual:
I've also read various posts that have stated permissions and ownership could cause many issues with qmail. I'm wondering if that might be a problem? Here are my qmail files...
Didn't have queuelifetime file so I created it and set it to 172800 (two days). But as you mentioned, I don't think this was the issue.
Is there anything or anywhere in specific I should look for to see what might be deferring the messages?
Also, when I looked at the log, I have noticed more spam than usual:
Code: Select all
Oct 1 08:43:39 servername /var/qmail/bin/relaylock[7381]: /var/qmail/bin/relaylock: mail from 211.221.197.244:46796 (not defined)
Oct 1 08:43:53 servername /var/qmail/bin/relaylock[7383]: /var/qmail/bin/relaylock: mail from 82.128.1.155:63379 (ml82.128.1.155.multilinks.com)
Code: Select all
drwxr-sr-x 2 alias qmail 4096 Jun 21 04:13 alias
drwxr-xr-x 2 root qmail 4096 Sep 28 07:32 bin
drwxr-xr-x 2 root qmail 4096 Sep 16 19:56 boot
drwxr-xr-x 2 root qmail 4096 Oct 1 05:22 control
drwxr-xr-x 30 root root 4096 Sep 28 08:57 mailnames
drwxr-xr-x 2 root qmail 4096 Sep 16 20:12 plugins
drwxr-xr-x 3 popuser popuser 4096 Jun 29 04:33 popuser
drwxr-x--- 11 qmailq qmail 4096 Jun 21 04:13 queue
drwxr-xr-x 2 root qmail 4096 Oct 1 05:20 users
The control folder:
lrwxrwxrwx 1 root root 33 Jan 26 2011 clientcert.pem -> /var/qmail/control/servercert.pem
-rw-r--r-- 1 root root 3 Oct 1 05:11 concurrencylocal
-rw-r--r-- 1 root root 3 Jul 15 14:48 concurrencyremote
-rw-r--r-- 1 root root 1 Sep 30 09:37 databytes
-rw-r--r-- 1 root root 34 Jun 21 04:13 defaultdelivery
-rw-r--r-- 1 root root 245 Oct 16 2009 dh1024.pem
-rw-r--r-- 1 root root 156 Oct 16 2009 dh512.pem
-rw-r--r-- 1 root root 245 Jun 21 04:13 dhparam1024.pem
-rw-r--r-- 1 root root 156 Jun 21 04:13 dhparam512.pem
-rw-r--r-- 1 root root 32 Oct 1 05:20 locals
-rw-r--r-- 1 root root 17 Oct 1 05:20 me
-rw-r--r-- 1 root root 7 Oct 1 05:17 queuelifetime
-rw-r--r-- 1 root root 527 Oct 1 05:20 rcpthosts
-rw-r--r-- 1 root root 614 Oct 1 05:20 rejectnonexist
-rw------- 1 qmaild root 493 Jan 26 2011 rsa512.pem
-rw-r--r-- 1 root root 2954 Jan 26 2011 servercert.pem
-rw-r--r-- 1 root root 25 Jul 22 03:49 smtpplugins
-rw-r--r-- 1 root root 28 Jun 6 13:26 smtproutes
-rw-r--r-- 1 root root 16 Jun 6 13:26 smtproutes.bak2
-rw-r--r-- 1 root root 4 Oct 1 05:22 timeoutremote
-rw-r--r-- 1 root root 4 Oct 1 05:22 timeoutsmtpd
-rw-r--r-- 1 root root 606 Oct 1 05:20 virtualdomains