MySQL Cluster でもフラッシュドライブを活用してみる

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
MySQL Cluster でも
フラッシュドライブを活用してみる
日本ヒューレット・パッカード株式会社
テクノロジーコンサルティング事業統括
オープンソース部
高橋智雄
2014年6月25日

© Copyright 2014 Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
2
自己紹介
 氏名：高橋智雄
 所属：日本ヒューレット・パッカード株式会社
 仕事：データベース関連のコンサルタント
Oracle Databaseのトラブル対応やチューニングなど。
最近はオープンソースのDBMSも。
 今年：PostgreSQL／Postgres Plus検証
MySQL Cluster検証①（←今日の話）
Oracle RAC提案
MS SQL Server PDWソリューション開発
MySQL Cluster検証②（←HP Moonshot System使いました）
Vertica構築
MySQL Cluster提案
Oracle RAC構築

3
はじめに
本書は2014年1月に実施した、 HP ProLiant BL460c Gen8上でMySQL Cluster
7.3を動作させた性能検証結果をまとめたものです。
検証では、 MySQL Cluster のパラメータチューニングによる性能向上や、PCIe直
結のフラッシュドライブ、HP IOアクセラレータにより、MySQL Clusterのディスク
テーブルの性能が劇的に向上することの検証などを行いました。
本検証にあたり、日本オラクル株式会社殿、フュージョンアイオー株式会社殿
に多大なるご協力をいただいたことに、厚く御礼いたします。

4
アジェンダ
1. 検証環境
2. 検証内容
3. メモリテーブルにおけるパラメータチューニングの効果
4. ディスクテーブルにおけるIOアクセラレータの効果
5. まとめ

1.検証環境

6
2-2.検証環境構成イメージ
MySQL Cluster
管理ノード#2 データノード#1 データノード#2 SQLノード#1 SQLノード#2
BL460c Gen8×6
ベンチマークツール
ProCurve 6120XG
ブレードスイッチ×2
管理ノード#1
IO アクセラレータ
Blade用メザニン
10Gbit Ethernet
IO アクセラレータ
Blade用メザニン

7
1-2.検証環境ハードウェア／ソフトウェア構成
ハードウェアサーバー HP ProLiant BL460c Gen8
CPU Intel® Xeon® Processor E5-2690 2.9Ghz 20MB Cache 2P/16Core
メモリ 64GB (8 x 8GB) DDR3 1600MHz RDIMMs
ディスク
コントローラ
HP Smart Array P220i Controller with 512MB Flash-Backed Write Cache
(FBWC)
内蔵HDD HP 300GB 6G SAS 15K 2.5in HDD × 2 （RAID1）
NIC HP FlexFabric 10Gb 2P 554FLB FIO Adptr
フラッシュ
ドライブ
HP 1.2TB MLC BladeSystem IO アクセラレータ
（データノードのみ搭載。 Factory Capacity (100%)でフォーマット）
OS RedHat Enterprise Linux 6.4 （kernel 2.6.32-358）
IOアクセラレータドライバー iomemory-vsl 3.2.4
MySQL Cluster MySQL Cluster 7.3.3

2.検証内容

9
検証目的
 パラメータチューニングによる効果測定
 MySQL Clusterには一般的なRDBMSよりもパラメータが多く存在
 適切に設定することによりパフォーマンスが大きく向上することを確認
 フラッシュドライブを使用した場合のディスクテーブルの性能検証
 ディスクテーブルはメモリテーブルに比較して遅いといわれている。
 ディスクテーブル用のストレージにフラッシュドライブである
IOアクセラレータを使用すると性能が向上することを確認

10
 測定方法
 sysbenchのcomplexモードを使用して測定
 管理ノード上でsysbenchを実行
 sysbench実行中のサーバーリソース使用状況を sarコマンドで取得
 測定条件（以下を変更して性能測定）
 SQLノード数：1、2 （SQLノード数に従い、sysbenchクライアントを複数起動
して、各SQLノードに負荷をかける）
 sysbench実行スレッド数（負荷の大きさに相当）
 レコード数：チューニング検証では100万行、
ディスクテーブル検証では1億行
 テーブル領域：メモリ、ディスク
性能測定方法

3.メモリテーブルにおける
パラメータチューニングの効果

12
性能測定条件（1/2）
項目説明
データ量 • sysbenchのパラメータ --oltp-table-size=1000000 を指定
• メモリ使用量
 DataMemory : 約230MB
 IndexMemory :約15MB
メモリ関連
パラメータ
• DataMemory=8G
• IndexMemory=8G
ファイルシステム ext4
 全データをメモリテーブルに配置しsysbenchの測定を実施

13
データメモリ
LCP HDD
GCP HDD
UNDO －（メモリテーブルのみのため不使用）
 データ、LCP、GCP、UNDO配置デバイス

14
ほぼデフォルト状態の測定結果
 SQLノード数を1台から2台に増や
しても性能はほとんどかわらない。
 MaxNoofExecutionThreadsが
デフォルトのままなので、データ
ノードのCPUが効率的に使われ
ずボトルネックになっている。
0
1,500
3,000
4,500
6,000
7,500
9,000
10,500
12,000
13,500
0 20 40 60 80 100 120
TPS
sysbench スレッド数
ほぼデフォルト
Read Only - 1Client - 1SQLnode Read Write - 1Client - 1SQLnode
Read Only - 2Clients -2SQLnodes Read Write - 2Clients -2SQLnodes

15
リソース使用状況～ほぼデフォルト～
データノードのndbmtdスレッド数の設定がデフォルト(2)のままのため、
sysbenchスレッド数が増えてもCPUの多くは使われていない状態。

16
MaxNoofExecutionThreads を16に設定
 SQLノード1台の性能は
ほぼデフォルト状態と同じ
 SQLノードを2台に増やすと
約1.7倍のスループットに向上
0
1,500
3,000
4,500
6,000
7,500
9,000
10,500
12,000
13,500
0 20 40 60 80 100 120
TPS
MaxNoofExecutionThreads=16
Read Only - 2Clients - 2SQLnodes Read Write - 2Clients - 2SQLnodes

17
ThreadConfigを設定して、さらに細かくチューニング
0
1,500
3,000
4,500
6,000
7,500
9,000
10,500
12,000
13,500
0 20 40 60 80 100 120
TPS
ThreadConfigを調整
ほぼデフォルト状態と同じ
約2倍のスループットに向上

18
リソース使用状況～ThreadConfig調整後～(1)
データノードはCPUが平均して使用されるようになった。
使用率自体はそれほど高くないので、SQLノードがボトルネック？
データノード

19
リソース使用状況～ThreadConfig調整後～(2)
SQLノードはsysbenchのスレッド数の増加に従い、使用するCPUが増えている。
CPU使用率の中では%sysの割合が高い。
SQLノード
％ｓｙｓが高い

20
ndb-cluster-connection-poolを8に設定
0
1,500
3,000
4,500
6,000
7,500
9,000
10,500
12,000
13,500
0 20 40 60 80 100 120
TPS
sysbench threads
ndb-cluster-connection-pool=8
ほぼデフォルト状態の2倍以上
さらに約2倍のスループットに向上
 最大でチューニング前の4倍以上！

21
リソース使用状況～ndb-cluster-connection-pool調整後～(1-1)
データノード

22
データノードのCPUは効率よく使用されている
データノード

23
SQLノード

24
SQLノードのCPUも効率よく使用されるようになった
SQLノード
％ｓｙｓの割合
が低下

25
チューニングによる応答時間の変化
高負荷時の応答時間は1/4に短縮！
0
10
20
30
40
50
60
70
80
90
100
0 20 40 60 80 100 120
応答時間（ミリ秒）
ほぼデフォルト
Read Only - 1Client - 1SQLnode
Read Write - 1Client - 1SQLnode
Read Only - 2Clients -2SQLnodes
Read Write - 2Clients -2SQLnodes
0
10
20
30
40
50
60
70
80
90
100
0 20 40 60 80 100 120
応答時間（ミリ秒） sysbench スレッド数
ThreadConfig調整後
Read Only - 2Clients - 2SQLnodes
Read Write - 2Clients - 2SQLnodes
0
10
20
30
40
50
60
70
80
90
100
0 20 40 60 80 100 120
ndb-cluster-connection-pool調整後
Read Only - 2Clients - 2SQLnodes
Read Write - 2Clients - 2SQLnodes

26
（参考）チューニング後のconfig.ini（1/2）
[ndbd default]
NoOfReplicas=2 # Number of replicas
DataMemory=8G # How much memory to allocate for data storage
IndexMemory=8G # How much memory to allocate for index storage
#MaxNoOfExecutionThreads=16
ThreadConfig=ldm={count=12,cpubind=1,2,3,4,5,6,7,8,9,10,11,12},main={cpubind=0},io={cpubind=0},
rep={cpubind=0},tc={count=2,cpubind=12,13},recv={count=1,cpubind=14}, send={count=1,cpubind=15} ← 実際は1行
MaxNoOfConcurrentTransactions=16384
MaxNoOfConcurrentOperations=5000000
MaxNoOfConcurrentScans=500
NoOfFragmentLogFiles=8
FragmentLogFileSize=1G
RedoBuffer=64M
TimeBetweenLocalCheckpoints=25
LockPagesInMainMemory=1
Odirect=1
RealtimeScheduler=1

27
（参考）チューニング後のconfig.ini（2/2）
[ndb_mgmd]
NodeId=1
hostname=192.168.0.3
datadir=/var/lib/mysql-cluster/mgm
[ndb_mgmd]
NodeId=2
[ndbd]
NodeId=10
datadir=/var/lib/mysql-cluster/data1
[ndbd]
NodeId=11
datadir=/var/lib/mysql-cluster/data
[mysqld]
NodeId=50
[mysqld]
・・・・後略

28
（参考）チューニング後のmy.cnf
[mysqld]
ndbcluster # run NDB storage engine
log-error=/var/log/mysql/error.log
max_connections=1000
[mysql_cluster]
ndb-connectstring=192.168.0.3 # location of management server

4.ディスクテーブルにおける
IOアクセラレータの効果

30
HP IOアクセラレータとは
PCIe直結のNANDフラッシュストレージ。多くのシステムで、高い成果を実現。
データベースのスループットを3.5倍向上
某ゲーム会社 : データベース
データベースサーバーの
データ同期時間を30倍高速化
某Webサービス会社 : データベース
製品開発における構造解析性能を
2倍に向上し、開発生産性を向上
某製造業 : HPC
某コンテンツ配信会社 : キャッシュ
動画配信キャッシュサーバーを
1/4に削減し、省電力化を実現

31
項目説明
データ量 • sysbenchのパラメータ --oltp-table-size=100000000 を指定
• メモリ使用量
 DataMemory : 約23GB
 IndexMemory : 約1.3GB
メモリ関連
パラメータ
• DataMemory=28G
• IndexMemory=1800M
• DiskPageBufferMemory=2048M（全データがキャッシュされない値
に設定）
ファイルシステム HDD、IOアクセラレータともにext4で統一
 データをメモリテーブルに配置したケースと、ディスクテーブルに配置したケースで
sysbenchの結果を比較
 ディスクテーブルは、ストレージに内蔵HDDを使用するケースと、IOアクセラレータを使
用するケースの性能測定

32
メモリテーブルディスクテーブル
（IOアクセラレータ）
ディスクテーブル
（HDD）
データ
メモリディスクテーブル
（IOアクセラレータ）※
ディスクテーブル
（HDD）※
LCP HDD IOアクセラレータ HDD
GCP HDD IOアクセラレータ HDD
UNDO －（不使用） IOアクセラレータ HDD
 データ、LCP、GCP、UNDO配置デバイス
※MySQL Clusterの仕様上、インデックス及びインデックスがついている列はメモリ上に配置される

33
データ配置デバイスによる測定結果比較
0
10
20
30
40
50
60
70
80
90
100
0 20 40 60 80
応答時間
Memory - Read Only Memory - Read Write IOA - Read Only
IOA - Read Write HDD - Read Only HDD - Read Write
0
1,500
3,000
4,500
6,000
7,500
9,000
10,500
12,000
13,500
0 20 40 60 80
TPS
sysbench threads
スループット
Memory - Read Only Memory - Read Write IOA - Read Only
IOA - Read Write HDD - Read Only HDD - Read Write
IOアクセラレータをメモリと比較するとスループットが1/3、
応答時間は1.5倍程度（HDDは比較にならない）

34
リソース使用状況～データノード～(1)
IOアクセラレータ使用時は、CPUのiowait時間は発生していない
64スレッド（Read Only）におけるリソース使用状況
iowaitで待機

