How many fsync / sec FusionIO can handle


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 )



  1. says

    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.

  2. Andy says

    The results also seems strange.

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

    In your random write test earlier ( )
    FusionIO is 653% faster than 8 disk RAID

    In your tpm test ( )
    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?

  3. says

    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.

  4. Gavin Towey says


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

  5. Mark Callaghan says

    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?

  6. Mark Callaghan says

    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 Or if you have a support contract, let them know you need a fix.

  7. says


    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.

  8. VJ Kumar says


    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).

  9. VJ Kumar says


    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.

  10. Vadim says

    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

Your email address will not be published. Required fields are marked *