Thanks for all your suggestions. File system optimizations via mount
options did not help. Changing to ext3 or creating an ext3 partition is
unfortunately not possible.
Our current solution is to patch Exim to disable fsync. This reduces the
time to thaw to 15 ms which is similar to the performance we get with
our first server group on ext3. It's a bit ugly but given the
circumstances it seems to work fine. As a precaution we will use the
modified Exim binary only for thawing messages. This implies that
overall Exim performance may still be slower than it could be.
Regards,
Volker
-----Original Message-----
From: exim-users-bounces+volker=quadnova.com@???
[
mailto:exim-users-bounces+volker=quadnova.com@exim.org] On Behalf Of
Jakob Hirsch
Sent: Thursday, August 23, 2012 9:53 AM
To: exim users
Subject: Re: [exim] Exim message thaw performance
Volker Schmelich, 22.08.2012 22:15:
> 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.
close() of file read or written to?
Maybe you could put the strace outputs (-o /tmp/strace) on some
webserver...
> 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?
It should be possible to mount the volume as ext3 (unless a
non-backwards-compatible ext4 feature was enabled, obviously).
Or just create a new ext3 partition, copy your spool there and mount it
over /var/spool/exim.
There are some ext4 options that may change performance, e.g.
noauto_da_alloc, nobarrier, journal_data_writeback.
--
## List details at
https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