35
リソース使用状況～データノード～(2)
Memory IOA HDD
ネットワーク
使用帯域(MB/sec)
rx 103.0 27.0 1.6
tx 550.5 130.0 7.3
ディスク
tps 53.4 14,617.5 767.5
rd_sec/s 0.0 934,109.4 47,788.2
wr_sec/s 882.9 490.5 289.0
avgqu-sz 0.0 2.8 4.5
await(ms) 0.7 0.2 5.8
util% 1.6 96.5 97.4
IOAはHDDの20倍のREAD性能（スループットの性能比とほぼ一致）

36
リソース使用状況～SQLノード～(1)
64スレッド（Read Only）におけるリソース使用状況

37
リソース使用状況～SQLノード～(2)
Memory IOA HDD
ネットワーク
使用帯域(MB/sec)
rx 367.0 244.1 12.6
tx 37.4 26.7 1.6
ディスク
tps －－－
rd_sec/s －－－
wr_sec/s －－－
avgqu-sz －－－
await(ms) －－－
util% －－－
SQLノードのリソースはボトルネックになっていない

38
IOアクセラレータが効果的なケース
それほど性能要求が高くないシステムで、たとえばデータ量が1TBの場合
 必要メモリ量は2TB+α（NoofReplicas=2とする）
 1サーバーに256GBのメモリを搭載すると想定
 データノードは10台前後必要
このケースで1.2TB IOアクセラレータを使うと
 データノードは2台でOK
データ量が多くメモリのみではサーバー数が多くなりすぎるケースに効果的！

39
（参考）config.ini（1/2）
[ndbd default]
NoOfReplicas=2 # Number of replicas
DataMemory=28G # How much memory to allocate for data storage
IndexMemory=1800M # How much memory to allocate for index storage
#MaxNoOfExecutionThreads=16
ThreadConfig=ldm={count=12,cpubind=1,2,3,4,5,6,7,8,9,10,11,12},main={cpubind=0},io={cpubind=0},
rep={cpubind=0},tc={count=2,cpubind=12,13},recv={count=1,cpubind=14}, send={count=1,cpubind=15} ← 実際は1行
MaxNoOfConcurrentTransactions=16384
MaxNoOfConcurrentOperations=5000000
MaxNoOfConcurrentScans=500
NoOfFragmentLogFiles=8
FragmentLogFileSize=1G
RedoBuffer=64M
TimeBetweenLocalCheckpoints=25
LockPagesInMainMemory=1
Odirect=1
RealtimeScheduler=1
DiskPageBufferMemory=2048M
SharedGlobalMemory=2048M
TransactionDeadlockDetectionTimeout=12000
NoOfFragmentLogParts=12
DiskCheckpointSpeed=1000M
DiskCheckpointSpeedInRestart=1000M
DiskIOThreadPool=4
TimeBetweenEpochsTimeout=32000
追加
修正

40
（参考）config.ini（2/2）
[ndb_mgmd]
NodeId=1
[ndb_mgmd]
NodeId=2
[ndbd]
NodeId=10
datadir=/var/lib/mysql-cluster/data1
[ndbd]
NodeId=11
datadir=/var/lib/mysql-cluster/data
[mysqld]
NodeId=50
[mysqld]
・・・・後略

41
（参考）my.cnf
[mysqld]
ndbcluster # run NDB storage engine
log-error=/var/log/mysql/error.log
max_connections=1000
[mysql_cluster]

5.まとめ

43
まとめ
 パラメータチューニングによる性能向上
 データノード
 ndbmtdを使用する
 CPU関連のパラメータ（MaxNoofExecutionThreads、あるいは
ThreadConfig）を必ず設定する。
データノード専用サーバーの場合、搭載コア数を設定
 SQLノード
 ndb-cluster-connection-pool を設定する
コア数に応じて4～8程度に設定
 IOアクセラレータを使用したディスクテーブル
 メモリテーブルの1/3のスループット、応答時間は1.5倍
 データ量が多く、メモリのみではサーバー数が多くなりすぎる場合に
使用を検討

ご清聴ありがとうございました

MySQL Cluster でもフラッシュドライブを活用してみる

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MySQL Cluster でもフラッシュドライブを活用してみる

Similar to MySQL Cluster でもフラッシュドライブを活用してみる (20)

MySQL Cluster でもフラッシュドライブを活用してみる