MySQL Cluster Performance by Mikael

aspects of performance

response times
throughput
low variation of response times

experience base

dbt2(tpc-c)
tpc-w
prototype
benchmark using NDB API

possbiel areas hot to improve performance
どうやって性能を改善させるか

ensure proper partitioning of your tables
use of new features in MySQL Cluster CGE 6.3
HW
use of features in MySQL Cluster 5.0

パーティショニングを効果的に使う、ってどういうことか？

MySQL Cアプリケーションと、MySQL Cluster　Cアプリケーションの比較

sync
性能は３倍、レスポンスタイムは半分になった
async
6, 1/4

性能が重要な場合はNDB API使うことになる

CGE 6.3.13での新機能

polling based communication
epoll replacing select system call(linux)
send buffer gathering
real-time scheduler for threads
lock threads to CPU
distribution awareness
avoid read bofore Update/Delete with PK

polling based communication

CPUは余計に使うけどレスポンスタイムは向上する
real-time schedulingと一緒に使うと、かなりいい

interrupt handling in dolphin supersockts

dolphin HW has checksums inegrated

socket interface to interrupts

interrupts enabled when no data available in select/poll call where timeout is > 0

polling-based communication benchmark results

CPUに余裕がある場合には性能改善した

epoll replacint select system call

select system call in large clustersのオーバーヘッドが減った
Interl e1000 Ethernet driverのinterruptオーバーヘッドは増えた
32ノード間今日では２０％性能改善

extra round of execution before sending messages

setting threads to real-time

main thread: lower priority
maintenance thread: higher priority
なのでメンテナンススレッド

locking threads to CPU's
Connection thread
watch dog
file system thread
などを固定する

例
CPU0
メンテナンススレッド

CPU1
メインスレッド
Super Socket

4コアの場合は、

CPU0
Interrupt Handling
メンテナンススレッド

CPU1
メイン
Ethernet

CPU2
メイン
Ethernet

CPU3
メイン
Ethernet

こんな構成にする

old "thruths" revisited
以前は1ノード1コンピュータだったけど、今は違う

distribution awareness

ex. SELECT * FROM t WHERE pk=x;
パーティションにマッピングしてしまうと、2倍まで性能改善する

けど、どうやって？？？

remove read before PK update
update t set a = const1 where pk=x;
こんなクエリは改善した

ensure proper partitioning of data model

TC
Primary
Backup
Backup
の順番で2phase commitしていく

パーティショニング
partition by key(warehouse_id)
partition by hash(warehouse_id)
DBT-2は、こんな風にしてパーテョニングを設定した

その他のパーティショニング
一つのノードグループだけをスキャンするようなケース
partition by key(id) (partition p0 nodegroup 0);
こんな感じで

use of features in 5.0
lock memory
batching of IN(,,,) pk access
insert batching
condition pushdown

lock memory in main memory
ensure no swapping occurs in NDB Kernel

batching in (...) w/ pk
INでまとめてSELECT した方が、１０倍速い
select * from t where pk=x
を１００回繰り返すよりも

bulk insertも、同じく１００倍速い

CGE6.4
multi threaded data nodes
だけど、今のところDBT-2には効果なし
NDB API経由の場合には40%性能改善したけど

HW
L2 cache

→いくつかを雑誌記事に追加してもいいかも。SELECT INの効果とか

DataNodeをローカルに一つ増やして性能改善するか、とか

DBT-2
DataNodeの３倍までSQL Nodeを増やしての性能改善は続いた

→まだ最適ノード数の探索は続きそう