Today I had the chance to observe courier's handling of a large backlog
of messages. One of our downstream SMTP servers went down, and I had
nearly 600 messages piled up for it. When it finally came back up,
courier began delivery to it. Courier started with 400 messages in the
queue cache, and maintained 10 parallel connections to the downstream
(I have set esmtp concurrency to 10).

However, as messages were being delivered, new ones kept coming in
for that downstream SMTP server. And as I understand it, these new
messages get inserted into the queue cache immediately, as long as
there is room.  And therefore, for nearly 4 hours, the "queuedelivering"
value hovered at around 300. Messages that were in the queue cache when
the downstream SMTP server came online, and new messages that arrived,
were being delivered. However, because of the arrival of new messages,
the low watermark of 200 was not reached until about 4 hours later, at
which point, courier went and re-read the queue from disk, and filled
up the cache back to 400 messages. Now, some of these on-disk messages
were for other domains, and they would have been delivered much sooner,
because there were enough outbound esmtp slots available.

So, in summary, messages for this one domain delayed delivery of messages
to other domains, because they had to sit in the queue on disk until
courier's low watermark went below 200.

I realise that the situation can be helped by tuning the values of the
high and low watermark, and making them much closer, like 380 and 400
for example, so that the on-disk queue will be read much more frequently.

However, I have no idea on what values are sensible, and what the impact
would be of making the low watermark so close to the high watermark. It
would mean that the disk would be read more often, but how severely
would it impact courier's performance?

Has anyone else experimented with these values? And if so, what is
your experience?

Sam, do you have anything to add to this discussion based on your
personal testing and experience? I am curious as to how you devised
this algorithm. Is it a well-known algorithm, with documented tuning
guidelines, or is it something you have devised yourself?

-- 
Anand Buddhdev
http://anand.org


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to