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 -- ## List details at https://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/
