Re: [exim] split_ spool_ directory - when would you use it?

Kjetil Torgrim Homme wrote:
> On Mon, 2006-09-04 at 16:47 +0100, Philip Hazel wrote:
>
>>On Mon, 4 Sep 2006, Warren Baker wrote:
>>
>>
>>>Besides the downside of using it in conjunction with queue_run_in_order,
>>>surely the majority of installations out there make use of
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>>split_spool_directory - so should it not be enabled by default since it
>>
>> ^^^^^^^^^^^^^^^^^^^^^
>>
>>Have you any evidence for this? My (also totally unsubstantiated) guess
>>would be that "the majority of installations" are single-user or
>>small-company users of Debian boxes. I think we just don't know.
>
>
> speaking only for our own installation, we only enable it for the
> outbound queue. the other Exim instances (which outnumber it by 30 to
> 1) use a regular queue. I prefer to know in exactly which directory I
> should look for the queue files. it makes our test for old messages in
> the queue a lot simpler, for instance.
>
> actually, I think that if you have a long queue, you're doing something
> wrong. as I write this, our single outbound queue has 164 messages.
> clearly the number will scale with your number of users, but we have
> more than 60000 users, and I doubt "the majority of installations" have
> more than that.
>

I think you've nailed the core of the issue.

On a 'healthy' POSIX-based system, a single queue should never outrun available
filenames at one level.

On a problematic system, (think massive frozen message count), and/or if on a fs
that has lower limits for per-level filename capability (WinWoes?, OS/2?,
or?...), then split-spool might at least buy some time to spot the problem and
seek a fix before resoeuces were overcome.

Otherwise, neither the extra CPU cycles to sort where in the 'split' tree to
store/recover, nor the time needed by the fs drivers will usually matter.

A typical machine will ordinarily be resource limited by a scanner, or absent
that, probably bandwidth/connection-count bound well before it becomes queueing
system bound.

Which may be why we have no 'one-size fits all' answers?

Bill