前回
まず、アジェンダは以下のような感じでした。
アジェンダ
- 19:00 - 19:05 会場に関する注意とステマ by 運営
- 19:05 - 19:15 じゃんけん大会でノベルティー配るらしい) by @MikumoConoHa
- 19:15 - 19:45 運用8カ月の四方山話的な予定 by いとうさん
- 19:50 - 20:20 Mac Miniで作るMySQL Cluster MCCTバージョン by 室田さん
- 20:25 - 20:55 【検証結果発表】MySQL Clusterでもフラッシュドライブを活用してみる by 日本ヒューレット・パッカード株式会社 テクノロジーコンサルティング事業統括 高橋 智雄さん
- 21:00 - 21:30 実際に使っている人に聞く怒涛のQAタイム by 登壇者のみなさん featuring @nippondanji さん
今回、個人的に一番高まるゥゥだったのは @MikumoConoHa ちゃんに写真とらせてもらった
※ブログ書くまでが勉強会ですからね( ｰ`дｰ´)ｷﾘｯ
※MySQL Cluster Casual Talks #2 にConoHaがきたはなしの裏側 - mysql | GMOメディア エンジニアブログ
さらにちなみに、今回は実際に MySQL Cluster を Production で使って 10 ヶ月の四方山的な話をはじめ、チューニング系の話が聞けたタメになる会でしたよ。
※あとで自分のためにトゥギャったりしようかな、と。 -> というわけで トゥギャりました
では以降からがわたしのメモです。
19:00 - 19:05 会場に関する注意とステマ by 運営
- 今回の提供は GMO メディア株式会社
- 多謝！！！
- ハッシュタグ：#mysql_jp
- QA タイム公開質問状 github
19:05 - 19:15 じゃんけん大会でノベルティー配るらしい) by @MikumoConoHa
- しょっぱなで負けた orz
19:15 - 19:45 運用8カ月の四方山話的な予定 by いとうさん
- MySQL Cluster をつかいはじめて 10 ヶ月間
MySQL CLuster きっかけ
- お客様がもともとつかっていた
- VPS で ndbd のほうを使っていた
- ndbmtd が動かなかった
- 性能もあまりでていなかった
- 物理サーバを使いたいらしい
構成
- LVS
- Web, SQL, Admin node (2)
- Data node (3 or 4)
- この構成だと Oracle のサポートは受けれない
パラメタ検討
- HW に適したパラメータは？ Innodb みたいなお約束のパラメータはあるのか？
- 奥野さんの本を読んだりした
- 若干情報が古くなっている
- マニュアルを読んだほうがいい
- Data node
- MaxNoofExecutionThreads
- ndbmtd のみのパラメタ
- 主要な動作スレッドの同左スレッド数
- 7.3 系では max 36, 物理 CPU 数と合わせる
- ThreadConfig
- より詳細な動作スレッドを設定可能
- 各スレッドがどの CPU コアで動作するか固定される
- スピーカーは利用してない (設定しなくても問題なく動いてるから)
- ndbmtd に任せている
- Numa
- NUMA 環境なら Swap Insanity 対策のためにも
- ODirect (default 0)
- innodb_flush_method と同様
- TransactionDeadlockDetectionTimeout (default 1200)
- tc がクエリ実行を待てる時間
- 大きすぎると deadlock 待ちが滞留する
- MaxNoOfConcurrentScans (max 500)
- スキャンクエリの最大並列実行数
- DN 単位で持つ
- 瞬間的に大量アクセスがくると Too many access scans
- MaxNoOfConcurrentTransactions (default 4096)
- DN 単位
- マニュアルに計算式が載っている
- NoOfFragmentLogFiles (default 16)
- FragmentLogFileSize (default 16MB)
- MaxNoofExecutionThreads
- SQL Node
- あまり設定するものがない
- ndb-cluster-connection-pool
- 増やすと接続数が増えるので付加状況次第で性能向上
- query_cache_type, query_cache_size
- MySQL Cluster 環境では無効にする
サービスインから発生した障害と対応
- 障害1
- SQL Node
- Too many active scans
- そもそも受け切れないなら Apache の Maxclient さげる
- SQL Node
- 障害2
- DN
- out of long signal memory....
- LongMessageBuffer を増やす
- DN
- 障害3
- ndbd 3 x 2 を ndbmtd 3 x 1 にするときに発生
- mysqldump してリストア
- しかし失敗
- Redolog 大きく (NoOfFragmentLogFiles)
- TimeBetweenLocalCheckpoints を 6 以下に
- ndbmtd 再起動が必要でメンテ時間は延長した
- 障害4
- daily crontab で ndbmtd が落ちる
- Forced node shutdown ....
- IO 負荷の高いであろう cron (updatedb 実行)を停止
- スワップとの兼ね合いで TimeBetweenWatchDogCheck に引っかかって停止したと考えられたため
- vm.swappiness=0 にした (CentOS 5 系)
監視について
- DN
- CPU コアごとの使用率を監視したほうがいい
- LA 監視や CPU 使用率はあまり役にたたない
- ldm スレッドが一番 CPU 使う
- NW Traffic
- DN の特徴として負荷がない状態でも NW Traffic が発生している
- 100Kbps は発生する
- 10Mbps 以下ならアラートとか
- DataMemory, IndexMemory の使用率監視
- CPU コアごとの使用率を監視したほうがいい
- SQL Node
- 接続監視
- DN との疎通ができているかまで確認する
- 参照更新ができることを確認
- DN との疎通ができているかまで確認する
- CPU 使用率はむしろ SQL Node のほうが使う
- 接続監視
- Misc.
- OS まわり
- NIC のリングバッファは最大に
- DN でスワップ発生は致命的
- vm.swappiness=0に設定しつつメモリに余裕があるか安定するまでは気を配る
- バージョン
- 最新バージョンをできるだけ使ったほうが恩恵が大きい
- Join 性能が 7.2 系より 7.3 系のほうが 30 倍くらい速い
- 最新バージョンをできるだけ使ったほうが恩恵が大きい
- OS まわり
おわりに
- MySQL Cluster
- レンジ系、セカンダリインデックスを使用したクエリが苦手
- 一台停止してもサービス継続するので楽
- 主キーに対する const な select はひたすら速い
- クエリによる向き不向きの差が大きい (通常の MySQL のほうが良いケースもあるのでよくよく検討を)
19:50 - 20:20 Mac Miniで作るMySQL Cluster MCCTバージョン by 室田さん
OpenPNE の開発をされている方
インフラ系が好きで自宅兼事務所に 42U ラックがある (それも 3 つ)
- 月の電気代 20 万円...
- そんな Infra でやってしまったことの共有
SAMSUNG の SSD を大量購入
- EVO に最近変えました
- 32 個購入
- Write:Read=800MB/s:900MB/s
- Thunderbolt 接続で
- 1240MB/s:1000MB/s に
そんなインフラの上に Virtual box で MySQL Cluster 環境構築
- Oracle VM Virtual Box に Ubuntu
今はそれを使って何をしてるか？
- WordPress やってる
- MySQL Cluster 上に WordPress 用の DB, User
- Web Server 上に WP 日本語版
- ...
- 各テーブルを ndbcluster engine に変更
- ここ重要
- 11 個の WP 用のテーブルを変換 (alter table hogehoge engine=ndb;)
- SQL Node での動作確認
- これで WP がどれだけさばけるようになったのか？
- 一ヶ月自動書き込み、 100 万記事更新しても問題なく動作した
- WP の DB を MySQL Cluster にすることでよりサクサクに
OpenPNE でも可能であることを確認
- MySQL Cluster を使った SNS の運用等も議論していきたい
ATTO という製品の紹介
- Mac mini に FusionIO を付けれるようになる？
20:25 - 20:55 【検証結果発表】MySQL Clusterでもフラッシュドライブを活用してみる by 日本ヒューレット・パッカード株式会社 テクノロジーコンサルティング事業統括 高橋 智雄さん
資料はこちら
- 2014-06-27 16:34 追記
HP ProLiant BL 460c Gen8 上で MySQL Cluster 7.3 をうごかした検証
検証環境
- BL460c Gen8 x 6
- Admin x 2
- DN x 2
- SQL Node x 2
- MySQL Cluster 7.3.3
検証内容
- パラメータチューニングによる効果測定
- フラッシュドライブを使用した場合のディスクテーブルの性能検証
- ディスクテーブルはメモリテーブルに比較して遅いと言われている
- ディスクテーブル用のストレージにフラシュドライブである IO アクセラレータを使ったらどうなるか
- 測定方法
- sysbench の complex mode で
- Admin Node 上で
- サーバリソースは sar で監視
メモリテーブルにおけるチューニング効果
- 全データをメモリ上に配置して sysbench
- Datamemory 230MB
- Indexmemory 15MB
- ほぼ Default
- 3,000 TPS くらいで条件ちがっても差は大きくなし
- DN ボトルネック？ ndbmtd スレッド数がデフォなので CPU があまり使われていない
- 3,000 TPS くらいで条件ちがっても差は大きくなし
- MaxNoOfExecutionThreads を 16 に
- 5,000 TPS くらいまでスケール
- 全体的に 1.5 倍に
- ThreadConfig を設定するとさらにスケール
- SQL Node を 2 倍に増やすと 2 倍に
- ここまでで、 DN は CPU が平均して使用されるようになった (CPU 使用率 40% くらい)
- SQL Node は sysbench のスレッド数の増加に伴い、使用する CPU がふえている. sys の比率が高い。
- ndb-cluster-connection-pool を 8 にした
- 13,500 TPS くらいまで最大伸びた
- DN の CPU 使用率も 60% くらいまで使えるように
- SQL Node も sys の割合が減った
- チューニングによる応答時間の変化
- デフォと比べると 1/4 に短縮
ディスクテーブルにおける IO アクセラレータの効果
- HP IO アクセラレータの紹介
- PCIe 直結お NAND フラッシュストレージ
- データをメモリテーブルに配置したケースとディスクテーブルに配置したケースで sysbench 比較
- 結果
- IO アクセラレータをメモリと比較するとスループットが 1/3
- 応答時間は 1.5 倍程度 (HDD は比較にならないくらい「遅い」)
- IO アクセラレータ使用時は CPU の iowait が発生しなかった
- HDD の場合は iowait 大量発生
- IOA は HDD の 20 倍の READ 性能 (DN の場合)
- IOA が効果的なケース
- それほど性能欲求が高くないシステムでデータ量が 1TB なら
- 必要メモリ 2TB + alpha
- IOA なら DN 2台でおｋ
- データ量が多くメモリのみではサーバ数が多くなりすぎるケースに良い
- それほど性能欲求が高くないシステムでデータ量が 1TB なら
まとめ
- パラメタチューニング
- DN
- ndbmtd を使用する
- MaxNoOfExecutionThreads, ThreadConfig
- SQL Node
- db-cluster-connection-pool
- IOA
- メモリテーブルの 1/3 のスループット、 1.5 倍の応答時間でおさまった
- DN
21:00 - 21:30 実際に使っている人に聞く怒涛のQAタイム by 登壇者のみなさん featuring @nippondanji さん
- 奥野さん無双な QA タイム！
- 公開質問状
より
SHOW ENGINE NDBの見方を知りたい(そもそも使う?)
- トランザクションの ID が進んでいるかどうか
- 生きてるノード数をみる
- レアモノですよ、これ
Point In Time Recoveryってやったことあれば感想(?)を聞きたい。
- できますよ
- ふつーの MySQL とおなじようにうごくよ
EXPLAINはMySQL Serverと同じくらい役に立つ？
- 一応役には立つと思う
- Extra にフツーの MySQL とは違う内容がでてくる
- 最初はこれはいいのか悪いのかわからなかった
- 慣れたら分かる、、、、、よ？
- Innodb とは別物とおもったほうがいいよ
60GBのデータベースを乗っけるのに、48GB(か64GB)のメモリーを積んだデータノードを2つ並べるのと32GB(か48GB)のデータノードを4つ並べるならどちらがよさげ？
- どっちがいいかはアプリの特性に依存する
- ノード数が増えることによる問題がないなら、安い方でいいのではないか
- どこにそのデータがあるか特定できるような場合はスケールするものはいい
- スキャン系はスケールしない
- フルスキャンに近いようなものならスケールする
- 結局は性能特性次第
NDB memcached Engineに心惹かれるんですが実績とかあれば。
- 使ったことはあるらしいけど、あんま速くなくてやめた
- 使い方の問題だとは思うけれども
CREATE TAMPORARY TABLE Engine= MyISAM AS SELECT .. って邪道ですか？
- Innodb では邪道とはしってるけど
- ローカルのテンポラリテーブルとしてやる分にはいいのでは？
- ひまな SQL Node でやる分にはいいのでは？
SQLノード、データノードのH/Wを選定する上でのポイントを知りたい(SQLノード向きのH/W、データノード向きのH/Wスペックが知りたい)
- Mac Mini 以外で
- スキャンが多いなら DN にメモリいっぱい
- バージョンによっても
- NW ならボンディングとか
- NUMA になってると Swap insanity とかおきてしまう
- CPU コアは正義
DN を増やしたにもかかわらずスループットが落ちたのは？
- 細かいスキャンがおきるとオーバーヘッドがその分増える (sysbench の中にはそういう処理があるよね)
今回も奥野さんの本が紹介されまくりでしたね。
バージョンが少し古くなっているので、そのへんの改訂がはいることを期待しつつ、今回はこんなところで。
GMO さんありがとう、な、お・ま・け
#mysql_jp に @MikumoConoHa きてた！ビッグバンカワユス！ via #iphone5s
