Testing FusionIO: strict_sync is too strict…

PREVIOUS POST
NEXT POST

With new updates of FusionIO drivers I was able to test it on our Dell R900 with Ubuntu 8.10 without pain of compiling drives myself and downgrading to older kernel, so I was decided to test it in strict_sync mode.

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.

So let’s benchmark it – as usually I do tpcc-mysql benchmark on 100W (9GB data) with 3GB buffer_pool in O_DIRECT access.

The raw number are here

and graph is
.
Results are in TPM (Transactions Per Minute), more is better, and graph shows how result is changing in time ( axis X ).
It is too obvious from graph to comment it…

I actually did not test if you really loose transactions in case of power outage in default mode, this is something to check.

PREVIOUS POST
NEXT POST

Comments

  1. Vadim says

    Andy,

    Mark may have used absolutely different setting for InnoDB and benchmarks, so results are not comparable in any way.

  2. says

    Didier Spezia,

    This also surprises me. $500 RAID cards have BBU on them. I think it should not cost more than $100 to provide BBU and same as for RAID card it should be possible to have it as an option but neither FusionIO nor any SSDs I know provide is an an option.

    Probably lying is good enough for most of users :)

  3. Stephan Uphoff says

    Vadim,

    I expect that our next release will no longer require the strict_sync setting for durability (without any performance loss)
    I am surprised about the low throughput – with or without strict_sync – are you testing with a single thread ? (Even for that it seems to be very slow)
    Can you describe your test setup?

    Currently with strict_sync on I recommend writing large blocks using at least two threads for writing (unless they are serialized by a file lock anyway).
    For strict-sync you can think of the sync writes as participating in group commits that are either triggered by reaching a certain combined size (depending on card – should be smaller than 128K in your case) or a timeout.
    Unfortunately the last write that reaches the combined “group commit” size will overflow into the next “group commit”.

    Hope this helps and again – strict_sync should no longer be required in the near future.

    Stephan

  4. Vadim says

    Stephan,

    It’s would be amazing if we will be able to rely on fsync without strict_sync and with the same performance!

    I am testing tpcc-like benchmark. You can see more details about setup in this post.
    http://www.mysqlperformanceblog.com/2009/04/30/looking-on-54-io-bound-benchmarks/

    In this benchmark I use 32 connection to mysql, but mysql settings are
    innodb_write_io_threads=16
    innodb_read_io_threads=16

    so final concurrency on device may be different.

    Please let me know when strict_sync is not be needed, I will re-test it.

    Currently we can’t recommend FusionIO to customers who have strong durability requirements.

  5. says

    Hello Vadim,

    I am the Principal Solutions Architect at Fusion-io. I focus on Database systems integration with Fusion-io.

    We have made some improvements in our latest drives that allow us to flush in-flight data. Your feedback is very crucial for us and I would like to enlist your help in re-testing our product without strict_sync and simulating power loss scenarios to ascertain that there is no corruption or data loss. If you are willing to something like this, please email me at sumeet@fusionio.com

    Thanks.

    regards,

    Sumeet

Leave a Reply

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