Re: [exim] Exim message thaw performance

Top Page
Delete this message
Reply to this message
Author: Todd Lyons
Date:  
To: Volker Schmelich
CC: exim-users
Subject: Re: [exim] Exim message thaw performance
On Wed, Aug 22, 2012 at 1:15 PM, Volker Schmelich <volker@???> wrote:
> Thank you for the tip regarding strace. From a first glance it looks like server 2 loses time between "Writing spool header file" and "LOG: MAIN unfrozen by root". Especially some fstat(), fsync(), close() call lines have higher times displayed when using strace with the -r param.
>
> E.g. one close() shows 0.000644 on server 1 and the same close() on server 2 shows 0.032874.
>
> As for the file systems: none of them is on LVM. Server 1 uses ext3, server 2 uses ext4.


"ext4 uses a performance technique called allocate-on-flush also known
as delayed allocation. That is, ext4 delays block allocation until it
writes data to disk. (In contrast, some file systems allocate blocks
before writing data to disk.) Delayed allocation improves performance
and reduces fragmentation by using the actual file size to improve
block allocation."

Some performance improvement will always result from buffering and
cache. But if the actual work of allocating structures and writing to
the disk is all being deferred until the close() and done all at one
time to reduce fragmentation, it's conceivable that this is partially
to blame. If you can make a separate partition to mount as
/var/spool/exim/ (or /var/spool or /var, whatever works for you) and
then mount it as ext3 with the options that Graeme suggested, that
would give you the testbed you need to compare the two.

> So my uneducated guess would be that ext4 is to blame. Is there a way to temporarily make ext4 behave like ext3 and re-run the test?


In my reading, it's not possible to do this, but maybe there are some
additional mount options that take away some of the performance
slowing features.
nodelalloc - disables the delayed allocation
journal_async_commit - commit blocks written without waiting for
descriptor blocks (I don't fully grok what it does, but if it allows
things to complete async, that may be a good thing if the timing is
based on disk rotational speed).

...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine