Author: Cantu

[See remaining text…] 

tpcc lanched with -a1 -b1 -W20 -T20 -r1 -R10 -i60
protocol TCP/IP

Scheduler was cfq (deadline scheduler results are really close)

First, on this box (certainly because Fedora 16 use ext4 driver only) ext3 give bad results

so on a database with -write async
for ext4

noatime,async,data=ordered,barrier=1
TPC-C Throughput: 5467.10 tpmC

noatime,async,data=ordered,barrier=0
TPC-C Throughput: 5427.88 tpmC

sync,data=ordered,barrier=0
TPC-C Throughput: 562.11 tpmC

for a raw device
TPC-C Throughput: 6604.00 tpmC

with -write sync
for ext4

noatime,async,data=ordered,barrier=1
TPC-C Throughput: 165.11 tpmC

noatime,async,data=ordered,barrier=0
TPC-C Throughput: 566.89 tpmC

sync,data=ordered,barrier=0
TPC-C Throughput: 568.11 tpmC

for a raw device
TPC-C Throughput: 396.78 tpmC

So reliability have a real cost
hard to have perf and reliability
I really wonder if we can’t get MaxUnflushedWrites or something like
that under Linux too
I would be curious to do same test with this parameter under Linux

it will not be really safe, but at least a medium solution for people
because between
5467.10 tpmC (FW OFF and noatime,async,data=ordered,barrier=1)
and
165.11 tpmC (FW ON and noatime,async,data=ordered,barrier=1)
seems that there is a room

Update:

with FW OFF and MaxUnflushedWrites = 100 and MaxUnflushedWriteTime = 5
ext4
noatime,async,data=ordered,barrier=1
TPC-C Throughput: 1155.67 tpmC

as expected between
5467.10 tpmC (FW OFF and noatime,async,data=ordered,barrier=1)
and
165.11 tpmC (FW ON and noatime,async,data=ordered,barrier=1)

but only partially reliable 🙁

« Hide it