[ZODB-Dev] Re: Use of fsync in FileStorage

[Tim Peters]

[Chris McDonough]
> Stats for an "enterprise class" 3.0GHz dual-processor system set up with
> hyperthreading, running Linux (RHEL 3.0; kernel 2.4.21), on an "Emulex
> LightPulse LP982" controller which fronts for a SAN-attached RAID array
> that appears to the kernel as a SCSI device (I don't have physical access
> to it so I don't know quite what this means but it sounds impressive)

Indeed.

> using 10,000 commits:
>
> 2 fsyncs (added an additional fsync to tpc_vote, per Sidnei's code):
>   38.591 seconds, 259.128 txn/sec
>
> 1 fsync (default Zope 2.7.1 code):
>   23.4319 seconds, 426.769 txn/sec

Surprise!  Good.

> 0 fsyncs (remove fsync from _finish):
>   3.91192 seconds, 2556.29 txn/sec
>
> Ran each of these tests twice with no significant variation.

It's a bit peculiar that nobody has reported significant variation across
tries.

> This would seem to break the pattern of 1-vs-2 fsyncs not behaving much
> differently on Linux, as there is a 60% difference in speed between 1 and
> 2 fsyncs in this setup.

Yup.  That's why I ejaculated "Surprise!" above.  It still fits the "10x
0-vs-2" Linux pattern, though.

> I have no idea why, although this seems to be the first test where the
> disks are network-attached as opposed to bus-attached, so maybe that has
> something to do with it.

Christian reported on a:

    Duron 1.2GHz, 256MB, NFS-mounted partition (based on the box I sent
    the previous stats in). Debian Woody.

System.  Bottom lines on that were:

    436.964 txn/sec  2 fsync
    549.359 txn/sec  1 fsync
    764.286 txn/sec  0 fsync

So that was an instance of the "< 2X difference no matter what" pattern.

One firm conclusion now is that people who know me best have systems that
act most like Windows <0.9 wink>.