Autor: Michael Haardt Data: A: exim-users Assumptes nous: Re: [exim] High Perf server Assumpte: Re: [exim] High Perf server - was (exim allowed someone to slam my
mailserver for 3 hours)
On Wed, Jun 29, 2005 at 10:16:46AM +0100, Mark Lowes wrote: > Mount /var/spool/exim/db/ as a ramdisk.
Correct. I use tmpfs for hints a long time now and it works great.
> We hit a bottleneck in db access when I rolled out the ratelimiting,
> moving to a ramdisk has resolved the problem for the moment, though I'm
> not entirely sure what the next step will be.
A better queue implementation would help a great deal. Possibly by
using a special purpose filesystem, or by Exim working on a raw device
or preallocated files.
There is no reason really that received mails cause a new file to be
created and the directory to be sync()ed. The Exim queue implementation
uses only a tiny subset of what filesystems offer, and that subset could
be implemented much more efficient. There are commercial systems that,
when receiving multiple mails, combine their disk transactions to break
the limit of one I/O transfer per mail. But a more efficient queue is
probably just wishful thinking.
To begin with, Exim could preallocate files, in order to save modifying
the queue directory and the inode allocation. Those files could be a
few blocks long, saving further block allocations for the common case
of small mails.
