I'm unclear about split_spool_directory - is then intention to split the
spool files across multiple hard drives, or is there a bottleneck in the
filesystem code that limits concurrent accesses to the directory. (i.e.:
Is it disk performance or a kernel locking problem that this setting gets
around.)
NSCD was used.
OpenLDAP "opened up" to use 33 threads on a busy system. I'm not sure if
this was the problem, or if it was the rapid creation and destruction of
processes when doing deliveries. (The kernel profiling work tells me the
processes are a problem, but the kernel profiling can't see the user-mode
bottlenecks, so they may be there as well.)
Regards,
Mike
Michael B. Brutman
Internet Mail: brutman@???
Nico Erfurth
<masta@??? To: Michael Brutman/Rochester/IBM@IBMUS
e> cc: exim-users@???
Subject: Re: [Exim] Some performance notes
12/03/2002 02:06
PM
Michael Brutman wrote:
....
> Everything scaled linearly up to 1 processor. (I was able to test at
0.25,
> 0.50, and 1.00 processor units.) Between 1 and 2 processors the scaling
is
> no longer linear, but still tolerable. After 2 processors it runs very
> strangely - the CPU surges and ebbs in a cycle.
>
> If you have suggestions for fun & easy tests to run, let me know - I've
got
> some playtime still left on the machine.
As usual, use split_spool_directory, some kind of local dns caching
(local dns server or nscd). But I think a real bottleneck is OpenLDAP.
But even here you can try to tweak a little bit, by using address_data
and named lists.
ciao
