Autor: Marcin Owsiany Data: A: Exim users mailing list Assumpte: Re: [Exim] Delivery delays - queueing vs. immediate delivery?
On Fri, Apr 23, 2004 at 10:44:00AM +0100, Philip Hazel wrote: > On Thu, 22 Apr 2004, Marcin Owsiany wrote:
>
> > 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,
>
> No, because other queue runners can run and deliver other messages,
> though they might also pick up the big ones.
And unfortunately it looks like they do pick the big ones frequently. A
burst of large messages causes the following patterns of queue runners
work times (queue run start, time until this queue run ends):
12:49:27 1 min. #
12:50:27 2 min. ##
12:51:27 40 min. ########################################
12:52:27 35 min. ###################################
12:53:27 36 min. ####################################
12:54:27 35 min. ###################################
12:55:28 36 min. ####################################
12:56:27 33 min. #################################
12:57:27 32 min. ################################
12:58:27 36 min. ####################################
12:59:27 29 min. #############################
13:00:27 31 min. ###############################
13:01:27 27 min. ###########################
13:02:28 28 min. ############################
13:03:27 26 min. ##########################
13:04:28 27 min. ###########################
13:05:27 26 min. ##########################
13:06:28 27 min. ###########################
13:07:27 24 min. ########################
13:08:27 23 min. #######################
13:09:27 20 min. ####################
13:10:27 20 min. ####################
13:11:27 17 min. #################
13:12:27 17 min. #################
13:13:27 18 min. ##################
13:14:27 20 min. ####################
13:15:27 19 min. ###################
13:16:27 17 min. #################
13:17:27 13 min. #############
13:18:27 11 min. ###########
13:19:27 12 min. ############
13:20:27 8 min. ########
13:21:27 8 min. ########
13:22:27 9 min. #########
13:23:27 8 min. ########
13:24:27 11 min. ###########
13:25:27 3 min. ###
> Take a look at the
> serialize_hosts option of the smtp transport. That can be used to
> enforce a "one-at-a-time to this host" rule.
This might help a bit (the burst will take only N queue runners with it,
where N is the number of slow remote hosts). I will investigate this
closer.
