Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Perhaps...but from 1069 transactions per second (2.6.31) in pgbench to only 280 (2.6.32) the cost is gigantic!
See this page.
Posted Jan 24, 2010 23:17 UTC (Sun) by man_ls (subscriber, #15091)
Posted Jan 25, 2010 8:12 UTC (Mon) by nix (subscriber, #2304)
Performances of ext4
Posted Jan 26, 2010 8:02 UTC (Tue) by kleptog (subscriber, #1183)
Anyone who gets thousands of transactions per second either has a battery backed cache on the hard disk controller, or does not have the D in ACID. Or is running on SSD disks.
The fact that disks and operating systems have silently been ignoring fsync requests has gotten people used to completely unrealistic numbers.
Posted Jan 26, 2010 15:00 UTC (Tue) by ricwheeler (subscriber, #4980)
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.
Posted Jan 26, 2010 15:30 UTC (Tue) by dlang (✭ supporter ✭, #313)
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)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds