Author: Michael Haardt Date: To: exim-users Subject: Re: [exim] High Perf server - was (exim allowed someone to slam my
mailserver for 3 hours)
On Wed, Jun 29, 2005 at 02:05:23PM +0100, Tony Finch wrote: > On Wed, 29 Jun 2005, Michael Haardt wrote:
> >
> > 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.
>
> That would significantly complicate the code with little advangate, and it
> would make programs like exipick and MailScanner impossible.
The code will certainly get more complicated, but given an API, additional
programs would be possible.
My main problem are disk transfers, not bandwidth. The fsync() calls
increase the amount of transfers, because they write data each time it
is modified, instead of allowing modifications to be combined and then
written. Try to remove the fsync() calls on a busy server and it will
fly, but that's not the solution. It just demonstrates the bottleneck,
although sometimes I wish I had a global configuration setting for that
to clear up a temporary problem.
So, what happens when receiving a mail? Exim creates a new file.
That means: A new inode (dirty inode allocation structure), a new
directory entry (dirty directory content and dirty directory inode),
and of course the file contents (dirty block allocation structure,
dirty data blocks). That may translate to four disk write transfers.
A preallocated file means: A modified inode (dirty inode) and the file
contents (dirt data blocks). That are only two transfers.
Probably I forgot something here, but it is just an example to show
that things could be faster.
