Stephen Gran wrote:
> On Sun, Dec 07, 2008 at 09:54:42AM +0000, Graeme Fowler said:
>> Hi Proskurin
>>
>> On Sun, 2008-12-07 at 12:38 +0300, Proskurin Kirill wrote:
>>> Yes - what about mail query processing rewrite?
>>> It is really slow and many company's have a Postfix to hold mail query
>>> on it.
>> I'm not sure I understand what you mean, here. Can you elaborate?
>
> The only way that sentence makes sense is s/query/queue/g
>
> I agree exim's queue processing could be faster, but it's not that bad.
> My main annoyance on large installs is that occasionally it seems the
> retry database loses it's marbles, and you end up with very wierd retry
> behavior. I've never gotten enough of a test case together to produce a
> useful bug report, unfortunately.
I have been thinking about this one over that last few months but
haven't really run into a situation where I required a faster queue runner.
My thoughts were along the lines of a separate exim process which would
be a master queue runner, keeping the queue and retry in memory and have
the exim processes that end in queue communicating via IPC/SHM/named
pipes. Use an ordered queue keyed on next delivery time and only wake up
when an attempt is due. The queue and retry could be written disk
periodically, or simply rebuild from the /var/spool/exim files on start.
I don't know if this would actually speed anything up though, or simply
waste RAM and burn up cycles.
--
The Exim Manual
http://www.exim.org/docs.html
http://docs.exim.org/current/
