Hi!
I have a rather large system, which handles mail for another local
system and also acts as a smarthost for the clients:
**********
*** ***
* *
* client hosts *
* *
*** ***
**********
| ______________
| | |
________V_________ | |
| | | |
| exim host |=======>| |
|________^_________| | |
| | host X |
*********** | |
*** V *** | |
|______________|
* Internet *
*** ***
***********
Here is a common scenario:
(1) client A sends a large amount of mail (e.g. 100 messages x 2 MB)
destined for remote hosts (somewhere in the Internet)
(2) some of the mail begins to be delivered at once, the rest of it is
processed by next queue run (because of
smtp_accept_queue_per_connection)
(3) client B sends a large number of small messages (e.g. 200 messages
x 10 KB), destined for the host X
(4) similarily, some of the messages are delivered immedately, and the
rest waits for next queue run
The problem is that now every time next queue runer begins delivery of a
message from client A, it takes a long time to finish, causing the
messages from "B" to be sit in the queue.
What I did for now was:
- increase smtp_accept_queue_per_connection to 30 (I'm afraid of
hitting some remote hosts' smtp_accept_max_per_host, which would
cause unecessary deferrals)
- increase queue running frequency from 30 minutes to 1 minute
I hope that will improve the situation somewhat, but I feel that is just
a workaround (60 large messages, each taking an hour to deliver, will
still block the queue for an hour, while the link to the host X will be
idle (well, not exactly idle, because the queue is not sorted, and some
small messages would slip between the large ones, but it still is not
optimal)).
I guess what I really want is to make queue runners treat the messages
to host "X" in a different way (for example to try deliveries to "X"
first).
I have thought of using queue_smtp_domains: to make it match on the
domains other the ones hosted on host "X", then I could disable
smtp_accept_max_per_host, since number of simultaneous deliveries to
host "X" is not a problem. But that would mean losing the advantage of
immediate deliveries for messages to remote hosts, when the amount of
messages in one connection from a client is low.
Any suggestions? What setups do you use?
Marcin
--
Marcin Owsiany
porridge@???