On Thu, 06 Sep 2001 09:19:24 +0100, Philip Hazel wrote:
> On Wed, 5 Sep 2001, Sheldon Hearn wrote:
>
> > I'm just wondering whether split_spool_directory costs any kind of
> > measurable overhead on systems that don't require it.
>
> No idea, without measuring it!
>
> It certainly costs overhead, but whether it is significant I do not
> know.
I have feedback. Today, I tried turning split_spool_directory off. My
mailshot queued without a hitch, slightly faster than normal.
After queuing completed, the spool containing 470,000 messages. The
kernel memory required for hashing the spool directory was 10MB, which
suggested a 5MB saving over the memory required to hash the spool when
split.
When I launched my standard 300 exim queue runners to fire the shot,
I was surprised. Each Exim process sizes were 14MB, instead of the
typical 1.4MB - 2MB! I ran out of swap space.
So, it would seem that
1) split_spool_directory is an absolute requirement for large queues
processed by multiple queue runner runners (exim -q)
and
2) Exim queue runners' memory requirements are directly proportional to
the size of the largest spool directory.
Do you think point 2 is unavoidable, or is it just the result of poor
memory management in an area that you never imagined would become
important?
