| |||||||||||||
Performances of ext4Performances of ext4Posted Jan 26, 2010 15:00 UTC (Tue) by ricwheeler (subscriber, #4980)In reply to: Performances of ext4 by kleptog Parent article: LCA: Why filesystems are hard
I agree in general with the comment, but have to point out that the transaction rate depends a lots of things.
You can get a rough idea of how many transactions your storage can do by timing the fsync()'s per second of a dirty file. On a S-ATA drive, that number is around 30-40 per second, on an enterprise class array it can jump up to 700/sec over fibre channel and with something like a PCI-e SSD device it can go beyond that.
Note that you can also try and batch multiple transactions into one commit - ext4 supports batching for multi-threaded writers for fsync for example.
(Log in to post comments)
Performances of ext4 Posted Jan 26, 2010 15:30 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
SATA drives can do better than that.
for rotating media, figure the drive can do one fsync per rotation when writing to sequential file, for 7200 rpm drives this is ~120/sec.
if you are getting thousands of transactions/sec from a database test, you have some buffering going on, and unless that buffering is battery backed, you will loose it in power outages.
the one exception is that if you have multiple transactions going in parallel, you may be able to have different transactions complete their syncs in the same disk rotation, so you may get # threads * (rpm/60) syncs/sec.
enterprise storage arrays have large battery backed ram buffers, which do wonders for your transaction rate, up until the point where those buffers are filled (although even then they give you a benefit as multiple transactions can be batched and written at once, reducing the number of writes to the drives)
|
|||||||||||||