Author: Sheldon Hearn Date: To: exim-users Subject: Re: [Exim] Interaction between queue_smtp_domains and -odq
On Tue, 30 Apr 2002 09:36:12 +0200, Sheldon Hearn wrote:
> > I wonder if
> >
> > queue_smtp_domains = hotmail.com
> > hold_domains = !hotmail.com
> >
> > would help you? Of course, you'd have to have that in the configuration
> > when you submit messages, but then get rid of "hold_domains" when you
> > actually do the deliveries.
>
> That's not a problem here. Generation of the queue already uses a
> different queue. In fact, it uses a different spool; a shell script
> moves the generated messages into the "live spool" swept by the queue
> runners.
Well, it certainly does what I asked for. :-)
Unfortunately, it bangs me up against the single biggest problem I have,
namely lock contention on the wait-remote_smtp DBM file. :-(
Even with a RAMdisc, I still getting a significant number of processes
timing out while trying to establish a write lock.
Since Exim's isn't designed around a domain-keyed queue, it seems to me
that anything I do here is going to be a bit of a hack-around.
Given this, it's probably just going to be simplest to keep a separate
queue for Hotmail (and any other problematic domains that crop up) and
use fewer queue runners to process that queue.
It still seems weird to me that as few as 600 queue runners can run into
lock contention on a RAM-backed DBM file as small as 3MB.
I was looking at transport_update_waiting() and wondered whether I
couldn't limit the write lock window, by downgrading the initial
dbfn_opn() to O_READONLY and only acquiring a O_RDWR lock as and when
required in the host_record-based for loop.
I had a little trouble profiling this, though, and wondered if you could
give me an "author's impression" of whether this is likely to reduce
average write lock wait time at all. :-)