Thursday, March 19, 2009

online add node - preliminary numbers (2)

Scenario: Grow from two data nodes to four using ONLINE ADD NODE and REORGANIZE PARTITION of a 2GB table, and UPDATE traffic

Setup for each data node:
* Dual cpu - quad core running at 2.33GHz.
* 8GB of RAM
* DataMemory=4096MB
* MaxNoOfExecutionThreads=8
* Configuration generated by Configurator
* Bound execution threads to cores (LockExec/Maint....Thread..)
* Completely distributed setup.

Created the following table and filled it with 2M rows which gives a table (different of last time to simplify further tests) of 2GB in size:

CREATE TABLE `t1` (
`a` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`b` int(10) unsigned DEFAULT NULL,
`c` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`d` varbinary(768) DEFAULT NULL,
`e` varbinary(256) DEFAULT NULL,
PRIMARY KEY (`a`),
KEY `c` (`c`)
) ENGINE=ndbcluster


Baseline (two data nodes)
Random updates of 256B:
UPDATE t1 SET e=<data> WHERE a=<random_value>
where DATA is 256 random bytes and RANDOM_VALUE=random value between 1..2M

Running with bencher-0.12:
src/bencher -t 20 -l 100000
20 threads
Total throughput = 18315.06 qps
Average response time=1089us for each update

CPU Util details at the end of this post (please note I was not trying to max out the data nodes with this test).

With reorg on + no load
mysql> alter table t1 reorganize partition;
Query OK, 0 rows affected (2 min 44.58 sec)
Records: 0 Duplicates: 0 Warnings: 0



With UPDATEs and ongoing reorg
ongoing reorg means: ALTER TABLE t1 REORGANIZE PARTITIONS;
20 threads each doing updates as in baseline
Total throughput = 10907.70 qps
Average response time=1827us for each update
And the reorg took:

mysql> alter table t1 reorganize partition;
Query OK, 0 rows affected (3 min 39.45 sec)
Records: 0 Duplicates: 0 Warnings: 0

Cost in performance during reorg
Throughput decreases with about 40% during the reorg.
Latency increases with about 68% during the reorg.


CPU DETAILS (baseline)



CPU DETAILS (with UPDATE + reorg)

No comments: