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:
Post a Comment