How many fsync / sec FusionIO can handle

Posted on:



Share Button

I recently was asked how many fsync / sec ( and therefore durable transactions / sec) we can get on FusionIO card.

It should be easy to test, let’s take sysbench fileio benchmark and run, the next command should make it:

So that’s 9229.35 req/sec, which is pretty impressive.

For comparison the same run on PERC 6i RAID10 with BBU:

which gives us 5369.62 req/sec.

Note this is for single thread, and in MySQL/InnoDB multi-thread load you may get more transactions per second with group commit ( which is back to live in InnoDB-plugin / XtraDB )

Share Button

Vadim Tkachenko

Vadim leads Percona's development group, which produces the Percona Server, Percona Server for MongoDB, Percona XtraDB Cluster and Percona XtraBackup. He is an expert in solid-state storage, and has helped many hardware and software providers succeed in the MySQL market.

Benchmarks, MySQL

  • 41% increase IMHO is not enough based on the price comparison. For a 8 2.5″ Disk 533GB RAID-10 with BBC on a PERC-6 the price performance still beats out Fusion I/O for the same space requirement. I hope by 2011 for that gap to shrink so I can deploy SSD as the standard for my DB Farm. BTW this bench also mimics my internal benchmarks.

  • The results also seems strange.

    In the current fsync test, FusionIO is 72% faster than 8 disk RAID

    In your random write test earlier (http://www.mysqlperformanceblog.com/2009/12/08/fusionio-time-for-benchmarks/ )
    FusionIO is 653% faster than 8 disk RAID

    In your tpm test (http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-vs-fusionio/ )
    FusionIO is 134% faster than 8 disk RAID

    Why the huge variation in performance difference? I’d expect them to be close to each other, no?

  • fsync does not reflect how many transactions / sec InnoDB can handle, there is group commit + also it does not reflect random read performance. that’s what plays in tpcc and sysbench benchmarks.

  • Andy:

    fsync/s is not the same as throughput, which is not the same as TPM. Those tests measure different things.

  • are you testing append performance on ext3?! hehehehehehehehehe

  • Mark Callaghan

    prepare_commit_mutex guarantees there is no group commit as soon as the binlog is enabled. What fraction of InnoDB deployments that care about performance run with the binlog off?

  • Domas,

    this is xfs with nobarrier.


    What about InnoDB-plugin ? it is supposed group commit is fixed there…

  • Mark Callaghan

    Group commit is fixed when the binlog is off. Otherwise, prepare_commit_mutex is locked in innobase_xa_prepare and unlocked in innobase_commit. The binlog write/sync is done between the two. I am not aware of any (or any good) documentation of this in MySQL or InnoDB docs and the plugin release notes that state that group commit is fixed might confuse people. Not having group commit can be a huge deal depending on your IO setup.

    Subscribe to my feature request for this at http://bugs.mysql.com/bug.php?id=49326. Or if you have a support contract, let them know you need a fix.

  • Interesting. So apparently only XtraDB has “fixed” group commit? I was under the same impression as Vadim.

  • Guys,

    I’d offer some background for this test. What we wanted to check if whenever FusionIO is good enough to keep transactional logs on it. For a lot of SSDs the fsync() rate they can do is slower compared to writes to the RAID cache (with BBU) It looks like it is not the case for FusionIO which is great.

  • Domas,

    What is so funny ?

    The numbers Vadim provided mirror my experience with sequential writes to any transaction log, not necessarily InnoDb’s.

    If transaction log writes are disturbed by other IO, then the pattern becomes random and IOPS/sec will probably go down to a couple hundred per sec. Whether the file system is ext3/4 or xfs does not matter much (ignoring barriers and journaling for simplicity).

  • Vadim,

    You haver earlier written: “As I understand FusionIO in default mode, like Intel SSD, is “lying” to application, and fsync() is not real, it still commit only to internal memory, not to final media. And FusionIO has “strict_sync” mode to guarantee fsync is trustworthy.”

    Is it still the case ? If it is, obviously, one cannot use the device for transaction log storage.

  • VJ Kumar,

    I blogged after that, that FusionIO fixed issue with durability in default mode, so you do not lose you data.

Leave a Reply