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)

Wednesday, November 5, 2008

700k reads per second on 1 datanode

added multi connect to flexAsynch, got new numbers
everything else same as previous post

[jonas@n1 run]$ flexAsynch -ndbrecord -temp -con 2 -t 16 -p 512 -l 3 -a 2 -r 2
insert average: 360679/s min: 346150/s max: 370075/s stddev: 2%
update average: 373349/s min: 372465/s max: 374132/s stddev: 0%
delete average: 371014/s min: 357043/s max: 378523/s stddev: 2%
read average: 731042/s min: 702211/s max: 760631/s stddev: 2%

Monday, November 3, 2008

500k reads per second on 1 datanode

just did some benchmarking on multi-threaded ndbd (binary called ndbmtd)
that is in the coming 6.4 release.

quite happy with results

--- results

[jonas@n1 run]$ flexAsynch -ndbrecord -temp -t 8 -p 512 -r 5 -a 2
insert average: 374200/s min: 374200/s max: 374200/s stddev: 0%
update average: 370947/s min: 370947/s max: 370947/s stddev: 0%
delete average: 395061/s min: 395061/s max: 395061/s stddev: 0%
read average: 537178/s min: 531948/s max: 543092/s stddev: 0%

---

this flexAsynch command will run with
- 8 threads
- 512 parallel transactions per thread
- 8 byte records.

note: during the reads, the datanode was *not* maxed out.

---

this was run on two identical computers,
2-socket, 4 cores per socket Intel(R) Xeon(R) CPU X5355 @ 2.66GHz

api-program was running on computer 1 (n1)
datanode was running on computer 2 (n2)

--- configuration

[cluster_config]
DataMemory=2000M
IndexMemory=150M

SendBufferMemory=8M
ReceiveBufferMemory=8M
LongMessageBuffer=64M

NoOfReplicas=1
ndb_mgmd=n1
ndbd=n2
mysqld=n1,n1,n1,n1
Diskless=1
MaxNoOfExecutionThreads=6
MaxNoOfConcurrentTransactions=16384