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.
About the Author
Vadim TkachenkoVadim 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.Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware.He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.
A pity they do not provide an optional BBU for this kind of hardware …
unbelievably low number of tpm!
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.
Andy,
Mark may have used absolutely different setting for InnoDB and benchmarks, so results are not comparable in any way.
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 🙂
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
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.
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 [email protected]
Thanks.
regards,
Sumeet