Re: [exim] Exim Development - queue

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Marc Perkel
日付:  
To: exim-users
古いトピック: Re: [exim] Exim Development
題目: Re: [exim] Exim Development - queue


Ted Cooper wrote:
> 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.
>
>
>

Hi Ted,

For what it's worth I'm using ran disk for a queue and it is hugely
faster. The way I have it coded to avoid losing email is that I have a
fallback host so that if it fail on the first try it goes to a different
server that uses hard disk for the queue. It also saves a copy of the
queue on shutdown and restores it on startup.

I do risk losing some email on a hard crash that's a rare event.

Not sure what to advise you to do but there is a lot of performance to
be gained.

If solid state drives keep getting faster and cheaper one might buy 4 of
them in a raid 0 array but that's not going to be as fast as ram. Wish I
could find a small battery backed up ram disk.