On 2011-05-19 at 14:10 +0000, W B Hacker wrote:
> Phil Pennock wrote:
> > At present, there's split_spool_directory, which divides things up with
> > one level of hashing, and then some people script their own queue-runner
> > launchers, running in parallel over sub-trees of the split spool instead
> > of having the Exim daemon launch runners over everything, which compete
> > with each other.
> >
> > Nothing more specific was discussed, that I either recall or find in the
> > minutes; we all understood the general problem.
>
> Known bound, yes.
>
> Problem?
>
> Not sure.
>
> I stand on the position that WHEN one is loading Exim so heavily that it
> HITS that sort of bound, one has far too many eggs in one basket
> downtime-risk-wise, and should split that load over multiple Exim (free)....
Ah yes, thanks for the reminder:
The queue system should not assume that the spool_directory is one
file-system; a reasonable design-choice would be to have a "deferred"
queue for mails which haven't gone out in a timely manner, and have the
deferred queue be on shared storage (DRBD, etc), avoiding the shared
storage and its overhead for short-lived messages.
FWIW: I now work for a company which sends out "lots" of emails each
day (unit of measurement is "million"), mails to account-holders
notifying them of particular updates to their *cough* timeline. I'm
*not* rushing to put Exim into handling that outbound email as there's a
lot of Unicode characters, we don't support 8BITMIME conversion, we're
not fantastic at handling backlogs of millions of messages and generally
I want to get a lot more stats and perhaps implement some new features
before I even try putting Exim in-place.
-Phil,
https://twitter.com/syscomet
