On Tue, Sep 07, 2004 at 09:05:40PM +0200, V. T. Mueller, Continum wrote: > Seriously, is there anyone here on the list who ever had a memory
> bottleneck in his mailserver(s)?
Yes, but I seriously doubt that splitting Exim in modules could have
changed that. There is more besides the MTA: BIND, mail scanners,
page cache etc. A RAM bottleneck can be fixed at low cost these days.
> Since memory is cheap and decent boards/systems can hold many of it
> I somewhat fail to understand the point of this discussion now.
Indeed. I run MX nodes (Exim as MTA, local caching BIND, POP/IMAP proxy
servers) with 2 GB RAM, 2 Athlon MP 2600+ CPUs and 6 IDE drives using
software RAID under Linux. If you need the performance, this setup gets
it at a small cost. CPU, RAM and I/O are well balanced, all three
becoming the bottleneck at the same time.
> The crucial point in a performant and well-scaling mail architecture
> has ever been [multi-system] design and filesystem IO, or did I miss
> something during the last years?
There is one often-cited weakness in Exim: Queuing. A queue run means
one new process per mail just to determine if it could be delivered.
Even messages that stay on the queue cost processes and associated
message file operations. Since there is no central queue manager, you
have a hell of a time to tune your system. With qmail, I can specify how
many parallel local and remote deliveries to use. That's /deliveries/,
not /queue runners/.
When it comes to queueing, Exim uses more CPU and I/O than needed, which
can be partially fixed by using more RAM for page cache. You could
reduce the memory requirements significantly by changing the queuing
architecture instead of splitting up Exim in different modules, and you
would also save CPU time and I/O.
