Tuesday, November 25, 2008
950k reads per second on 1 datanode
i spent last night adding 75% of the next step for our multi-threaded datanode.
and got new numbers...
the config is the same as earlier post, with the exception that
MaxNoOfExecutionThreads=8
flexAsynch -ndbrecord -temp -con 4 -t 16 -p 312 -a 2 -l 3 -r 2
insert average: 461584/s min: 451928/s max: 474254/s stddev: 2%
update average: 533083/s min: 530950/s max: 537351/s stddev: 0%
delete average: 564388/s min: 559265/s max: 567143/s stddev: 0%
read average: 948954/s min: 937288/s max: 959262/s stddev: 0%
also tried using SCI instead of gigabit ethernet
flexAsynch -ndbrecord -temp -con 4 -t 16 -p 256 -a 2 -l 3 -r 2
insert average: 568012/s min: 550389/s max: 578367/s stddev: 2%
update average: 599828/s min: 598480/s max: 602175/s stddev: 0%
delete average: 614036/s min: 612440/s max: 616496/s stddev: 0%
read average: 1012472/s min: 1003429/s max: 1024000/s stddev: 0%
i.e with SCI the 1M reads/sec limit is reached! (on 1 datanode)
i think this should also be achievable on ethernet by adding some
more optimizations (let api-application start transactions directly
on correct TC-thread)
---
comments:
1) the new "feature" is multi threading the transaction coordinator
aka MT-TC
2) this part will likely not make the mysql cluster 6.4.0-release
3) our multi-threading architecture seems promising,
in less than a month i managed to double the throughput
(in a admittedly unrealistic benchmark, but still)
4) the 25% missing from the current patch is node-failure handling
and a "rcu-like" lock which will be used for reading/updating distribution
(it's read for each operation, and updated during node-failure,node-recovery and
online table repartitioning)
and got new numbers...
the config is the same as earlier post, with the exception that
MaxNoOfExecutionThreads=8
flexAsynch -ndbrecord -temp -con 4 -t 16 -p 312 -a 2 -l 3 -r 2
insert average: 461584/s min: 451928/s max: 474254/s stddev: 2%
update average: 533083/s min: 530950/s max: 537351/s stddev: 0%
delete average: 564388/s min: 559265/s max: 567143/s stddev: 0%
read average: 948954/s min: 937288/s max: 959262/s stddev: 0%
also tried using SCI instead of gigabit ethernet
flexAsynch -ndbrecord -temp -con 4 -t 16 -p 256 -a 2 -l 3 -r 2
insert average: 568012/s min: 550389/s max: 578367/s stddev: 2%
update average: 599828/s min: 598480/s max: 602175/s stddev: 0%
delete average: 614036/s min: 612440/s max: 616496/s stddev: 0%
read average: 1012472/s min: 1003429/s max: 1024000/s stddev: 0%
i.e with SCI the 1M reads/sec limit is reached! (on 1 datanode)
i think this should also be achievable on ethernet by adding some
more optimizations (let api-application start transactions directly
on correct TC-thread)
---
comments:
1) the new "feature" is multi threading the transaction coordinator
aka MT-TC
2) this part will likely not make the mysql cluster 6.4.0-release
3) our multi-threading architecture seems promising,
in less than a month i managed to double the throughput
(in a admittedly unrealistic benchmark, but still)
4) the 25% missing from the current patch is node-failure handling
and a "rcu-like" lock which will be used for reading/updating distribution
(it's read for each operation, and updated during node-failure,node-recovery and
online table repartitioning)
Subscribe to:
Post Comments (Atom)
8 comments:
Jonas does ndbmtd show a negative performance impact when you set MaxNoOfExecutionThreads to greater than 8 ?
8 is greatest accepted value.
it refuses to start is set higher.
so yes, definitely lower performance
How good is it compared to single threaded ndbd? I guess the result of prior benchmark(500k reads/s) is even better than ndbd. I wonder how good the latest ndbmtd is compared to ndbd.
Really good news. Is there any dead line for the 6.4 release ?
Great work Jonas
i think (current) plan is to make a beta-release early next year
Great news ! Did you make the same test with 6.3.x version ? Do we get the same performance with a 6.3.x and a 6.4.x if multithreading is disabled ?
Happy New Year and we hope that we'll see a lot of interesting new posts this year !
good post :)
Is it possible to get the code to the flexAsync benchmark client. I'm trying to get a cluster up and running, and I need very high write rates. It sounds like seeing the flexAsync code may help with building my own NDB API client.
Post a Comment