On Mon, Dec 08, 2008 at 02:06:09AM +1100, Ted Cooper said: > 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 MTAs that do implement a seperate master queue runner (postfix and qmail are the ones I'm familiar with) do seem to have better thoughput for large queues. I'm not saying exim's queue speed is bad, or even that it needs changing. Some minor tweaks to the config are usually enough to make it reasonably performant. I am under the impression (although I could well be wrong - I don't know the code base all that well) that quite a few fairly core assumptions in the code would need to be changed were exim to move to a model that included a seperate master queue scheduler. If that's an accurate assumption, I'm not sure it's worth it. Cheers, -- -------------------------------------------------------------------------- | Stephen Gran | Adler's Distinction: Language is all | | [EMAIL PROTECTED] | that separates us from the lower | | http://www.lobefin.net/~steve | animals, and from the bureaucrats. | -------------------------------------------------------------------------- -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
