EmergencyEMERGENCY? Get 24/7 Help Now!

Testing FusionIO: strict_sync is too strict…


Posted on:

|

By:


PREVIOUS POST
NEXT POST
Share Button

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.

Share Button
PREVIOUS POST
NEXT POST


Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.



Categories:
Benchmarks, Hardware and Storage


Comments
  • Didier Spezia

    A pity they do not provide an optional BBU for this kind of hardware …

    Reply

  • unbelievably low number of tpm!

    Reply

  • The tpm does look unbelievably low.

    According to this benchmark:
    http://mysqlha.blogspot.com/2009/06/innodb-io-bound-oltp-2-disk-server.html
    A lowly PC with 2 SATA disk running software RAID 0 is getting around 3,000 tpm in tpcc-mysql.

    That’s more than what you got using FusionIO.

    So a $10K FusionIO capable of 100K IOPS is outperformed by two $50 SATA drives in SW RAID 0???

    Something’s not right.

    Reply

  • Vadim Post author

    Andy,

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

    Reply

  • 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 :)

    Reply

  • Stephan Uphoff

    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

    Reply

  • Vadim Post author

    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.

    Reply

  • 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

    Reply

Leave a Reply

Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.

Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below and we’ll send you an update every Friday at 1pm ET.

No, thank you. Please do not ask me again.