Hi guys.. I need some advices here.
I found sometimes when "Message queue processing" is full, it will cause "Messages in Queue" accumulate more email & degrade our server performance. Previously the maximum number of delivery threads is set to 50. Now I had increased it to 150 & the messages in queue seem able to send out smoothly.
1) What is the impact by increasing Delivery Threads? What has to be accounted by increasing it?
2) What is in "Message queue processing" that make it full are these messages with status below:
Why it takes too long time to deliver all these emails? And it always show 0%.
(Size: 124.92KB, Downloaded 313 times)
I see you have small-ish messages (85K) waiting for 38 minutes for local delivery, and I can't heplp but thinking you have a DNS issue somewhere. SpamAssassin is doing many lookups for the various URL lists, DNSBLs do their own lookups, Caller-ID and SPF are doing DNS lookups also, and for all I know you are resolving hostnames on incoming connections.
If you e.g. have to wait for the DNS to time out on each and every one of these checks, the delivery will take quite a long time.
Have you done manual name resolving from the command line on the server? Are your name servers inhouse or at the ISP? Do you use a caching name server? The latter is always useful when you have a busy mailserver.
There may be other problems as well, but you won't get anywhere without spending some time with the various logs. If you switch on "Spam filter" messages in the debug log, SpamAssassin will tell you the amount of time it spent processing a mail. If you cross check the message IDs with the other logs, you'll get a pretty clear picture of where the bottleneck is.
Delivery threads are as far as I know for outgoing messages only, but increasing the number of threads may not necessarily shorten the time the messages spend in the queue. The receiving end may have limits on how many parallel deliveries they can take from you, and many mail servers are using greylisting.
For instance, we don't accept more than 20 simultaneous deliveries from a single IP. The burden of sending bulk should be on the sender, not the receiver.
Problems like these are almost never solved with the flick of a switch, just good old elbow grease ...
Kerio discussion forums are intended for open communication between forum
members and may contain information and material posted by members which may
be useful in learning about Kerio products. The discussion forums are not
intended to provide technical support for any specific product. Any
information implied or expressed in the discussion forums is that of the
posting member. Kerio is in no way responsible for the information posted in
the forums, or its accuracy. Kerio employees may participate in the
discussions, but their postings do not represent an offical position of the
company on any issues raised or discussed. Kerio reserves the right to
monitor and maintain the forums to promote free and accurate exchange of